User warning: The following core is missing from the file system: drupal. In order to fix this, put the core back in its original location.

https://www.drupal.org/node/2487215 try this may by helpfull

did you try drush updb ? it looks like db have some tables from your modules and can't find them.

#6: The easiest is to hack core and add a backtrace to when we generate the message:

  $e = new Exception();
  $backtrace_string = $e->getTraceAsString();
  trigger_error_delayed('The following module ...' . $backtrace_string, E_USER_ERROR);

Then you can see who calls drupal_get_filename() with the modules that don't exist.

We are considering always adding a backtrace for core itself, too.

Hi,

I have similar issue on one of client's site. I get it resolved by doing two things over the site:

1) https://www.drupal.org/project/module_missing_message_fixer
2) After rebuilding the registry(https://www.drupal.org/project/registry_rebuild), i got it sorted out.

All the best!!

Along the same lines,
here is a test scenario that affects 7.50 and behaved differently in all previous versions of Drupal 7:

call

$test_path1 = drupal_get_path('module', 'some_name_xyz_anything_but_a_module_name');

//OR call

$test_path2 = drupal_get_path('theme', 'some_name_xyz_anything_but_a_theme_name');

Both calls will get an error , however prior to 7.50 (version 7.44 and previous) the result either $test_path1 or $test_path2 would have been NULL or something similar without any error message. But now it IS an error.

I am a maintainer of the 'sassy' module and had to make some workaround to get it to pass simpletest on jenkins.

The system table never ever contained a record of 'some_name_xyz_anything_but_a_module_name' , it seems to me that 7.50 bootstrap is going an extra mile here, might have to do some performance profiling with xhprof to compare system calls on this type of a thing.

Curious. I might have some time the next few days to dig a bit more into this.

For those interested, see this commit and the previous two

*edit* issue version is 7.50 not 7.5

@joseph.olstad, see the change record - there is now a new parameter to drupal_get_filename() that can be used to restore the previous behavior of not triggering a warning message, if you're calling the function in a scenario where you expect the files to sometimes not exist. (And since drupal_get_path() is a simple wrapper around drupal_get_filename(), you could switch to that if you wanted.)

Just be aware that if you call these functions on something that might not exist, it will sometimes initiate a filesystem scan (not as often as it did before Drupal 7.50, but still sometimes) so you probably don't want to do that in performance-critical code.

@David_Rothstein, excellent (and timely) tip, I looked at the change record and it all makes sense now, very helpful! I'll make the necessary changes to replace the workaround I had done.

Test scenario:
Drupal 7.50
sassy version 7.x-2.17 (older version, prior to my workaround for this bug)

I'm using various core patches to D7 7.50 and D7 7.44 .

- projects[drupal][patch][405360] = https://www.drupal.org/files/issues/aria-describedby_2.patch
- projects[drupal][patch][460408] = https://www.drupal.org/files/issues/menu-access_unpublished-nodes_460408-157.patch
- projects[drupal][patch][728702] = https://www.drupal.org/files/issues/install-redirect-on-empty-database-728702-36.patch
- projects[drupal][patch][865536] = https://www.drupal.org/files/drupal-865536-204.patch
- projects[drupal][patch][911354] = https://www.drupal.org/files/911354-drupal-profile-85.patch
- projects[drupal][patch][1443342] = https://www.drupal.org/files/drupal-1443342-1-inline-file_uri_scheme-in-file_stream_wrapper_uri_normalize.patch
- projects[drupal][patch][1470656] = https://www.drupal.org/files/drupal-1470656-14.patch
- projects[drupal][patch][1710656] = https://www.drupal.org/files/drupal-1710656-3-skip-hidden-menu-items-D7.patch
- projects[drupal][patch][1772316] = https://www.drupal.org/files/drupal7-allow_change_system-requirements-1772316-18.patch
- projects[drupal][patch][2289867] = https://www.drupal.org/files/issues/D7_port_fix_w3c_url_validation_html5_changes-2289867-1.patch
- projects[drupal][patch][2339447] = https://www.drupal.org/files/issues/2339447-73-optimize_drupal_find_theme_functions.patch

In my test, I made this change on sassy.module
from:

drupal_get_path('module', $namespace);

to:

drupal_get_path('module', $namespace, NULL, FALSE);

AND also this change

from:

drupal_get_path('theme', $namespace);

to:

drupal_get_path('theme', $namespace, NULL, FALSE);

and simpletest gave me this on D7 core v7.50 (same result as unmodified sassy 7.x-2.17 ):

Enabled modules: sassy_compass, sassy
The following module is missing from the file system: utilities. In order to fix this, put the module back in its original location. For more information, see the documentation page

Similar error messages over and over again about 19 times

Then I tested on Drupal 7.44

ran simpletest with the same code

These "missing from the file system" do not occur on Drupal 7.44 using sassy 7.x-2.17

In order to fix this, upgrade to 7.x-2.18 of sassy , however the fix was not as described in the "change record" . (or how I expected it to be)

Anyhow, for now the sassy module latest release has a workaround that works. This doesn't appear to be a problem with the core patches we're using. Curious still why this is happening, maybe I missed something in the change record.

#13: You need to use drupal_get_filename() instead of drupal_get_path() ...

ah ok, Thanks Fabianx, I will try that

**EDIT**
Hmm, I ran some more tests, ok, drupal_get_filename seems to do the job when called with the extra params... seems to do the trick, I'll run a few more tests.
**EDIT**

Just fyi: I made a new release for sassy 7.x-2.19 with the help of the "change record"

It passes all simpletest tests on jenkins despite looking a bit odd.

see commit diff

*EDIT*
after 7.x-2.19 I released 7.x-2.20 a couple days after, using the (bool) and checking if the module exists before calling drupal_get_path
same result, it works either way, passes simpletests, does what its supposed to.
*EDIT*
Thanks

Unless we get more information, this is most likely not a core bug.

Thanks for the updates, #20, #21!

I am fine with leaving this in the core queue for others to find. :)