Regression: Allow maintenance to be themable

subscribing

subscribe

earnie: Yeah, the maintenance page can be themed but that would depend on the db being setup and active. Merlins' proposal bypasses the need for a db.

+1 to the idea. I've tried some crazy hacks to get this done before and I've seen others too attempt it too. They are all dirty.

Well I went ahead and applied this and played around a bit. As for testing it is sort of hard to really see much with maintenance mode broken but I did change some stuff up on the install_page.tpl.php and it worked great. No errors or other funny business.

I think it would be a good idea for there to be some documentation perhaps on the Site Maintenance page that says you can customize this by blah blah blah.

This is one of those things that just bugs the crap out of a themer so I'm excited about this getting in along with the other cool theming changes.

Latest version of HEAD - the patch applies with a few offsets but then I get WSOD on install.php and also when trying to do update.php from an older version of HEAD. Reversing the patch let's me proceed. :( Also applying the patch after install and setting the site to maintenance mode gives WSOD as well.

So, I went ahead and applied the patch and copied garland's page.tpl.php to be maintenance_page.tpl.php on a successfully installed (that is just fresh HEAD) site and maintenance mode "worked" but was plain HTML with errors:

    * warning: include(./includes/maintenance_page.tpl.php) [function.include]: failed to open stream: No such file or directory in /Users/addi/Sites/test/includes/theme.inc on line 615.
    * warning: include() [function.include]: Failed opening './includes/maintenance_page.tpl.php' for inclusion (include_path='.:/usr/local/php5/lib/php') in /Users/addi/Sites/test/includes/theme.inc on line 615.

I also did the same (copy page.tpl.php) for the install_page.tpl.php and the installation worked (as well as the maintenence mode) BUT my modified template file (having a I'M AN INSTALL PAGE header) did not show. Just the standard install/maintenance page.

Now that I am sufficiently confused, hopefully you are not. :p

Yep, that does the trick. So nice to be able to edit the maintenance page just like anything else. Kudos!

I think this looks OK. The only thing I'm not sure about is theme.admin.inc (vs theme.inc). I'd actually prefer to put that in a separate patch after some more discussion. The maintenance.inc seems reasonable to me though.

If the patch says:

+    // Fall back to Garland. If Garland doesn't exist, they've deleted files
+    // they should not have and this will crash horribly and that is not our
+    // problem.

... why is the Garland maintenance_page.tpl.php still in the includes directory rather than in the Garland directory?

Just wanted to come in and give a HUGE +1 to this. Drupal is being used in more and more high-profile sites, where "what happens when there's an error" must be carefully managed and controlled as much as the everyday situations. In addition, the rise of distributions and profiles means that branding and/or massaging the install experience is important as well. I know of three clients we've had who required core hacks to achieve this functionality on their sites.

This is much needed. +1. Would RTBC if it weren't already. ;)

Is this going in? As it currently stands, the notes on theme_maintenance_page mentions that the function is *not* themeable but it's a registered function. Seems like it can be overridden.

And it's a bit odd that maintenance.tpl.php is inside the /misc folder for HEAD. Patch doesn't apply anymore. Tried to re-roll but the changes are too big.

I discovered that the maintenance is indeed not overridable. This is a serious regression.

What this patch does is let themers override and it also *does not* depend on the database to function.

I tried to keep it as simple as possible. Only the theme_maintenance_page() function + maintenance.tpl.php file were affected.

The way it works now is this. A handful of directories are checked for.

1. sites/example.com/maintenance
2. sites/default/maintenance
3. misc

From there the maintenance.tpl.php, style.css, logo and favicon.ico is checked for. If no overrides are found then the default behavior is maintained. Minnelli is also checked as a fallback for the logo and style.css.

This is critical IMO.

And a bug..

I was informed by greggles that this would not get in unfortunately.

Here's another anyway just to fix which folders are checked.

1. sites/example.com/maintenance or sites/default/maintenance. Wherever it's installed.
2. sites/all/maintenance -changed from sites/default/maintenance
3. misc

I believe this regression is actually part of http://drupal.org/node/117018 which changed the doxygen to say "note - not themeable"

I don't see in the discussion where it explains why those shouldn't be themeable, though.

Thanks for the pointer Greggles,

It looks like there's a bigger issue with viewing the maintenance page. The registry doesn't read from the db and even weirder is that the coded registry doesn't return proper results.

Here's an example from "page" when viewed in maintenance mode:

"page"]=>
  array(4) {
    ["arguments"]=>
    array(3) {
      ["content"]=>
      NULL
      ["show_blocks"]=>
      bool(true)
      ["show_messages"]=>
      bool(true)
    }
    ["template"]=>
    string(4) "page"
    ["function"]=>
    string(10) "theme_page"
    ["theme path"]=>
    string(4) "misc"
  }

