3

Following the 8.6 upgrade, several of our sites have developed a strange problem. The currently active profile, let's call it foo_profile, is now also listed as a module in config (core.extension.module).

This leads to the backend of the site becoming unavailable at seemingly random intervals, until a cache is cleared. The error that's being logged is:

The module foo_profile does not exist.

Which makes sense, since it's not a module.

I know there were some updates to profiles in 8.6, but I couldn't find anything that would help to explain. settings.php for all sites contained this prior to the upgrade:

$settings['install_profile'] = 'foo_profile';

After getting the exception, I removed that line from one of the sites, just in case. It made no difference, so my conclusion is that having that line or not doesn't affect this problem.

I tried simply removing the non-module from the list:

$conf = \Drupal::configFactory()->getEditable('core.extension');
$modules = $conf->get('module');
if (isset($modules['foo_profile'])) {
  unset($modules['foo_profile']);
  $conf->set('module', $modules);
  $conf->save();
}

That didn't overtly break anything, but now I have warnings when visiting the status report and similar pages:

Notice: Undefined index: name in system_requirements() (line 52 of core/modules/system/system.install). system_requirements('runtime') call_user_func_array('system_requirements', Array) (Line: 403) Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 112) Drupal\system\SystemManager->listRequirements() (Line: 49) Drupal\system\Controller\SystemInfoController->status() call_user_func_array(Array, Array) (Line: 123) Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 582) Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124) Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97) Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 151) Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68) Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57) Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47) Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99) Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78) Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47) Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52) Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23) Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 665) Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Since the problem recurs on its own schedule, I'm not convinced that's done anything to resolve the underlying issue.

So...how do I fix this?

As a bonus, how on earth did this even happen in the first place?

  • Sounds like this should be a bug report... – No Sssweat Oct 1 '18 at 22:05
  • FWIW in my experience it's normal for the profile to show up as a module with weight 1000 in core.extension. I think it did that even before the profile field was added (and it wasn't removed at that point, just refactored into \Drupal\Core\Extension\ModuleExtensionList::doList()). Btw there's a similar-sounding issue on d.o. drupal.org/project/drupal/issues/3000677 – Andy Oct 2 '18 at 10:57
  • @Andy thanks a lot, I haven’t had a chance to come back to this yet but I came to the same conclusion yesterday about the profile being listed in modules since ages ago. I did see that issue on d.o but couldn’t relate it to my situation enough to find it useful. I have other sites upgraded that don’t demonstrate the same problem so I’m guessing it’s not a 8.6 upgrade bug. I have lots of monitoring running on it now so when it next fails I’ll get a snapshot of the site and go from there – Clive Oct 2 '18 at 11:01
  • @Clive rather than unset(), have you tried using $conf->clear('module') or $conf->delete() ? – No Sssweat Oct 2 '18 at 21:47
  • 1
    @NoSssweat Thanks, I haven't, but as Andy mentioned I think I've actually got the wrong end of the stick here. The problem isn't that the profile is listed in the modules, it turns out it always was, the problem now is why something is trying to load it as a module (or why it's temporarily missing if it's supposed to be called as such). But that's probably a bit broad, I'll either edit or delete this soon – Clive Oct 2 '18 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.