WSOD when updating from 6.x-2.x to 6.x-3.0

What do you mean by "misupload", the wrong location of the Views folder? At least if Drush works as it usually does, and reports back correctly what it is doing, it puts the "views" folder into "sites/all/modules" (as quoted from the shell in my initial issue). Also that's the location which I recursively deleted before downloading views-6.x-3.0-rc3, and before downgrading to views-6.x-2.16 (an error whould have been thrown if the folder to be deleted wouldn't exist).

(Checked) Yes, at the referenced path (/var/www/drupal/sites/all/modules/views/views.module), views.module does exist when views-6.x-3.0-rc3 is installed and the mentioned errors are emitted into error.log.

I currently do not need to run Views3 in this site, so I'm fine with downgrading again; maybe we should postpone this issue and see if more similar reports come in (in case this is a singular phenomenon on one site)?

'drush dl' (pm-download) downloads and extracts a specified release into the given path, by default ./sites/all/modules. If files/folders exist at this location, they're overwritten. In case directory layout or file naming has changed (not unlikely with a major version update), this results in a mixture of old and new files and causes weird errors. Thus, the recommended procedure is to always delete the old directory, then drush dl the desired release. Drush works, as long as Drupal core can bootstrap successfully. The Core environment can be chaecked with 'drush st' (status); even with a deleted views folder, the Core bootstrap completes fine. The only (and obvious) exception from this recommendation are core upgrades through Drush which work differently.

'drush up' (pm-update) updates always to the recommended release for the discovered environment and moves the old files into /backup (drush 3.x) or ~/drush-backups (drush 4). According to 'drush rl' (pm-release), the currently tagged as "recommended" release is views-6.x-2.16, so you can't go with 'drush up' to views-6.x-3.0-rc3.

The _menu_check_access() message at shell level ist not the issue here, it's a side effect that does not show up in Apache's error.log. The issue I've experienced is a WSOD after a complete views-6.x-3.0-rc3 package has been downloaded and unpacked into ./sites/all/modules. "Prove":

# rm -r sites/all/modules/views
# drush dl views (...)
# cd sites/all/modules/views
# ls -lah
-rw-r--r--   1 6226 6226  48K 14. Nov 21:45 CHANGELOG.txt
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 css
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 docs
-rw-r--r--   1 6226 6226  257 14. Nov 21:45 documentation-standards.txt
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 handlers
drwxr-xr-x   3 6226 6226 4,0K 14. Nov 21:45 help
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 images
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 includes
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 js
-rw-rw-r--   1 6226 6226  18K 17. Sep 23:50 LICENSE.txt
drwxr-xr-x  16 6226 6226 4,0K 14. Nov 21:45 modules
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 plugins
-rw-r--r--   1 6226 6226  807 14. Nov 21:45 README.txt
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 theme
-rw-r--r--   1 6226 6226  51K 14. Nov 21:45 views2.doxy
-rw-r--r--   1 6226 6226  195 14. Nov 21:45 views.drush.inc
drwxr-xr-x   2 6226 6226 4,0K 14. Nov 21:45 views_export
-rw-r--r--   1 6226 6226  254 14. Nov 22:25 views.info
-rw-r--r--   1 6226 6226  16K 14. Nov 21:45 views.install
-rw-r--r--   1 6226 6226  40K 14. Nov 21:45 views.module
-rw-r--r--   1 6226 6226 4,3K 14. Nov 21:45 views_revert.drush.inc
-rw-r--r--   1 6226 6226  318 14. Nov 22:25 views_ui.info
-rw-r--r--   1 6226 6226 9,1K 14. Nov 21:45 views_ui.module
(...)

When these files are in place, I'm encountering the WSOD, and the quoted error messages (Call to undefined function views_cache_get(), Call to undefined function _views_fetch_plugin_data(), Class 'view' not found..., etc.) start to show up in Apache's error.log.

I double-checked this by downloading views-6.x-3.0-rc3 from the project page, unpacked the archive manually, and got exactly the same behaviour (WSOD...). So deleting the 'Views' directory and then downloading the views-6.x-3.0-rc3 release through drush is definitely not the root cause of the issue here - imho.

However, in my initial report I already mentioned the required "fix" for this issue without recognizing it. The site requires a full Apache httpd restart (/etc/init.d/apache2 restart on Debian) before the WSOD goes away (not a graceful apache2 "reload", not clear the Drupal caches!). At least for my site this is required as well after updating to views-6.x-3.0-rc3, as after downgrading to views-6.x-2.16.

So I'll try to memorize if a WSOD shows up after a major Views version update: restart Apache httpd!

Correction: The Apache restart seems just to mask the WSOD for a while. Back to to views-6.x-2.16 again.

My first attempt to update a Views 2 site directly from views-6.x-2.16 to views-6.x-3.0 leads again to a WSOD on all pages of the site, including admin pages. Apache's error log reports a number of fatal errors:

[Sat Jan 14 18:37:01 2012] [error] [client xxx] PHP Fatal error: require_once(): Failed opening required './sites/all/modules/views/theme/theme.inc' (include_path='sites/all/modules/import_html/coders_php_library:.:/usr/share/php:/usr/share/pear') in /var/www/drupal/sites/all/modules/views/views.module on line 1126

