The site off-line page is un-themed. Is this by designed? It seems odd off-line page is un-themed but the _db_error_page() is.

Comments

wretched sinner - saved by grace’s picture

Category: feature » support
Status: Active » Fixed

Have a look at http://drupal.org/node/195435. It is a bit trickier to theme the maintenance page, due to when you will use the maintenance page, but it is doable!

mattyoung’s picture

I've no idea what's going on. I did set 'maintanence_theme' in settings.php and it works for database error page. But site off-line is always un-themed.

I don't understand what's going on. theme('maintanence_page', ...) is called and the built-in 'maintanence-page.tpl.php' are actually a full page. But in off-line mode, only a plain text page is shown.

mattyoung’s picture

I figure out what's wrong. It's a bug in the garland theme. It doesn't have phptemplate_preprocess_maintenance_page(&$variables) in its template.php file. So the required variables needed in the maintenance-page.tpl.php are not set, resulting in a plain page. If you do a view page source, that page actually has all the divs. Just that they are all blank.

Once I add the following to garland's template.php file, site off-line page display correctly:

function phptemplate_preprocess_maintenance_page(&$variables) {
  template_preprocess_maintenance_page($variables);
}
wretched sinner - saved by grace’s picture

Component: base system » Garland theme
Category: support » bug
Status: Fixed » Active

I would caution about modifying core template files, as the changes will get wiped out next time you upgrade. I'll move this to the main queue as a (possible) bug and get those in charge of Garland to have a look.

mattyoung’s picture

After some more research, I found that just do:

include_once './includes/theme.maintenance.inc';

at the end of Garland's template.php in enough to fix this problem. The reason is the theme registry build look for the existence of a function template_preprocess_maintenance_page(). If one exists, it's included in maintenance_page() theme hook preprocessor function.

Defining this function:

function phptemplate_preprocess_maintenance_page(&$variables) {
  template_preprocess_maintenance_page($variables);
}

work also because theme registry build also look for the existence of phptemplate_preprocess_maintenance_page() and since we define one, it's included in the preprocessor hook list. In normal page execution, template_preprocess_maintenance_page() is undefined because it's defined in theme.maintenance.inc and it's never require/include in normal page render. But when in off-line mode, drupal_maintenance_theme() is called and that's defined as this in bootstrap.inc:

function drupal_maintenance_theme() {
  require_once './includes/theme.maintenance.inc';
  _drupal_maintenance_theme();
}

I don't know which method is better. I suspect defining phptemplate_preprocess_maintenance_page() is probably better because in normal operation, theme.maintenance.inc does not get included, saving some parsing.

BTW, setting maintenance_theme = 'garland' in settings.php and when database is bad, that page is displayed correctly with Garland's tempalte.php as is now. But that's a special case: drupal_maintenance_theme() is called early on, causing theme.maintenance.inc to be require_once and template_preprocess_maintenance_page() comes into existence. So when the theme registry is then build from scratch, it's included as preprocessor hook.

dvessel’s picture

Status: Active » Postponed (maintainer needs more info)

I'm not sure what isn't being themed. I tried with Garland and it seems to work just fine.

This point may be obvious but just in case it was missed. -You have to be logged out to have the maintenance theme take over.

dvessel’s picture

BTW, all the variables for Garlands page.tpl.php file and maintenance-page.tpl.php should be available. Some for maintenance-page.tpl.php might be just an empty string but that was done to keep the two templates very similar.

As long as Garland wasn't modified, it should work just fine.

mattyoung’s picture

It definitely doesn't work for me and I don't see how it should work. With Garland's template.php as is, neither of these function exist when the theme registry is built:

template_preprocess_maintenance_page()
phptemplate_preprocess_maintenance_page()

So the theme registry will not have the necessary preprocess function. Just use the devel module to dump out the theme registry, you will see this for the maintenance_page hook is like this:

maintenance_page
(Array, 7 elements)

  • template
    (String,
    16 characters
    )
    maintenance-page

  • path
    (String,
    14 characters
    )
    themes/garland

  • type
    (String,
    12 characters
    )
    theme_engine

  • theme path
    (String,
    14 characters
    )
    themes/garland

  • arguments
    (Array, 3 elements)

  • theme paths
    (Array, 2 elements)

    • 0
      (String,
      14 characters
      )
      modules/system

    • 1
      (String,
      14 characters
      )
      themes/garland

  • preprocess functions
    (Array, 1 element)

    • 0
      (String,
      19 characters
      )
      template_preprocess

      |
      (Callback)
      template_preprocess();

      =
      =
      =
      =
      But if I define phptemplate_preprocess_maintenance_page() in template.php, it becomes this:

      maintenance_page
      (Array, 7 elements)

      • template
        (String,
        16 characters
        )
        maintenance-page

      • path
        (String,
        14 characters
        )
        themes/garland

      • type
        (String,
        12 characters
        )
        theme_engine

      • theme path
        (String,
        14 characters
        )
        themes/garland

      • arguments
        (Array, 3 elements)

      • theme paths
        (Array, 2 elements)

        • 0
          (String,
          14 characters
          )
          modules/system

        • 1
          (String,
          14 characters
          )
          themes/garland

      • preprocess functions
        (Array, 2 elements)

        • 0
          (String,
          19 characters
          )
          template_preprocess

          |
          (Callback)
          template_preprocess();

        • 1

          (String,
          39 characters
          )
          phptemplate_preprocess_maintenance_page

          |
          (Callback)
          phptemplate_preprocess_maintenance_page();

mattyoung’s picture

StatusFileSize
new20.41 KB

Attached is the plain looking garland off-line page

mattyoung’s picture

StatusFileSize
new20.98 KB

Here is what the page look like after patching template.php

dvessel’s picture

http://api.drupal.org/api/function/template_preprocess_maintenance_page/6

It's there. Could you try it on a fresh install to rule out your server? I'm not having any problems with it myself and I'm running it off of MAMP on Mac OS X.

dvessel’s picture

I misread, you know it's there.. I'm not sure why it's not being included in your install. I can't recreate it myself.

mattyoung’s picture

I tested this on several sites and they are all the same.

Can you go to 'devel/php' and execute this:

dvm(function_exists('template_preprocess'));
dvm(function_exists('template_preprocess_maintenance_page'));

On my install, the first is true, and second is false and that's the problem. I suspect for you it might be both true and this mean 'theme.maintenance.inc' is require/include somewhere in your install for normal site operation. That's not the case for my 6.9 install. The only place this file is required is in bootstrap.inc:

function drupal_maintenance_theme() {
  require_once './includes/theme.maintenance.inc';
  _drupal_maintenance_theme();
}

and this function is only called when the site is off-line. During normal operation like when the theme registry is built, no body include/require theme.maintenance.inc. If yours is different, some body else is include/require this file. Try to find who is doing this by 'egrep -lr "theme.maintenance.inc" .' or use whatever recursive search tool from the top of your Drupal install. I suspect some other code is include/require this file and that's not in the normal Drupal install.

In any case, I now think this is a bug for core to fix. Theme.inc should include 'theme.maintenance.inc' when it builds the theme registry so the template_preprocess_maintenance_page() hook can be found. Every theme has this problem actually and it should be taken care of in core like this:

in theme.inc:

function _theme_build_registry($theme, $base_theme, $theme_engine) {
  require_once './includes/theme.maintenance.inc';      <<< ===== add this
...
dvessel’s picture

I'm responsible for allowing the maintenance page to be themable. The registry handling for the maintenance page is handled differently. It doesn't need to be in the cached registry while in normal operation. It's only when set to offline mode and you're viewing the site as an anonymous user, the registry gets built with template_preprocess_maintenance_page. This includes when the db is offline. In all other cases, it's not needed and so it isn't included.

As long as drupal_maintenance_theme() is invoked while in offline mode, it should work. Why your install doesn't call this is beyond me.

mattyoung’s picture

>I'm responsible for allowing the maintenance page to be themable.

Ha, I'm talking to real McCoy.

>It's only when set to offline mode and you're viewing the site as an anonymous user, the registry gets built with template_preprocess_maintenance_page.

Okay, I know what's going on. Your assumption is no body cause the theme system initialized during bootstrap. I have a module that makes theme() call in its _init() hook. This has the unfortunate side effect of initializing the theme system even in off-line mode. _drupal_bootstrap_full() invoke all init hooks. By the time execution gets to drupal_site_offline(), global $theme is set:

function _drupal_maintenance_theme() {
  global $theme, $theme_key;

  // If $theme is already set, assume the others are set too, and do nothing.
  if (isset($theme)) {
    return;
  }

  ....

so the rest is skip and the database version theme registry is used.

For maintenance-page to work in off-line mode, theme() cannot be called in init(). A lot of things may need to use theme hook in init. Especially consider that fact that site off-line need to work normally for admin. So this restriction may not be reasonable. If we add

function _theme_build_registry($theme, $base_theme, $theme_engine) {
  require_once './includes/theme.maintenance.inc';      <<< ===== add this
...

the whole problem is solved.

dvessel’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

I would think about why you're calling a theme function so early. It causes other problems like throwing off the block configuration page and possibly others so it shouldn't be done. And the line to include the file may fix it but it's out of place. What does building the theme registry have to do with including the maintenance file?

I'm sorry but I think it's more of a problem with your module ATM due to the other problems with initializing the theme system so early. Unless Drupal can initialize the theme very early with no consequence, I see little point in fixing it here.

mattyoung’s picture

The api page does not indicate any restriction: http://api.drupal.org/api/function/hook_init/6. It says "For example, this hook is a typical place for modules to add CSS or JS that should be present on every page." Adding css affects the look so theme() function should be used to allow theme to override. hook_init() is called at the very end of bootstrap, I can't see it have any limitation on what it can do. But if there really is some limitation, then hook_init() should indicate this clearly and Drupal need another hook, say a 'prepagecallback' hook:

function menu_execute_active_handler($path = NULL) {
  if (_menu_site_is_offline()) {
    return MENU_SITE_OFFLINE;
  }
  // Rebuild if we know it's needed, or if the menu masks are missing which
  // occurs rarely, likely due to a race condition of multiple rebuilds.
  if (variable_get('menu_rebuild_needed', FALSE) || !variable_get('menu_masks', array())) {
    menu_rebuild();
  }
  if ($router_item = menu_get_item($path)) {
    if ($router_item['access']) {
      if ($router_item['file']) {
        require_once($router_item['file']);
      }

      module_invoke_all('prepagecallback');                /// <<<===== one more hook

      return call_user_func_array($router_item['page_callback'], $router_item['page_arguments']);



    }
    else {
      return MENU_ACCESS_DENIED;
    }
  }
  return MENU_NOT_FOUND;
}

>It causes other problems like throwing off the block configuration page and possibly others so it shouldn't be done.

I don't see any problem with the block configure page. In fact I'm writing a custom block right now and I have been using the block configure screen very often and encounter no problem. Can you point me to the code in the block configure screen where the problem is?

>What does building the theme registry have to do with including the maintenance file?

It's a combination of two things. Since theme got initialize in hook_init, the global $theme variable is set. So in here:

function _drupal_maintenance_theme() {
  global $theme, $theme_key;

  // If $theme is already set, assume the others are set too, and do nothing.
  if (isset($theme)) {
    return;
  }

  ....

you cut out early and don't go on to build the special maintenance page theme registry from scratch in memory. So the database cache version is used. In order the get the 'template_preprocess_maintenance_page()' in included as 'maintenance_page' template preprocess function, the function 'template_preprocess_maintenance_page()' must be defined at the time when the registry is build. Therefore, by including theme.maintenance.inc at the top of:

function _theme_build_registry($theme, $base_theme, $theme_engine) {
  require_once './includes/theme.maintenance.inc';      <<< ===== add this
...

make the 'template_preprocess_maintenance_page()' defined so the normal theme registry will have the preprocess function for maintenance_page.

Anyway, I don't think this fix is a good idea because you want to handle off-line page using your special logic _drupal_maintenance_theme(). What you can do is this:

function _drupal_maintenance_theme() {
  global $theme, $theme_key;

  static $been_here;       // <<=== add this flag
  // If $theme is already set, assume the others are set too, and do nothing.
  if (isset($been_here) && isset($theme)) {    // <<=== check both
    return;
  }

  ....

this way, hook_init() can touch theme() and you still get to make your own maintenance_page theme registry.

Can you take a look at this other thing I reported: http://drupal.org/node/374651

dvessel’s picture

Here the issues I'm aware of:
#219756: blocks cannot be configure if administration theme used
#219846: breaks blocks editor if administrative theme used
#219910: Calling theme function from hook_init() interferes with administration theme

Adding styles and scripts are not handled the same way as calling a theme functions in Drupal so your assumptions about treating them the same doesn't work out. The docs do need to be updated for hook_init() or a lot of the bootstrap process has to be reorganized.

dave reid’s picture

"Adding css affects the look so theme() function should be used to allow theme to override."

Yes, you can add CSS and JS in hook_init(), but they are not actually processed until the page is rendered at the end of the request. If you call a theme function in init(), it loads the theme registry immediately. There's a big difference. Maybe we should document this in hook_init()?

mattyoung’s picture

>There's a big difference. Maybe we should document this in hook_init()?

Yes, document this. Maybe even add a flag to indicate bootstrap happening so theme() can check for this flag, put itself in "no-can-do" mode and log a message/blow itself up to tell whoever call it to stop that. This flag should be clear after bootstrap_full() so theme() can operate normally.

If theme() cannot be called in hook_init(), then how does one allow theme to override css for the css added in hook_init()? SOL?

Seeing how others have running into this problem, I think another hook just prior to page handler would solve this problem. Some thing like this:

function menu_execute_active_handler($path = NULL) {
  if (_menu_site_is_offline()) {
    return MENU_SITE_OFFLINE;
  }
  // Rebuild if we know it's needed, or if the menu masks are missing which
  // occurs rarely, likely due to a race condition of multiple rebuilds.
  if (variable_get('menu_rebuild_needed', FALSE) || !variable_get('menu_masks', array())) {
    menu_rebuild();
  }
  if ($router_item = menu_get_item($path)) {
    if ($router_item['access']) {
      if ($router_item['file']) {
        require_once($router_item['file']);
      }
                                                            ////////////////////////////////////////////////////
      module_invoke_all('prepagecallback');                /// <<<===== one more hook
                                                          ////////////////////////////////////////////////////
      return call_user_func_array($router_item['page_callback'], $router_item['page_arguments']);



    }
    else {
      return MENU_ACCESS_DENIED;
    }
  }
  return MENU_NOT_FOUND;
}
benthroop’s picture

We've run into this same problem where the maintenance mode ends up building the page as all white with plain black text. I"m posting here because it seems to be the same symptom, if not the same cause.

In our case Drupal is actually using the proper theme (ours is based off of Acquia_Marina), but none of the theme PHP variables are filled in. So the entire page looks like this:

<!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" lang="" xml:lang=""> 
  
  <head> 
    <title></title> 
            <!--[if IE 7]>
      <link rel="stylesheet" href="sites/all/themes/acquia_marina/ie7-fixes.css" type="text/css">
    <![endif]--> 
    <!--[if lte IE 6]>
      <link rel="stylesheet" href="sites/all/themes/acquia_marina/ie6-fixes.css" type="text/css">
    <![endif]--> 
      </head> 
  
  <body class=""> 
    <div id="page" class="clearfix"> 
      <div id="header-wrapper" class="clearfix"> 
        <div id="header-first"> 
        </div><!-- /header-first --> 
      </div><!-- /header-wrapper --> 
      <div id="main-wrapper" class="clearfix">  
        <div id="content-wrapper"> 
          <div id="content"> 
            <div id="content-inner" class="clear"> 
                Maintenance message is properly included here. 
             </div> 
          </div><!-- /content --> 
        </div><!-- /content-wrapper --> 
      </div><!-- /main-wrapper --> 
    </div><!-- /page --> 
  </body> 
</html> 

The really weird part is that no matter what we change the maintenance theme to in setting.php, it uses this page. I've even made edits to it and they are properly shown. Just can't get it to look at anything else or to fill in the vars.
FWIW, we have this same setup working on a different server and this just started happening after we migrated (successfully except for this) to another server. This is in D6.8

Is there anywhere else in Drupal that you can set the maintenance theme?
Has anyone else run into this?

benthroop’s picture

I've verified that this is a DB issue. Cloning the DB from the working server to the new one makes it work fine on the new server.
So I'm cloning the DB and will play with it until I get the maintenance page to show. FUN! Hopefully documenting this will help someone else.

mattyoung’s picture

Something initialized theme during bootstrap. That's why you get empty maintenance-page theme variables. Most likely some init hook did it.

Find out if this is happening to you. If you have access to a debugger, put a breakpoint in init_theme() and see if it's called during bootstrap init hook phase.

If you don't have access to a debugger, use devel module, go to 'devel/php' and execute this:

dpm(module_implements('init'));

This will show you a list of modules that implements hook_init(), look into each non-core module's hook_init() and see if any of them cause init_theme() to be called like calling theme(), drupal_render_form() etc. If you find any, that is the problem.

>Is there anywhere else in Drupal that you can set the maintenance theme?

Nope. The variable 'maintenance_theme' is it. But if theme system is initialized during bootstrap, all the logic in _drupal_maintenance_theme() is by-passed. You end up empty theme variable. Also the maintenanc-page.tpl.php is from your regular theme, if one is not is define there, the one in system module is used. The variable 'maintenance_theme' is totally ignored. Whatever you set in settings.php $conf['maintenance_page'] doesn't matter.

Find out who is messing with theme during bootstrap and you will find the problem.

benthroop’s picture

mattyoung, if I ever meet you, beer's on me. Thanks!

That line of PHP gave me a list of 25 modules and the culprit turned out to be the Rules Module dev release. One rule that we had was running on Page View, and turning that off fixed the issue. I'll log an issue with those guys.

axel pressbutton’s picture

StatusFileSize
new17 KB

Hi, I'm subscribing to this thread as I'm having the same problems.

I had a list of 20 modules returned (see attached list in screenshot) but am not sure what I should do next to eliminate each of them...is it a case of disabling modules one at a time or do I search the code for something? If I need to search the code, what exactly am I looking for and where?

I disabled the Rules module (see previous post, #24) but still had the same issues.

Thanks in advance for any help :)

mattyoung’s picture

open 'includes/common.inc', go to line: 2544 and comment this line out:

//  require_once './includes/theme.inc';

then browse your site normally and you should see a stack trace. that'll tell show you which module call theme. If it originates from some init() hook, then you found the problem.

axel pressbutton’s picture

Thanks for the reply mattyoung,

I've tried your suggestion but get the following error as soon as I refresh the page with the site in 'online mode'...

Fatal error: Call to undefined function theme() in C:\xampp\htdocs\drupal6\includes\common.inc on line 2871

Line 2871 contained in 2869 - 2873;


  // Until now, we rendered the children, here we render the element itself
  if (!isset($elements['#printed'])) {
    $content = theme(!empty($elements['#type']) ? $elements['#type'] : 'markup', $elements);
    $elements['#printed'] = TRUE;
  }

Just to note, I'm using Drupal 6.10 and a Custom theme based on the Basic theme.

Hope this is of some use.

mattyoung’s picture

It should have printed out a stack trace. I guess your php version doesn't do this.

try this: insert this in the beginning of init_theme() in line 31 of includes/theme.inc:

  $trace = debug_backtrace(FALSE);
  print "<ul>";
  foreach($trace as $t) {
    print "<li>" .$t['function']. "() at " .$t['line']. " in " .$t['file']. "</li>";
  }
  print "</ul>";
  exit;

access your site and see what it print out.

axel pressbutton’s picture

Thanks,

I've now included that code and get the following list on the homepage...

  • init_theme() at 593 in C:\xampp\htdocs\drupal6\includes\theme.inc
  • theme() at 2871 in C:\xampp\htdocs\drupal6\includes\common.inc
  • drupal_render() at 2861 in C:\xampp\htdocs\drupal6\includes\common.inc
  • drupal_render() at 1010 in C:\xampp\htdocs\drupal6\modules\node\node.module
  • node_view() at 1096 in C:\xampp\htdocs\drupal6\modules\node\node.module
  • node_show() at 1785 in C:\xampp\htdocs\drupal6\modules\node\node.module
  • node_page_view() at in
  • call_user_func_array() at 348 in C:\xampp\htdocs\drupal6\includes\menu.inc
  • menu_execute_active_handler() at 18 in C:\xampp\htdocs\drupal6\index.php

Not sure if this points the finger at anything or not? Not exactly sure what's going on with "node_page_view() at in "

Both XAMPP and my remote server show the PHP version as being 5.2.6

mattyoung’s picture

Well, this mean nothing during bootstrap call init_theme(). So it's something else is messing up mainenace-page.

Looks like you are running this with the site online normally. Try to put the site off-line first, then run the code and see what it print out.

What you do is comment out the code you added int init_theme(). Put you site off-line. uncomment the code in init_theme(), access your site and see what it print out.

axel pressbutton’s picture

Sorry, i did that before but had the same error message...my fault, i needed to clear the cache so i could see the site from a non-logged in perspective in IE6. Being logged in as super admin in Firefox obviously also returns the same list as previous

The list is reduced to 3 items...

  • init_theme() at 593 in C:\xampp\htdocs\drupal6\includes\theme.inc
  • theme() at 335 in C:\xampp\htdocs\drupal6\includes\common.inc
  • drupal_site_offline() at 30 in C:\xampp\htdocs\drupal6\index.php

and I'm guessing that this looks all OK :(

mattyoung’s picture

Everything looks normal. I don't know what can be wrong.

What does the maintenance-page actually looks like? Do a view source and paste the content here and see.

axel pressbutton’s picture

I've tried this with Lightbox2 switched off for this page as well...just in case

<!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" dir="ltr">

<head>
  <title>Site off-line | Test</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="shortcut icon" href="/drupal6/misc/favicon.ico" type="image/x-icon" />
  <link type="text/css" rel="stylesheet" media="all" href="/drupal6/modules/node/node.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/modules/system/defaults.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/modules/system/system.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/modules/system/system-menus.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/modules/user/user.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/cck/theme/content-module.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/filefield/filefield.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/imagefield/imagefield.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/lightbox2/css/lightbox_alt.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/ubercart/uc_attribute/uc_attribute.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/ubercart/uc_file/uc_file.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/ubercart/uc_order/uc_order.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/ubercart/uc_product/uc_product.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/ubercart/uc_roles/uc_roles.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/ubercart/uc_store/uc_store.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/modules/forum/forum.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/sites/all/modules/cck/modules/fieldgroup/fieldgroup.css?e" />
<link type="text/css" rel="stylesheet" media="all" href="/drupal6/modules/system/maintenance.css?e" />
  <script type="text/javascript" src="/drupal6/misc/jquery.js?e"></script>
<script type="text/javascript" src="/drupal6/misc/drupal.js?e"></script>
<script type="text/javascript" src="/drupal6/sites/all/modules/lightbox2/js/lightbox.js?e"></script>
<script type="text/javascript" src="/drupal6/sites/all/modules/ubercart/uc_file/uc_file.js?e"></script>
<script type="text/javascript" src="/drupal6/sites/all/modules/ubercart/uc_roles/uc_roles.js?e"></script>
<script type="text/javascript">
<!--//--><![CDATA[//><!--
jQuery.extend(Drupal.settings, { "basePath": "/drupal6/", "lightbox2": { "rtl": 0, "file_path": "/drupal6/(\\w\\w/)sites/default/files", "default_image": "/drupal6/sites/all/modules/lightbox2/images/brokenimage.jpg", "border_size": "10", "font_color": "000", "box_color": "fff", "top_position": "", "overlay_opacity": "0.8", "overlay_color": "000", "disable_close_click": 1, "resize_sequence": "0", "resize_speed": 400, "fade_in_speed": 400, "slide_down_speed": 600, "use_alt_layout": 1, "disable_resize": 0, "disable_zoom": 0, "force_show_nav": 0, "loop_items": 0, "node_link_text": "", "node_link_target": 0, "image_count": "Image !current of !total", "video_count": "Video !current of !total", "page_count": "Page !current of !total", "lite_press_x_close": "press \x3ca href=\"#\" onclick=\"hideLightbox(); return FALSE;\"\x3e\x3ckbd\x3ex\x3c/kbd\x3e\x3c/a\x3e to close", "download_link_text": "", "enable_login": false, "enable_contact": false, "keys_close": "c x 27", "keys_previous": "p 37", "keys_next": "n 39", "keys_zoom": "z", "keys_play_pause": "32", "display_image_size": "", "image_node_sizes": "()", "trigger_lightbox_classes": "", "trigger_lightbox_group_classes": "", "trigger_slideshow_classes": "", "trigger_lightframe_classes": "", "trigger_lightframe_group_classes": "", "custom_class_handler": 0, "custom_trigger_classes": "", "disable_for_gallery_lists": true, "disable_for_acidfree_gallery_lists": true, "enable_acidfree_videos": true, "slideshow_interval": 5000, "slideshow_automatic_start": true, "slideshow_automatic_exit": true, "show_play_pause": true, "pause_on_next_click": false, "pause_on_previous_click": true, "loop_slides": false, "iframe_width": 600, "iframe_height": 400, "iframe_border": 1, "enable_video": 0 } });
//--><!]]>
</script>
  <script type="text/javascript"> </script>
</head>
<body class="in-maintenance no-sidebars">
  <div id="page">
    <div id="header">
      <div id="logo-title">

                  <a href="/drupal6/" title="Home" rel="home" id="logo">
            <img src="/drupal6//logo.png" alt="Home" />
          </a>
        
        <div id="name-and-slogan">
                      <h1 id="site-name">
              <a href="/drupal6/" title="Home" rel="home"><span>Test</span></a>
            </h1>
          
                  </div> <!-- /name-and-slogan -->
      </div> <!-- /logo-title -->

      
    </div> <!-- /header -->

    <div id="container" class="clear-block">

      
      <div id="main" class="column"><div id="main-squeeze">

        <div id="content">
          <h1 class="title" id="page-title">Site off-line</h1>          <div class="messages error">
 <ul>
  <li>warning: array_keys() [<a href='function.array-keys'>function.array-keys</a>]: The first argument should be an array in C:\xampp\htdocs\drupal6\includes\theme.maintenance.inc on line 217.</li>
  <li>warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\drupal6\includes\theme.maintenance.inc on line 217.</li>
 </ul>
</div>
          <div id="content-content" class="clear-block">
            Test is currently under maintenance. We should be back shortly. Thank you for your patience.          </div> <!-- /content-content -->
        </div> <!-- /content -->

      </div></div> <!-- /main-squeeze /main -->

      
    </div> <!-- /container -->

    <div id="footer-wrapper">
      <div id="footer">
                      </div> <!-- /footer -->
    </div> <!-- /footer-wrapper -->

  </div> <!-- /page -->

</body>
</html>
mattyoung’s picture

I don't see anything wrong with the page itself. But I don't see any theme settings. That error message indicates there is something wrong with the theme. The theme is somehow broken. What do you have 'maintenance_theme' variable set to? This is the one you set in settings.php like this:

$conf = array(
  'maintenance_theme' => 'THEME-ID',
);

try 'minnelli'.

Anyway, there is nothing wrong with the maintenance-page. The problem is your theme.

axel pressbutton’s picture

$conf = array(
#   'site_name' => 'My Drupal site',
#   'theme_default' => 'minnelli',
#   'anonymous' => 'Visitor',
/**
 * A custom theme can be set for the off-line page. This applies when the site
 * is explicitly set to off-line mode through the administration page or when
 * the database is inactive due to an error. It can be set through the
 * 'maintenance_theme' key. The template file should also be copied into the
 * theme. It is located inside 'modules/system/maintenance-page.tpl.php'.
 * Note: This setting does not apply to installation and update pages.
 */
  'maintenance_theme' => 'zodbod',
/**
 * reverse_proxy accepts a boolean value.
 *
 * Enable this setting to determine the correct IP address of the remote
 * client by examining information stored in the X-Forwarded-For headers.
 * X-Forwarded-For headers are a standard mechanism for identifying client
 * systems connecting through a reverse proxy server, such as Squid or
 * Pound. Reverse proxy servers are often used to enhance the performance
 * of heavily visited sites and may also provide other site caching,
 * security or encryption benefits. If this Drupal installation operates
 * behind a reverse proxy, this setting should be enabled so that correct
 * IP address information is captured in Drupal's session management,
 * logging, statistics and access management systems; if you are unsure
 * about this setting, do not have a reverse proxy, or Drupal operates in
 * a shared hosting environment, this setting should be set to disabled.
 */
#   'reverse_proxy' => TRUE,
/**
 * reverse_proxy accepts an array of IP addresses.
 *
 * Each element of this array is the IP address of any of your reverse
 * proxies. Filling this array Drupal will trust the information stored
 * in the X-Forwarded-For headers only if Remote IP address is one of
 * these, that is the request reaches the web server from one of your
 * reverse proxies. Otherwise, the client could directly connect to
 * your web server spoofing the X-Forwarded-For headers.
 */
#   'reverse_proxy_addresses' => array('a.b.c.d', ...),
);

my theme lives in /sites/all/themes/zodbod/.

I tried minnelli as you suggested and it worked, along with all of the other themes that live in /themes/.

As settings.php suggested, I've copied the template for the offline message from /modules/system/maintenance-page.tpl.php into my theme and it has no effect. I've also just made a copy of page.tpl.php and renamed it to maintenance-page.tpl.php and that didn't work.

Do these only work if they live in the main /themes/ dir?

mattyoung’s picture

Something is wrong with your theme and you need to debug it. Your theme is probably not even working correctly for normal operation.

What does zodbod.info looks like?

when you render a normal page like the home page, what does the page source look like?

>I've copied the template for the offline message from /modules/system/maintenance-page.tpl.php
This is not strictly necessary unless you need to modify that template. The theme system falls back to the system copy if one is not defined in the maintenance_theme.

>Do these only work if they live in the main /themes/ dir?
No, any theme can be used and they can reside in any usual locations: /themes, /site/all/themes, /sites/www.SITENAME.XXX/themes. There is nothing special about maintenance theme.

Again, something is wrong with your theme. This problem has nothing to do with maintenance-page.

axel pressbutton’s picture

Many thanks for your ongoing advice mattyoung.

I think you may have hit something here....I've just had a look and noticed that the .info is still labelled as the original theme name that it was based on but with modifications within that (Not sure if it needed to be renamed....I'm guessing it did :( ).

My .inf file is currently called basic.info, NOT zodbod.info - the site works ok BUT if i then change the name to zodbod.info and clear my cache the site then breaks completely...i'm guessing that the name is being referenced in the db somewhere?

Sorry, forgot to add the code...there's a lot of it there compared to the standard .info files though i must admit

; $Id: basic.info,v 1.1.2.3 2008/11/22 00:53:22 stevek Exp $

name = Zodbod
description = Zodbod theme for Drupal 6
screenshot = screenshot.png
engine = phptemplate

regions[left] = Left sidebar
regions[right] = Right sidebar
regions[content_top] = Content Top
regions[content_bottom] = Content Bottom
regions[header] = Header
regions[sub_header] = Sub Header
regions[footer_block] = Footer

features[] = logo
features[] = name
features[] = slogan
features[] = mission
features[] = node_user_picture
features[] = comment_user_picture
features[] = search
features[] = favicon
features[] = primary_links

; disabled features, uncomment to activate
; features[] = secondary_links

stylesheets[all][] = style.css
stylesheets[all][] = css/tabs.css
stylesheets[all][] = css/layout.css
stylesheets[all][] = css/main.css
stylesheets[print][] = css/print.css

; Information added by drupal.org packaging script on 2008-10-17
version = "6.x-1.x-dev"
core = "6.x"
project = "basic"
datestamp = "1224244887"


; Information added by drupal.org packaging script on 2008-11-22
version = "6.x-2.0"
core = "6.x"
project = "basic"
datestamp = "1227316202"
mrfelton’s picture

2 modules that are offenders of calling theme related functions are textsize and pagestyle which both call path_to_theme() in hook_init():

function pagestyle_init() {
  $pagestyle_path = drupal_get_path('module', 'pagestyle');
  $pagestyle_current = pagestyle_get_current($value = 'int');
  drupal_add_js('
    var pagestyle_path = "'. $pagestyle_path .'";
    var pagestyle_current = "'. $pagestyle_current .'";
  ', 'inline');
  drupal_add_js(drupal_get_path('module', 'pagestyle') .'/jquery.pagestyle.js');
  if (file_exists(path_to_theme() .'/pagestyle.css')) {
    drupal_add_css(path_to_theme() .'/pagestyle.css');
  }
  else if (file_exists(drupal_get_path('module', 'pagestyle') .'/pagestyle.css')) {
    drupal_add_css(drupal_get_path('module', 'pagestyle') .'/pagestyle.css');
  }
  pagestyle_print_html();
  pagestyle_check();
}

I will lodge a bug report in their issue queues now.

mattyoung’s picture

I reported this as a bug that core should not allow: #405578: Need to prohibit hook_init() from initializing theme system: just not allow hook_init() to touch theme and problem solve.

David_Rothstein’s picture

Version: 6.9 » 7.x-dev
Status: Closed (won't fix) » Active

This is still an issue in Drupal 7, and there, we ought to be able to fix it. The relevant part of the theme system has been completely refactored in #553944: Define hook_menu_get_item_alter() as a reliable hook that runs before the page is doomed so that now, all the other issues with calling theme functions in hook_init() are solved, and this seems to be the only one remaining.

(Actually, right at the moment calling theme functions from hook_init leads to a white screen, but that is a temporary condition - applying the patch at #592008-24: Don't save theme registry before modules are included fixes that.)

I think the issue with the site offline theming is possible to fix for Drupal 7.

wibbsy’s picture

On my offline page, the layout and content (i.e. the images) are the same as online, the only thing that doesn't carry over from the "online" theme is the colour scheme? The above new funcitons in template.php don;t make a difference either?

mlncn’s picture

Note that elements of this issue appear to stem from #341140: drupal_get_filename() when database is down, does not deal with phptemplate themes which is fixed in 7 now but not yet in 6.

benjamin, agaric

heather’s picture

Is this a feature request for D8 rather than a bug for D7?

See related issues:

#421062: Maintenance theme is ugly and cannot be altered

Just tested, and yes, if Garland or Bartik are the default theme, and any color changes have been set- they don't display in offline mode.

Bartik gets around this by showing a plain maintenance-page.tpl.php with no styling, hiding the color.

In both cases below, I set the color module with some custom colors:

See Garland:

Only local images are allowed.

See Bartik:

Only local images are allowed.

mrfelton’s picture

pasqualle’s picture

Issue summary: View changes
Status: Active » Closed (fixed)

I don't see any remaining issues here