Expected results.. Note that I removed page.tpl.php from garland to show what gets registered outside the theme.

["page"]=>
  array(6) {
    ["arguments"]=>
    array(3) {
      ["content"]=>
      NULL
      ["show_blocks"]=>
      bool(true)
      ["show_messages"]=>
      bool(true)
    }
    ["template"]=>
    string(19) "modules/system/page"
    ["type"]=>
    string(6) "module"
    ["theme path"]=>
    string(14) "modules/system"
    ["theme paths"]=>
    array(1) {
      [0]=>
      string(14) "modules/system"
    }
    ["preprocess functions"]=>
    array(2) {
      [0]=>
      string(19) "template_preprocess"
      [1]=>
      string(24) "template_preprocess_page"
    }
  }

Well, never mind that. I thought it still went through _theme_build_registry even without a db.

Either the patch I posted can be accepted or the _theme_load_registry has to be reworked so it works with and without a db connection. Not sure what to do there.

@merlinofchaos, Yeah, that looks like a lot of work and it'd take me forever to figure out.

I decided to tackle this in a better way. Closer to what Merlinofchaos had in mind but I'll try change as little code as I can. I have a better idea now after a little IRC chatting.

Subscribing.

I'm still trying to get this done. It's not easy, and sorry for the delay.

Subscribing

dvessel, try to share the ideas and whatever code you have. let us help.

Chx:

This definitely needs work but marking CNR just to get your and other opinions.

The patch works. Maintenance page is themable in situations where the site is explicitly set into offline mode. It also works when the database is dead but in order to use a custom theme when the databse is dead, you have to set the 'maintenance_theme' key for the $config array inside your settings.php file.

The theme registry is built only one way. Previously, it would go off on an alternate route to rebuild a custom registry just for the off line page. Now it just builds it anew when the db can't be touched. This is done with the new function "db_is_active()".

The install and update pages will always default to Minnelli.

The function list_theme_engines() has been removed. It seems to serve no purpose since the engine information is already attached to $theme->info. It's counterpart to save the theme engine information into the database was also removed from system_theme_data().

It needs more loving. I've spent too much time on this already so if anyone want's to jump in, it'd be great.

I mean I'll jump back on this later. I'm not abandoning it. :)

Forgot to remove theme_maintenance_page which was replaced with the preprocessor.

Another note, the maintenance template and style sheets where moved to modules/system/ and it's based on the default page.tpl.php file. Previously, it was based on the markup from garland. So, the minnelli maintenance page was added inside Minnelli folder since that's the default.

subscribing

Subscribing

I'm pretty certain there is an existing issue in the documentation component queue for some of these strings, which I'll find and mark as a duplicate of this issue.

I know none of these items -- or very very few of them -- are changes in this patch, but can some string cleanup happen here:

Can this:

We were unable to find any installer profiles. Installer profiles tell us what modules to enable and what schema to install in the database. A profile is necessary to continue with the installation process.

Be something like (change person):

An installation profile was not found. An installation profile provides important configuration data to the Drupal installer, and is required to continue the installation process.

There are several instances where an error message says something similar to this example:

For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider.

Can that last sentence (on all those instances -- there are a bunch of them) be just (no "should probably"):

If you are unfamiliar with these terms, contact your hosting provider.

Where the error messages use "We", like in (change person):

We were unable to use the MySQL database because the MySQL extension for PHP is not installed. Check your PHP.ini to see how you can enable it. For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider.

Is there another alternative?

Just:

The MySQL extension for PHP is not installed. Check your PHP.ini file for information on enabling it. ...

