Problem/Motivation
Follow-up to: #1081266: Avoid re-scanning module directory when a filename or a module is missing
Users that have upgraded from D6 to D7 have a residual default.profile entry in their system table, which as of 7.50-dev generates the warning:
User warning: The following module is missing from the file system: default. In order to fix this, put the module back in its original location. For more information, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1122 of /includes/bootstrap.inc).
Proposed resolution
Remove entry in system table.
Remaining tasks
- Decide if this needs to be fixed
- Write a hook_update_N() to clean-up the system table
User interface changes
None
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#17 | 2762241-17.patch | 1.49 KB | David_Rothstein |
#9 | 2762241-9.patch | 702 bytes | David_Rothstein |
#8 | 2762241-8.patch | 720 bytes | David_Rothstein |
Comments
Comment #2
MustangGB CreditAttribution: MustangGB commentedComment #3
jeroen.b CreditAttribution: jeroen.b at .VDMi/ commentedSince the following lines are in the commited patch:
I think we should fix this too.
Can you confirm that you have a record for "standard" and that status is 1 and that the value of the variable "install_profile" is "standard"?
If that's the case we only have to delete the old "default.profile".
Comment #4
MustangGB CreditAttribution: MustangGB commented@jeroen.b: Yes to all of that.
Comment #5
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedHm, this is pretty unfortunate - I can reproduce just by updating from 6.x to 7.44, then updating to the latest 7.x. (Updating from Drupal 6 to the latest 7.x directly is OK.)
It is probably the case for whatever profile the Drupal 6 site was using (not necessarily "default"). I'm not sure if we can safely delete any profile that's not in use from the {system} table, but maybe we can....
In the meantime I will at least add this issue to https://www.drupal.org/node/2487215. Unfortunately a lot of people might see this - update.php displays warnings on the screen even if the rest of the site isn't configured to (I think).
I suppose this is basically just exposing a bug that was there all along on sites that upgraded from Drupal 6. It is just now a lot more visible...
Comment #6
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedMaybe it's mostly limited to default though. If you had another profile, you probably needed to keep it in place on upgrade (or else face other bugs)?
Comment #7
jeroen.b CreditAttribution: jeroen.b at .VDMi/ commentedI think it's only limited to default as that profile actually got renamed by Drupal core.
If you rename a custom profile it's your own task to take care of the "migration".
Comment #8
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedWe're thinking of adding the attached patch to the release (not as a final fix, but just to avoid error messages on lots of sites when we know the cause of the bug).
Comment #9
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedOr this one, which is just focused on this issue (the above is for #2761829: Getting drupal_trigger_error_with_delayed_logging errors on Drupal 7.x dev (7.50) too).
Comment #10
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedI like #8, but I feel this should be in its own issue and this one should focus on fixing the thing in 7.51.
I do think we might also be able to do something about the menu router problem, so the work around feels okay to me.
Comment #11
stefan.r CreditAttribution: stefan.r commentedCreated #2762393: Skip error triggering for missing files if the files are empty or "default"
Comment #13
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedBack to active for this issue then. When fixing it for real in this issue, we should remove that @todo (and most/all of that code).
Comment #14
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedAdding as a bugfix target.
Comment #15
JamesOakley>> Comment #13 by David_Rothstein said "Back to active for this issue then"
Does that mean this issue needs to be put back into https://www.drupal.org/node/2487215 - I only found this issue because I looked at the revision history for https://www.drupal.org/node/2487215 and noticed that this had been removed from there now the issue is fixed.
Comment #16
stefan.r CreditAttribution: stefan.r commented@JamesOakley no need, we implemented a workaround in #2762393: Skip error triggering for missing files if the files are empty or "default"
Comment #17
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedCompletely untested, but maybe something like the attached?
I added several conditions to the delete query that might not be strictly necessary, but want to be extra sure we don't accidentally delete a real Drupal 7 profile (e.g. with the same name) that's actually in use somehow.
I'm still curious exactly what happens if you run into this with a different install profile than "default", but I guess sites in that situation already have errors due to #1170362: Install profile is disabled for lots of different reasons and core doesn't allow for that and this issue would just be another error message on top of the existing ones...
Comment #18
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedI would RTBC this, but this needs manual testing. The patch looks good to me though.
Comment #19
wylbur CreditAttribution: wylbur as a volunteer commentedI ran across this error on a site that was imported from D6 to D7. I applied the patch without issue. Ran the update and the missing module messages stopped.
Marking the RBTC.
Comment #20
stefan.r CreditAttribution: stefan.r commentedThanks @wylbur for testing
Comment #22
stefan.r CreditAttribution: stefan.r commentedCommitted and pushed to 7.x, thanks!