Closed (fixed)
Project:
Drupal core
Version:
8.0.0
Component:
install system
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
9 May 2015 at 13:08 UTC
Updated:
3 Feb 2017 at 02:01 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
imiksuI can confirm this.
Comment #2
benjy commentedComment #3
fgmSame here on Ubuntu 12.04 LTS with PHP 5.6, opcache enabled, no apcu enabled.
Comment #4
eiriksmFor completion, me too:
Tested on Mac OS x with PHP 5.5.20 and PHP 5.6.7 (both on on the CLI).
Comment #5
sweetchuckSame here on
openSUSE 13.1
PHP version 5.4.20 (official)
PHP version 5.5.21 (custom compile)
php ./core/scripts/run-tests.sh --url http://5521-dev.d8-dev.localhost:1080 --color --verbose --die-on-fail --module mymoduleComment #6
stefan.r commentedWe need to do the same thing in InstallStorage as we do in ExtensionInstallStorage, untested patch attached
Odd that our testbot didn't catch this...
Comment #7
sweetchuckPatch #6 solves the problem. (All the PHP warnings are disappeared)
Comment #8
jeroen.b commentedPatch #6 solves it for me too. Think we can RTBC this directly after testbot completes.
Comment #9
eiriksmYup. Fixed it for me too, and patch looks good
Comment #10
fgmWe probably want to check that this call to drupal_get_filename() actually succeded.
Comment #11
stefan.r commentedIt should always succeed considering all it does is prime the cache right?
Comment #12
jeroen.b commented@fgm That call is to prime the static cache of drupal_get_filename, so to set the path. The call always succeeds.
Comment #13
alexpottCommitted 081f58e and pushed to 8.0.x. Thanks!
Comment #16
tormiSame kind of error again with 8.0.0-beta12 on Pantheon (PHP 5.5.24):
Comment #17
-enzo- commentedSame error reported in #16
Comment #18
bradjones1Don't re-open long-closed tickets. Start a new ticket if you believe you have a regression or new issue.
Comment #19
charginghawk commentedSince #1081266: Avoid re-scanning module directory when a filename or a module is missing just hit D7, this issue has shown up again there. We may need to port this fix.
Comment #20
David_Rothstein commented@charginghawk, what are the steps to reproduce this in Drupal 7? (Probably better to create a new issue and link to it from here.)
Comment #21
devin carlson commentedI'm also seeing this with custom distributions after updating to 7.50.
Steps to duplicate: attempt to install the latest -dev of Drupal Commons which bumps core up to 7.50.
https://simplytest.me/project/commons/7.x-3.x
Failing tests: https://travis-ci.org/acquia/commons/jobs/143737454#L614
When checking a profile's requirements,
drupal_check_profile()creates an array of profile module dependencies. It then adds the the profile module as a dependency of itself, in order to see if it has requirements.module_load_install()is then called for each of the modules in the array, in order to load their .install files before checking if they implementhook_requirements().Then
module_load_install()callsmodule_load_include()which callsdrupal_get_path()and finallydrupal_get_filename().The issue is between the interaction of
module_load_include()anddrupal_get_path().module_load_include()doesn't account for the fact that a module could be a profile and callsdrupal_get_path('module', $module)with 'module' hard-coded. This leads todrupal_get_path()callingdrupal_get_filename()with $type=module instead of $type=profile, resulting in the profile-specific logic indrupal_get_filename()getting skipped so it is unable to locate the file (all fallback detection methods don't work as the profile module hasn't been installed yet, the function wasn't passed the full filename, the $files static hasn't been primed with the profile path, etc).The solution committed to D8 also works here. Instead of changing the way the profile requirements are checked, altering module_load_include() to account for profiles, or adding a profile_load_include() function, the $files static of
drupal_get_filename()could be primed with the path to the profile.Comment #22
fabianx commentedWe usually don't do backports this way anymore, so #21, if you could create a new issue, that would be appreciated.
Reviewing the code: RTBC - might need a test, though I don't think we had test coverage for that in D8 either.
Comment #23
David_Rothstein commentedThat doesn't look like a bug in core - rather it's a bug in a patch that Commons in running: #1971072: Install profiles cannot list their own requirements in drupal_check_profile. I tried unapplying that patch and the issue wasn't reproducible.
(See also https://www.drupal.org/node/1081266?page=1#comment-10816284 where this was previously discussed.)
Comment #24
charginghawk commentedBTW, people running into this issue can refer to: How to fix "The following module is missing from the file system..." warning messages
Comment #26
cilefen commentedComment #27
donquixote commentedThis issue fixes just one scenario where this warning occurs.
I think it would be wise to have
- One parent issue with the issue title "(meta) The following module is missing from the file system...", with links to other issues, but no patches.
- Multiple issues, with patches, that fix specific scenarios where this occurs. These issues should have more specific titles, such as "drupal_verify_profile() can cause missing module warnings."
With this in mind, this issue probably should be renamed to "drupal_verify_profile() can cause missing module warnings.". I will not rename it myself, because I don't know if others agree, and I have not completely read all the comments in this issue.