"

Or

We were able to connect to the MySQL database server (which means your username and password are okay) but not able to select the database.

to something like:

A successful connection was made to the database server, but the database could not be selected.

I looked through the patch. Some comments:

- I agree that misc/maintenance.tpl.php and misc/maintenance.css are not well placed, so these could use some move to a more proper place (system module possibly). Their dependency on Minnelli is also evident. I see this patch does add a generic maintenance page and then a minnelli themed one.
- Why not make distinct themes for the install, update, error and offline maintenance pages, reusing the generic theme if no specific is available? That would save us from redoing lots of stuff around the install and update system, which there is no intention to make themeable as it seems, and admittedly, they should not be themeable for consistency.
- There is lots of stuff changed in the patch, both external and internal APIs.
- There was no progress on this issue for weeks.

Let me remind you that this issue is in the critical queue for Drupal 6 which means that as it stands now a Drupal 6 release is hold back in part by this issue. If there is no intention in pursuing this feature anymore, we can close the issue, or move to D7 if there is no progress to be done here in the D6 timeframe.

I agree that restoring the themeability of the maintenance page is desired, and I hope it will be doable in D6, but the release should not be hold back if there is no interest in pushing this forward.

Everyone.. I'm sorry for the delay. I've been swamped with work.

Gábor, It now uses distinct themable function for update, install and maintenance but it shared a good deal of code.

theme_maintenance_page is a templated function while update and install are both "regular" functions but they tap into template_preprocess_maintenance_page to keep all the variables consistent. Also the variables in there mirror what's available inside the normal "page" hook. Again, for consistency.

A new template suggestion is also made available when the database is off-line. This allows the maintenance page to swap the content entirely so site visitors don't see db errors.

BTW, while testing this you may run into a notice about trying to get a property of non-object while installing. It's not due to this patch. system.install uses the "t()" function all over the place before the global $language is available.

+  else {
+    // Force the maintenance theme only when the database is not on-line and
+    // the settings.php file is configured for it. When the database is active,
+    // it will automatically use the active theme.
+    $conf['theme_default'] = variable_get('maintenance_theme', 'minnelli');
+  }

I'm not sure this comment reflect reality. The active theme is something different from the 'maintenance_theme' not? Why should there be a maintenance theme when we're able to load the active theme?

The part in the code where you processes the theme_registry when the database is inactive, could use more documentation. It wasn't instantly clear what was going on in that code or why it matters. It could do with more verbose documentation (that is non-obvious).

+ /* Add favicon */ should be + // Add favicon

I'm not sure I'd quality this issue as 'critical'. Regression or not, critical issues are issues that prevent your Drupal installation from working.

I'm not sure this comment reflect reality. The active theme is something different from the 'maintenance_theme' not? Why should there be a maintenance theme when we're able to load the active theme?

Dries, that's just passing in what's set inside settings.php when the db is inactive. It must use 'theme_default' so it properly initializes the theme within init_theme().

drupal_maintenance_theme() is run in only these cases:
1.) install page. -to force Minnelli.
2.) update page. -the same as install.
3.) db dies. -to read what's set as the 'maintenance_theme'.

When the site is set to off-line mode and the db is working, drupal_maintenance_theme() isn't run (I removed it). drupal_site_offline() is called and the theming system is intact so it will work without problems.

I'll get a patch up shortly.

Okay, _theme_load_registry_offline() was moved into the main _theme_load_registry(). I realized it wasn't needed. Not sure if the docs are what you wanted in here. Hope it makes sense.

The other issues I changed. the comments using /* */ was simply copied from template_preprocess_page() so I changed that too to what you suggested.

Subscribing. Would this be possible to backport, or is it 6.x specific?

ksenzee, the theming system between the two versions is very different so it won't happen.

Any further feedback would be nice. Dries, Gábor: if there's anything else in here that doesn't seem satisfactory then please tell me. I'll try to clarify or fix it ASAP.

And anyone else looking over this, please review and verify that it works.

This may have been broken by the recent requirements changes, but when the patch is applied, error messages and notices during the installation process no longer appear. That's pretty critical since it means people get no indication of why they can't install. I'm taking a look to see if I can track it down but am not sure I'll have time to fix it.

