Document that maintenance_theme conf in settings.php only works when the database is offline

.

Jeff: When I read the above (which is in default.settings.php), it looks like it's saying that $conf['maintenance_theme'] should be used when:
- Database is off-line
- You have set the site to maintenance mode

Are you saying that this is not working? Your original report seems to b emissing a "not" somewhere, and I'm not sure what behavior you have observed...

I've just stumbled across this as well. It seems as if it simply doesn't work. Nothing happens when you change $conf['maintenance_theme'] in settings.php. The maintenance theme is enabled, but the default theme is still used for maintenance pages.

Like Jeff mentioned, if I make the DB fail, the maintenance theme I've set in settings.php is used.

Sounds like a code bug then. Thanks for the confirmation and explanation!

Subscribing

Hmm I'm going to downgrade this from major for the following reasons

It's my understanding that this setting is so that you can have your main site theme used for maintenance instead of Seven (or Garland in D6).

It sounds like people on this issue are trying to set a completely different theme for site maintenance from their main site theme, which might be a valid use case, but I don't think the original system was designed for that at all.

So, it's not supposed to be possible to have a maintenance theme that is different from the site theme? It was possible in D6 using that setting in settings.php

Our use case is for a lot of smaller sites that we produce. In order to have one well made maintenance page across all mini-projects rather than having to custom theme it for each project we produced a small low profile maintenance theme that works well no matter which site uses it.

Although it was possible to specify a different maintenance theme in D6, it never really worked reliably. Things would break badly if there was any code on the site that caused the theme system to be initialized too early in the page request. (See #219910-14: Calling theme function from hook_init() interferes with administration theme as well as other comments in that thread - there are actually a host of related issues not just involving the maintenance theme.)

In D7/D8, there is code to deliberately initialize the theme system early on in every page request, so I assume that's what causes it to not work all the time there.

Here's a simple patch that seems to fix things. I suspect it might not be quite as simple as this, but testing it out it works fine.

To really solve this properly we might need something like #981654: Use several themes during the same page request, though.

Hmm, do we have test coverage for maintenance mode?

Note that the Drupal 8.x patch will need to be rerolled, because the core directory structure for Drupal 8 has now changed. (For more information, see #22336: Move all core Drupal files under a /core folder to improve usability and upgrades). When the patch has been rerolled, please set the issue back to "Needs Review."

Tagging as novice for the task of rerolling the Drupal 8.x patch.

Just rerolling the patch with the right directory structure.

Thanks!

I tried testing this by purposefully putting wrong db info into my settings.php file, but I got a "Uncaught exception thrown in shutdown function" error instead of the maintenance theme. That's how I used to test it in D7. Is this a new bug? Or do I just need to change my testing methodology?

Sorry if I'm just adding noise but the patch above looks a bit convolute to me (maybe I'm just looking it from the wrong perspective), although it fixed the issue.

The attached one also works and looks like the right fix to me.

@JohnAlbin:

I don't get that exception with wrong db info and this patch applied, but I get:

PDOException: SQLSTATE[42000] [1049] Unknown database 'wrong_db' in lock_may_be_available() (line 167 of [...]\webroot\includes\lock.inc).

with the maintenance theme I set (seven). Looks like the correct behavior to me.

@plach:

Setting the maintenance theme for offline databases using $conf['maintenance_theme'] = 'themename'; only seems to work for themes in /themes folder. Using Bartik, Garland etc works as intended.

However, If the theme is in sites/all/themes or in a profile, such as /profiles/profile-name/themes it doesn't work. I did notice however, that If I copy "seven" to sites/all/themes, rename it, and make it into a subtheme of seven, it actually works. It's all very very strange.

Are you sure this don't work with sites/all/themes? The profile dir will work only if the profile is the actually installed one.

@plach, does your patch work in the case where the database is online but a fatal error occurs for other reasons? (For example, when a page callback throws an exception.) It doesn't look like it would.

It might make sense to go with your approach as an interim fix, though, since it certainly looks like it would deal with the "site deliberately taken offline" situation. On the other hand, the current codebase already has a "halfway" fix in place, and per @catch's comment in #6 the current split actually does make some sense... Drupal always tries to get the theme from the database (corresponding to the one that was chosen in the user interface), and only consults the settings.php variable when the database is unreachable.

@plach According to my test it doesn't work. Regarding the profile: the profile the theme was in was installed and active. However - how is Drupal supposed to know which profile is installed when the database connection is failing? If the settings.php setting should apply to all scenarios where the database is failing then it has to be able to find a theme that is placed in the correct spot (i.e profiles/xxx/themes, themes, sites/xxx/themes) regardless of whether it's enabled or the default theme.

Found this thread trying to figure out why $conf['maintenance_theme'] in settings.php was not working. Hoping to revive this since we need it to work in D7 for our university installation where we want to set a maintenance theme page no matter what theme is being used. Would be happy to submit a D7 patch since the menu.inc code looks the same. Thanks.

Reading the above, this seems like a documentation issue. The comment in settings.php reads:

"This applies when the site is explicitly set to maintenance mode through the administration page or when the database is inactive due to an error."

It sounds like that's not true -- it's only triggered when the database is inactive. If so, at a minimum this description in the 8.x and 7.x default.settings.php file should be updated.

Personally I'd love to be able to set a maintenance-specific theme, but it sounds like there are technical limitations to doing that, at least in core, as the patches above try to. But we should at least have a description of what this setting does accurate for D8.

Related issue #1829170: Convert the Maintenance Theme variable to settings

Not knowing a thing about themes I took a dive into this and learned the following:

This if block in common.inc that is to set the maintenance theme always fails so drupal_maintenance_theme() never executes. So I changed like so to see what happens.

  if (function_exists('drupal_maintenance_theme')) {
    \Drupal::theme()->resetActiveTheme();
    drupal_maintenance_theme();
  }

then drupal_maintenence_theme executed but after clearing cache and reloading the home page the theme was still not what was set in $settings['maintenance_theme']. I removed my changes to the code.

Then I learned that there is a themeNegotiator and the \Drupal\Core\Theme\DefaultNegotiator::determineActiveTheme was being called and that always retrieved the default system.theme which was not the maintenance theme in setttings.php.

The only way I got this to use theme set in $settings['maintenance_theme'] was:

  public function determineActiveTheme(RouteMatchInterface $route_match) {
    if (\Drupal::state()->get('system.maintenance_mode')) {
      return Settings::get('maintenance_theme');
    }
    return $this->configFactory->get('system.theme')->get('default');

What should be done here? Is this a documentation problem or not?

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.