While trying to test #233091: Move code from update.php into includes/update.inc, I was told that my patch yielded a WSOD (white screen of death: no output in the browser window). After removing the patch and testing in a clean environment, I was able to reproduce the issue (so my patch is not the issue).

Here's how to reproduce the issue:

1. install a clean/simple 6.13 Drupal
2. untar a D7 devel snapshot (I am using current CVS, but that should be fairly similar)
3. copy over the sites directory
4. point your domain to the d7 snapshot directory
5. visit update.php

Expected result: the nice little drupal update system

Actual result: blank page.

While debugging this, I was able to find out the error is actually in cache.in:

Fatal error: Class name must be a valid object or a string in /var/hostmaster/drupal-7.x-git/includes/cache.inc on line 25

I was able to find this problem with the following trivial patch:

--- a/update.php
+++ b/update.php
@@ -653,7 +653,7 @@ function update_check_requirements() {
 
 // Some unavoidable errors happen because the database is not yet up-to-date.
 // Our custom error handler is not yet installed, so we just suppress them.
-ini_set('display_errors', FALSE);
+//ini_set('display_errors', FALSE);
 
 // We prepare a minimal bootstrap for the update requirements check to avoid
 // reaching the PHP memory limit.

(I find that instruction rather silly too...)

Here's a backtrace:

Array
(
    [0] => Array
        (
            [file] => /var/hostmaster/drupal-7.x-git/includes/cache.inc
            [line] => 46
            [function] => _cache_get_object
            [args] => Array
                (
                    [0] => cache
                )

        )

    [1] => Array
        (
            [file] => /var/hostmaster/drupal-7.x-git/includes/bootstrap.inc
            [line] => 670
            [function] => cache_get
            [args] => Array
                (
                    [0] => variables
                    [1] => cache
                )

        )

    [2] => Array
        (
            [file] => /var/hostmaster/drupal-7.x-git/includes/bootstrap.inc
            [line] => 1437
            [function] => variable_initialize
            [args] => Array
                (
                    [0] => Array
                        (
                            [file_directory_path] => sites/testd7-upg.hostmaster.koumbit.net/files
                            [file_directory_temp] => sites/testd7-upg.hostmaster.koumbit.net/files/tmp
                            [file_downloads] => 1
                            [cache] => 1
                            [clean_url] => 1
                        )

                )

        )

    [3] => Array
        (
            [file] => /var/hostmaster/drupal-7.x-git/includes/bootstrap.inc
            [line] => 1361
            [function] => _drupal_bootstrap
            [args] => Array
                (
                    [0] => 5
                )

        )

    [4] => Array
        (
            [file] => /var/hostmaster/drupal-7.x-git/update.php
            [line] => 697
            [function] => drupal_bootstrap
            [args] => Array
                (
                    [0] => 9
                )

        )

)

Interestingly enough, variable_init is called with [cache] => 1 although when I look at the code, I feel it shouldn't be that:

function _cache_get_object($bin) {
  // We do not use drupal_static() here because we do not want to change the
  // storage of a cache bin mid-request.
  static $cache_objects, $default_class;
  if (!isset($cache_objects[$bin])) {
    $class = variable_get($bin, FALSE);
    if (empty($class)) {
      $class = variable_get('cache_default_class', 'DrupalDatabaseCache');
    }
    $cache_objects[$bin] = new $class($bin); ##### <= this is what provokes the error, $class = 1 here, because $bin = 'cache'
  }
  return $cache_objects[$bin];
}

Maybe i'm just sitting in the tree in a wrong turn or something...

Comments

anarcat’s picture

Status: Active » Fixed

Okay, sorry about that, I had $conf['cache'] = 1; in my settings.php...

anarcat’s picture

Title: cache.inc broke update.php » D7 support: set $conf['cache'] properly
Project: Drupal core » Provision
Version: 7.x-dev »
Component: update system » Code
Category: bug » task
Status: Fixed » Active

In Aegir's settings.php, there is a:

$conf['cache'] = 1;

while it's nice to have caching enabled out of the box, in fact, that breaks Drupal 7, which expects something else (the caching mechanism class name, from what i can tell from cache.in).

adrian’s picture

Title: D7 support: set $conf['cache'] properly » 0.4 - D7 support: set $conf['cache'] properly
Priority: Critical » Normal

We can't support d7 yet, because drush 2.0 doesn't support d7, and d7 is way too fast moving at this point.

we can look at an early 0.4 alpha with support for d7 once code freeze has happened, when things should be a bit more stable.

adrian’s picture

please test this again.

drupal 7 was working fine for me when i was testing.

omega8cc’s picture

Tested many times on different machines and results are confirmed:

1. Drupal 7.0-alpha4 works with Aegir alpha8 without any issues.

2. Drupal 7.0-alpha5 allows platform and site install, but created site gets nice WSOD: http://skitch.com/omega8cc/djdsc/fullscreen

3. Verify on Drupal 7.0-alpha5 shows this error: http://skitch.com/omega8cc/djdi4/d7a5.mega.nyc.host8.biz-aegir-hosting-s...

4. Drupal 7.x-dev installed *today* works without any issues on Aegir alpha8: http://skitch.com/omega8cc/djdi9/fullscreen

5. Verify on just created Drupal 7.x-dev site also works, as expected: http://skitch.com/omega8cc/djdas/d7dev.mega.nyc.host8.biz-aegir-hosting-...

Conclusion: it was not an Aegir fault probably, since it is now fixed in the D7-dev.

HTH ~ Grace

adrian’s picture

Status: Active » Fixed

marking fixed.

thanks grace.

Status: Fixed » Closed (fixed)

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