Eaton, I accidentally flipped the 'show_message' flag to false inside theme_install_page(). That's a simple fix.

I'm in the process of reworking some areas so I'll roll it into the next patch.

The previous patch would use the currently selected theme when in offline mode. I changed this since some themes might not be setup for it and break the layout completely.

In drupal 5, it had to be themed explicitly, so, it's the same in here. First the theme must be explicitly enabled for off-line mode but this time it must be set through settings.php + the theme overrides if the theme needs it.

Pure CSS themes would just have to enable it through settings.php since the markup from maintenance-page.tpl.php and page.tpl.php is very similar.

I also moved alot of the functions into a new theme.maintenance.php.

Just took this through its paces and it deals gracefully with a dead database and other similar situations. The approach appears to be clean and tidy, and I know of a number of our clients who will be thrilled that occasional DB issues don't result in a big splatter of 'stock theme' over their carefully tailored site branding...

Great Eaton! Thanks for your time. :)

Minor doc cleanup on this one but it's exactly the same.

Oh, and did I mention that theme inheritance work too now? Not sure I did. It was restricted before.

So if we wanted, we can clean up Minnelli a bit so it inherits Garlands styles instead of importing them. I think there was a problem with that.. Not sure. My mind has been on another project.

Thanks for your patients.

Given the size and timing of this change, I wrote Dries a mail to check back and review the patch. I definitely like this feature being kept, and proposed fixing this in other issues, but at the same time, the D6 release process went ahead a lot in the meantime.

A huge +1! As mentioned before, corporate websites can't live without this.

/**
 * Enables use of the theme system without requiring database access.
 */