At the path ./sites/all/modules/views/theme/theme.inc, the file "theme.inc" exists:

# ls -lah theme.inc 
-rw-r--r-- 1 6226 6226 34K  4. Jan 00:39 theme/theme.inc

Also, /usr/share/php and sites/all/modules/import_html/* exist, /usr/share/pear does not. To my knowledge, I'm not using any PEAR components in my Views or on the site at all.

[Sat Jan 14 18:37:13 2012] [error] [client xxx] PHP Fatal error: Call to undefined function views_include() in /var/www/drupal/sites/all/modules/views_attach/views_attach.module on line 188

The file ./sites/all/modules/views_attach/views_attach.module exists, and the 'views_attach' module is installed and enabled. The code around the reference line 188 in the fatal error is:

...
 if (empty($used_views)) {
    views_include('cache');
    $cache = views_cache_get("views_attach:nodes");
    if (isset($cache->data)) {
      $used_views = $cache->data;
    }
...

According to 'drush ws' (= "watchdog show"), there is "only" one potentially relevant warning in Drupal's watchdog log:

13975271  14/Jan 19:03  warning  boost  There are php errors on this page, preventing boost from caching. ERROR: Array
                                               [type] => 1
                                               [message] => Maximum execution time of 30 seconds exceeded
                                               [file] => /var/www/

All caches have been cleared through 'drush cc'.

Downgrading back to views-6.x-2.16 seems to work fine, "just" Views 3 breaks the site. Any ideas and/or suggetions how to proceed?

Thanks!

Related issues: #1128028: Call to undefined function views_include() in /all/modules/views_attach/views_attach.module on line 187 and #846122: Fatal error: Call to undefined function views_include() in ..../sites/all/modules/views_attach/ after updating to views 6x.2.11; in the last one, eaton mentioned: "[...] views_include() is a core function of the views module, and if it can't be found, Views itself is not loading correctly." Because of this, eaton closed the 'views_attach' issue. #1128028 was closed because this is supposed not to be a Views issue, so we have a classical deadlock. That's bad since it blocks the migration to Views 3.

I can reproduce the WSODs after updating to Views 3 on several different sites, but I don't have a procedure to reproduce on a fresh site. I suspect that this issue only shows up with real world data; in this case, it might be triggered by the changed pager settings in Views 3 that lead to timeouts. The reason for this suspicion is as follows:

Updating to Views 3 gives me an WSOD, directly after installing the updated views version, running update.php (via drush), clearing the caches (drush cc), and reloading the frontpage. Apache's error.log says:

[Sat Apr 21 20:18:45 2012] [error] [client 12.34.56.78] PHP Fatal error: Call to undefined function views_include() in /var/www/drupal/sites/all/modules/views_attach/views_attach.module on line 188

Next I disable 'views_attach', repeat drush cc and reload the frontpage. Again a WSOD, but pointing to different modules:

[Sat Apr 21 20:20:51 2012] [error] [client 12.34.56.78] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /var/www/drupal/includes/common.inc on line 2575
[Sat Apr 21 20:22:16 2012] [error] [client 12.34.56.78] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /var/www/drupal/includes/theme.inc on line 206, referer: http://.../update.php?op=results
[Sat Apr 21 20:30:18 2012] [error] [client 12.34.56.78] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /var/www/drupal/modules/node/node.module on line 454

For testing purposes I changed the maximum execution time in settings.php like so:

ini_set("max_execution_time",600);

Again, this leads to a WSOD:

[Sun Apr 22 02:16:07 2012] [error] [client 12.34.56.78] PHP Fatal error:  Call to undefined function views_cache_get() in /var/www/drupsl/sites/all/modules/views_attach/views_attach.module on line 189
[Sun Apr 22 02:16:10 2012] [error] [client 91.23.45.67] PHP Fatal error:  Call to undefined function views_cache_get() in /var/www/drupal/sites/all/modules/ctools/views_content/plugins/content_types/views.inc on line 47

After disabling, the WSOD is still there, but the error moves to Ctools. Repeated "PHP Fatal error":

[Sun Apr 22 02:20:07 2012] [error] [client 65.52.104.88] PHP Fatal error: Call to undefined function views_cache_get() in /var/www/drupal/sites/all/modules/ctools/views_content/plugins/content_types/views.inc on line 47

So the error thrown is not very indicative, but the WSOD stays, as long as Views 3 is active. Again, after downgrading to Views 2.16 everything is back to normal.

Conclusion: The WSOD is directly triggered by Views 3; the site goes back to normal after downgrading to Views 2.16. With this procedure, I believe to have excluded 'views_attach' as the root case. Since the Views version directly switches the WSOD on (Views 3.0) and off (Views 2.12), there is a high probability that the root cause has something to do with Views. Since the update directly results in a WSOD and multiple "PHP Fatal errors", I think a "major" priority is justified.

Thanks, obviously I am encountering a situation that should not happen. Since the site runs fine with Views 2, the installation itself shouldn't be too borked; since I am encountering this on different sites, the problem can not be too site specific. I tried switching the WSOD on and of several times by exchanging Views 2.16 and Views 3.0, and for that I downloaded the files multiple times, so I don't believe that anything is missing from the tarball.

PHP Fatal errors:

views_attach.module -> common.inc/theme.inc/node.module -> views.inc [...]

This succession of different "PHP Fatal errors" indicates to me, that the problem is neither views_attach.module, common.inc, theme.inc, node.module, nor views.inc, but something below it. However, I don't know how to debug something like this. Is there anything I can do to help tracking this down?

I was hit by this on just another site. Current success/failure ratio: 50% of all my sites go into a WSOD when udating to Views 3.0 (three sites are OK, three sites can't be updated).

I have no idea what I could do wrong on the update - download the new archive, replace the old views folder, run update.php and clear all caches (drush dl ... ; drush updatedb; drush cc ...). It does not matter if you download and unpack the tarball manually, and #3 is definitely not the problem here; I don't see anything that could be made wrong during the update procedure.

What I can find out myself is already documented in #9 and #10. Actual coding and debugging (as Merlin suggested in #7), beyond following, and trying to resolve the messages in Apache's error.log, is beyond my capabilities.

Btw: The only sites that I could update so far are either extremely simplistic (e.g. no complex Views, no Panels), or the migration started during the development cycle of Views 3 and - maybe - succeede, because I followed the changes from Views 2 to Views 3 in smaller steps.

Obviously, at least part of the problem is that I'm working with real (not synthetic) data; otherways the developers would have run into similar issues themselves. My gut feeling tells me, that the chain of timeouts has something to do with Views' changed behaviour in regard to a) the DISTINCT handling, and b) the paging; imho, both work fundamentally different in Views 3, when working with unaltered Views from Views 2.

Lets assume, that the working View for Views filters out 10 records out of 40,000 nodes, plus it does a DISTINCT that removes a certain number of duplicates from the result set. Additionally, many of my Views are embedded in Panel pages, so mutiple views are run when loading a single page, including the front page. Assuming that the pager settings in Views 3 do not work out of the box as they did in Views 2, a single view might try to load 40k nodes and not 10 (-> timeouts); additionally one might assume that the DISTINCT operator liquidates an average of three duplicates per record in the result set; so the ratio in Views 2 would have been 10 records out of 30 (paging to ten records plus duplicate filtering); the ratio in Views 3 - without editing the Views - might be 120.000 out of 120.000 (no paging out of the box = 40k records in record set; no working DISTINCT out of the box = 40k records multiplied by assumed liquidation rate in Views 2 -> timeouts and probably worse in Views 3). Now permutate this with an average of six Views per Panels page, and you might get an idea where the "PHP fatal errors" might come from, and why they finally end up somewhere in Ctools.

However, this is pure theory and I don't know how to prove it with reasonable effort; also I'm assuming that my observations in regard to DISTINCT and paging are essentially correct. Judging from experience from just two really updated sites is something I wouldn't bet my right hand on, and I have never received confirmation about this.

@couturier: What am I supposed to write? It still does not work, over and over again, once per month, or once per week? That wouldn't make much sense, wouldn't it.

Also I don't see where anyone might have indicated that this actually is an individual problem. The fact still is, that I can not update *any* site to Views 3, except for those two where the update was started with the dev release.

If you want to close this unsolved issue, please use the proper status tag "won't fix".

@couturier: I'll try very hard to not sound hostile, but this kind of suggestions are not helping in any way. You might consider that other people might not be imbecile amoebae, and that there might be reasons to stay with Drupal 6. In our case, all sites we have built during the past eight years, are stuck with D6 because of broken or missing upgrade paths. E.g., 'Image' module, which was used here at d.o a while ago and still has 70k users (!), has no migration path to D6; there is not even a dev release to get Image Attachments into D7; our default input format will not be ported to D6; our access control module will note be ported… I could go on with this for quite some time; in short, Drupal 7 is not even a mid-term option to consider when the sun shines very bright. Also, if we'd seriously consider to migrate without images, without input formats, and without access control, there'd be no Views 2 on D7. So, please forget about bogus like D7 migrations.

@dawehner: If there is anything I can do to help, please let me know [1]. At least the issue is perfectly reproducable for me, which is not the worst starting point to find an error. The nastier question is how much time and energy you are willing/able to spend on this kind of legacy issues, and that one I can not answer for you. Many devs have already left D7 and are heading fo D8, I know that…

[1] What I can provide is administration experience, including Apache troubleshooting and the OS (Debian); we have a dedicated root server, and we can set up a sandbox environment. What I can not provide is PHP debugging capability or prgramming experience.

@couturier: Yes, start from scratch appears to be the most common "migration" approach to get from D6 to D7. The small issue with this is that we have to deal with 14+ sites, 5-8 years old, with an average of 60k nodes. If we have to start this from scratch, it will be anything but Drupal.

@dawehner: Thanks for your mail; I'll either put a site backup together without image files (~20 GB ;), or simply set up a sandbox and then get back to you (you'll probably need SSH access, I assume). Please give me a couple of days...