The new method for handling missing modules in Drupal 7.50 seems to trigger errors from Omega as well, like these:
User warning: The following theme is missing from the file system: ctools. In order to fix this, put the theme back in its original location. For more information, see the documentation page. i _drupal_trigger_error_with_delayed_logging()

Members fund testing for the Drupal project. Drupal Association Learn more


granholm created an issue. See original summary.

granholm’s picture

Title: User warning: The following theme is missing from the file system: ctools (and others) » Modules are listed as missing themes in Drupal 7.50, triggers user warnings.
granholm’s picture

This patch will prevent the scan from triggering errors.

stefan.r’s picture

Status: Active » Needs work

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

czigor’s picture

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/

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

czigor’s picture

Status: Needs work » Reviewed & tested by the community

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.

Fabianx’s picture

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).

das-peter’s picture

Status: Reviewed & tested by the community » Needs review
3.27 KB

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.

das-peter’s picture

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.

das-peter’s picture

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

Fabianx’s picture

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.

drupov’s picture

Status: Needs review » Needs work

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) {

in the 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.

das-peter’s picture

Status: Needs work » Needs review
4.11 KB

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.
Fabianx’s picture

Status: Needs review » Reviewed & tested by the community

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

drupov’s picture

"Go" from me too with #13!


Bird-Kid’s picture

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

Chris Burge’s picture

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.

aschiwi’s picture

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

criscom’s picture

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

olli’s picture

+++ b/omega/includes/
@@ -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.