function drupal_maintenance_theme() {

Added one-line descripiton (API).

/**
 * Note: This setting does not apply to installation and update pages.
 */

Added this note to settings.php and moved phpdoc block right in front of the setting.

Was list_theme_engines() in theme.inc intentionally removed? Just curious. There is no reference in core.

Note: I don't know how to remove files in a local working copy, so I wasn't able to remove misc/maintenance.css and misc/maintenance.tpl.php in this patch.

Earnie: Grrrhm.
Earnie, sun: read the docs! http://drupal.org/patch/create

Sorry for being dumb. Let's get back to focus.

merlinofchaos: Maybe you have not seen but I have even postponed some API modifying drag and drop issues, before Dries came and "approved" them (getting them back to the 6.x queue), and also put a now RTBC looking drag and drop issue to his consideration because of the same reasons: big API breaking changes without Dries' prior approval. That's not about how flashy an issue is but how late it is going to be applied in the cycle. I did not receive privileges to say yes to these without consulting Dries.

I reviewed this patch, found it nice for my taste, and wrote Dries an email yesterday afternoon, but did not receive a reply since then. Dries seemingly being mostly out of time to review bigger patches now, I slept one more on this patch, and being a low level issue which is not at all possible to fix in contrib, I decided to commit it.

Please understand that I am trying to watch the best interest of the community, and that sometimes conflicts with the interest of (your) customers. I would not like to offend highly valued people who work hard on completing a big fix they think is important. But at the same time I would not like to offend others who postponed their important fixes to D7 understanding that the community needs to agree on common rules on deadlines and focusing on stabilizing what is already there instead of looking into what is missing, to have a release in a reasonable timeframe. Additionally I do not like to provide grounds for finger pointing like "but you accepted drag and drop patches, and ours is just as important" (as demonstrated above) or "but you accepted the maintenance theming patch". This can go on forever if the focus is not agreed on.

So much for the background. As I said, I liked what I have seen in this patch, and would love to see you fine folks in the criticals issue queue (http://drupal.org/project/issues?projects=3060&versions=97368,184399,175...), now that this is resolved. There is a nice small theming bug there which would fly if you would take a look and approve / comment on the suggested fix: http://drupal.org/node/194026 (although all the other issues are just as interesting).

Thanks for all your time making Drupal 6 better, it is all highly respected.

OK, this made the install theme buggy when the site is already installed, but the DB is not populated. Reproduce:

- install Drupal
- drop the database
- create the database empty
- visit install.php

All you get is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Choose language | Drupal</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="shortcut icon" href="/profilednd/misc/favicon.ico" type="image/x-icon" />
    <link type="text/css" rel="stylesheet" media="all" href="/profilednd/modules/system/defaults.css" />
<link type="text/css" rel="stylesheet" media="all" href="/profilednd/modules/system/system.css" />
<link type="text/css" rel="stylesheet" media="all" href="/profilednd/modules/system/system-menus.css" />
<link type="text/css" rel="stylesheet" media="all" href="/profilednd/modules/system/maintenance.css" />
        <!--[if lt IE 7]>

This is an edge case, but might uncover other bugs introduced with this. Previously, the installer was possible to be used to populate the tables when the DB was cleaned as said above. Not good.

With display_errors = TRUE:

<br />
<b>Warning</b>:  Table &#039;installer.system&#039; doesn&#039;t exist
query: SELECT * FROM system WHERE type = &#039;theme&#039; in <b>/Users/gabor_h/Desktop/Websites/installer/includes/database.mysqli.inc</b> on line <b>167</b><br />
<br />
<b>Notice</b>:  Undefined index:  minnelli in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.maintenance.inc</b> on line <b>61</b><br />

<br />
<b>Notice</b>:  Trying to get property of non-object in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.inc</b> on line <b>93</b><br />
<br />
<b>Notice</b>:  Trying to get property of non-object in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.inc</b> on line <b>390</b><br />
<br />

<b>Notice</b>:  Trying to get property of non-object in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.inc</b> on line <b>390</b><br />
<br />
<b>Notice</b>:  Trying to get property of non-object in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.inc</b> on line <b>390</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /Users/gabor_h/Desktop/Websites/installer/includes/database.mysqli.inc:167) in <b>/Users/gabor_h/Desktop/Websites/installer/includes/common.inc</b> on line <b>141</b><br />

<br />
<b>Warning</b>:  Table &#039;installer.system&#039; doesn&#039;t exist
query: SELECT * FROM system WHERE type = &#039;theme&#039; in <b>/Users/gabor_h/Desktop/Websites/installer/includes/database.mysqli.inc</b> on line <b>167</b><br />
<br />
<b>Notice</b>:  Undefined index:  minnelli in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.inc</b> on line <b>881</b><br />

<br />
<b>Notice</b>:  Trying to get property of non-object in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.inc</b> on line <b>893</b><br />
<br />
<b>Notice</b>:  Trying to get property of non-object in <b>/Users/gabor_h/Desktop/Websites/installer/includes/theme.inc</b> on line <b>902</b><br />
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Choose language | Drupal</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="shortcut icon" href="/installer/misc/favicon.ico" type="image/x-icon" />
    <link type="text/css" rel="stylesheet" media="all" href="/installer/modules/system/defaults.css" />
<link type="text/css" rel="stylesheet" media="all" href="/installer/modules/system/system.css" />
<link type="text/css" rel="stylesheet" media="all" href="/installer/modules/system/system-menus.css" />
<link type="text/css" rel="stylesheet" media="all" href="/installer/modules/system/maintenance.css" />
        <!--[if lt IE 7]>
      <br />

<b>Fatal error</b>:  Call to undefined function  phptemplate_get_ie_styles() in <b>/Users/gabor_h/Desktop/Websites/installer/themes/garland/maintenance-page.tpl.php</b> on line <b>23</b><br />

Great! this is finally in. :)

Previously, the installer was possible to be used to populate the tables when the DB was cleaned as said above. Not good.

Wow, I never knew this. I'll look into this edge case..

Gábor, thanks for your hard work.

The problem is with how list_themes() was modified. The patch does a check with db_is_active() so simply dropping the tables is not caught.

Looks like I'll have to revert list_themes() and separate out the part listing the themes without calling the database. It'll be a simple fix.

Well, I opted to just check for the table. Not sure it's the best way to go.

list_themes() is called in many places but the call from theme_get_settings() prevented me from reverting list_themes.

Great, this looks sensible to me. Thanks for the fix, committed.

If list_themes() is called in many places, we should perhaps cache the database check. (first patch)

Or, at least add some notes to this non-obvious check. (second patch)

The theme list is already cached so caching the db check isn't needed. It's only checked once unless it needs a refresh.. not a common thing.

