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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

MustangGB created an issue. See original summary.

MustangGB’s picture

Issue summary: View changes
jeroen.b’s picture

Since the following lines are in the commited patch:

+  // 'Default' profile has been renamed to 'Standard' in D7.
+  // We change the profile here to prevent a broken record in the system table.
+  // See system_update_7049().
+  if ($profile == 'default') {
+    $profile = 'standard';
+    variable_set('install_profile', $profile);
+  }
+

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

MustangGB’s picture

@jeroen.b: Yes to all of that.

David_Rothstein’s picture

Hm, 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...

David_Rothstein’s picture

It is probably the case for whatever profile the Drupal 6 site was using (not necessarily "default").

Maybe 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)?

jeroen.b’s picture

I 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".

David_Rothstein’s picture

Status: Active » Needs review
FileSize
720 bytes

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

David_Rothstein’s picture

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

Fabianx’s picture

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

stefan.r’s picture

Status: Needs review » Needs work

The last submitted patch, 9: 2762241-9.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Active

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

Fabianx’s picture

Issue tags: +Drupal bugfix target

Adding as a bugfix target.

JamesOakley’s picture

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

stefan.r’s picture

David_Rothstein’s picture

Status: Active » Needs review
FileSize
1.49 KB

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

Fabianx’s picture

Issue tags: +Needs manual testing

I would RTBC this, but this needs manual testing. The patch looks good to me though.

wylbur’s picture

Status: Needs review » Reviewed & tested by the community

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

stefan.r’s picture

Issue tags: -Needs manual testing +Pending Drupal 7 commit

Thanks @wylbur for testing

  • stefan.r committed 00e9ceb on 7.x
    Issue #2762241 by David_Rothstein, wylbur: Missing default.profile from...
stefan.r’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -Pending Drupal 7 commit

Committed and pushed to 7.x, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.