Modules are listed as missing themes in Drupal 7.50, triggers user warnings.

Isn't that just hiding the problem? We shouldn't call drupal_get_filename on nonexistent themes to being with, right?

After upgrading to 7.50 we are getting this too in a non-reproducible way but always together with

User warning: The following theme is missing from the file system: fences. In order to fix this, put the theme back in its original location. For more information, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (Zeile 1128 von /includes/bootstrap.inc).

We are using an aurora subtheme. Fences and ctools modules are enabled.

So my issue was #2765081: Error messages after upgrading to Drupal 7.50 and it got fixed just the same way as the patch in #3. We are not hiding the problem since with that call we are only checking if the file exists or not.

Marking this as RTBC.

So the problem with #3 is that it before 7.50 lead to a system scan for anything missing.

Now it will just lead to a huge missing cache entry for all permutations of things.

I suggest to instead get all installed modules and those namespaces, then all themes and all engines. (from the theme registry).

Hope I got the idea from @Fabianx right :) Patch attached.
I'm actually not sure what's more expensive to process / maintain - the check of every file and the stall file cache or the collection of all namespaces in advance. Currently I assume it depends on the site installation / pattern usage.
However, it sounds cleaner not to fill the cache with "random" file checks.

Found an issue while testing this further.
Theme engines seem not to be tracked in the system table this causes drupal_get_path() to use _drupal_get_filename_fallback() which will log a warning about a moved file.
To avoid this I've changed the way how theme engine tokens are detected.
Now the code relies on the theme info and does a file exists check before adding the path.

Darn, looks like I'm operating in derp mode - there was another issue. Fixed patch attached.

Looks already great. Now that your list is fixed, I would probably cache at least the profiles/ to avoid the file system scan during run-time.

Not really aware what is going on, but I load a theme-external css file from a library through

function my_theme_preprocess_html(&$variables) {
  libraries_load('my_library');
}

in the html.preprocess.inc of my Omega4 subtheme. This was going great, even with the patch from #3, but this external css stopped loading with the patch from #10.

Updated the patch:

1. Added caching for all the "system" tokens.
2. As mentioned by @drupov in #12 the libraries module support was lost - readded.

Not tested, but this looks great to me! Thanks!

"Go" from me too with #13!

Thanks!

Been seeing the same error message spam since the 7.50 update. #13 worked like a charm. – Thanks!

Patch #13 resolved this issue. In my case, I was excluding CSS from a particular module using 'omega_css_exclude', which caused the error message.

Patch in #13 worked for me as well. Thank you! The rtbc status was probably a little early in #14, but since I am now the 4th comment and nobody has been having any problems, commit it? <3

Patch in #13 works for me although it partially failed. I had to apply the patch manually.

+++ b/omega/includes/assets.inc
@@ -37,6 +42,44 @@ function omega_assets_prepare_regex(array $paths) {
+    // Get install profiles.
+    // Same as in install_find_profiles().
+    $profiles = file_scan_directory('./profiles', '/\.profile$/', array('key' => 'name'), 0, TRUE);
+    foreach ($profiles as $profile => $profile_info) {
+      // Add theme engine.
+      $directory = preg_quote(drupal_get_path('profile', $profile), '/');
+      $system_tokens[$profile] = $directory;
+    }
+    cache_set("omega:omega_assets_prepare_regex:tokens", $system_tokens, 'cache', CACHE_TEMPORARY);

Is it necessary to scan the entire profiles directory? Would $profile = drupal_get_profile() do it? If so, do we need the cache (wrt #11)?

Note that the 7.x file_scan_directory() takes only 4 parameters.

We had an issue applying the patch against omega 7.x-4.4 so I rerolled #13. No further changes. please ignore. Unrelated to this issue :)