More docs the better but I still don't think that's clear.

... + if settings are configured but database is empty.

Now one would ask, why would this situation arise? I know now but if I didn't I'd have no clue.

@dvessel: I regularly encounter this situation when "re-setting" a local Drupal test site, for example. This is all about an edge case, absolutely. So I'd say, it's sufficient to just explain why we're doing this second check without giving any other reason than the one included in the patch.

This broke updates badly.

webernet: Please elaborate. I tried to run update.php (although without actual updates to run) and seen the progressbar go through to 100%, and then a message that my site is up to date, just as before. I would not commit this patch, if there would be an obvious bug which does not need explanation.

- First load of update.php throws a fatal error.

<!--[if lt IE 7]>
Fatal error: Call to undefined function phptemplate_get_ie_styles() in /themes/garland/maintenance-page.tpl.php on line 23

- Not all updates are run -- only those for system module.

- Updates fail at system update 6027.

An HTTP error 200 occurred. /update.php?id=1&op=do

Uh, huh. This could very well be closely related to the "developer edge case" I found. The error message is the same. Seems like although the database is set up, the system table is there, this code does not play nice with the tables not updated yet. Basically, it should use the file based theme code, not the database based theme code.

system_update_6027() looks like modifying both the global $theme and $custom_theme, and although $theme is restored, $custom_theme is not. So the theme is modified in the update code, and again, that breaks the update. Looks like the $custom_theme needs to be restored.

Crap.. it's because of the use of module_list() inside _drupal_maintenance_theme(). It needs to be more selective.

It's needed for off-line mode and dead db's. install.php repeats that function. I didn't realize that update cannot have it run that way.

Sorry.. patch coming right up.

Okay, I tested and it works for me.

Removed all the redundant calls to drupal_maintenance_theme() from install.php also. All the install functions go through install_main() so this is safe.

The db table check from the previous fix was swapped for the "MAINTENANCE_MODE" constant. Just to be on the safe side, have it read from the file system even when updating.

I also had to add in $theme->status to prevent notices. It didn't happen before due to the order it was run. Without it, notices occur from system_menu() where it registers theme config paths.

er, broken on install..

I mean, revisiting the install page after it's already been installed caused a fatal error..

Works now.

Awaiting some testing. Would love to see what webernet has to say on this.
Edit: funny crosspost. :)

#87 seems to fix things for me after a quick test. Needs further testing/review though.

I tested this on a 4.6 -> 6 upgrade which worked before this patch (yes, 1 have 2(!) custom modifications in the update code to make this run well, and a few lines of DB preparation SQL code). Also worked with the patch, so it seems the update is fixed. Committed, thanks.

Hooray for all of us on this one. Good work, gang!

Indeed.. I only wish I could have been more focused. Bad timing when Merlin rolled his original patch and now. I wasn't around when it initially appeared but all wasn't lost since I learned from his example. Not exactly the same but still, it gave me a clue.

Time to let this issue die, finally..

I hope it's OK etiquette to resurrect this thread. I wrote about this issue on the developer's email list and I wanted to post my patch somewhere. I submit it for consideration for Drupal 5.x, but I understand if this get's resolved as won't fix, since it appears to be addressed differently in Drupal 6.

My problem is that I needed the maintenance pages to be custom branded, especially when the database is unreachable. The attached patch to bootstrap.inc solves the problem. With the patch in place, I can write something like the following in my settings.php. This gives me control of the maintenance pages.

$conf['custom_maintenance_theme'] = 'custom_maintenance';

function custom_maintenance_maintenance_page($content, $messages = TRUE, $partial = FALSE) {
  // My custom code goes here (replaces theme_maintenance_page from theme.inc)
}

It looks reasonable but the install and update pages could have problems with custom themes. Accounting for that would require further changes. Alas, it is a feature so I doubt this would happen.

hook_system_info_alter() was never documented. Please fix.

http://api.drupal.org/api/function/hook_system_info_alter

Looks like this patch may have caused a new issue: http://drupal.org/node/281997

EDIT: Disregard. Further investigation suggests a function provided by the result of this issue may be the first victim of a different bug and not a cause of the problem in the other issue.