My site has had views installed for a long time. I started to make some changes this morning and started getting WSOD's all over. I've ended up removing my views, completely uninstalling views, and starting with a fresh views install. (I did uninstall views and install it again)

Going to admin/build/views results in a WSOD and trying to use the WSOD module to capture information gives zero information about the WSOD.

I can get into admin/build/views/tools and cleared the cache etc but that made no change. I could get into a couple other views tabs, tried to add a view but it WSOD'd on the second page of the wizard.

There's nothing printed in the error log file. However WSOD did leave this in the recent activity log. This is the behavior it gave this morning that started this. I wasn't able to find anything about this and the code in the relevant function didn't make sense.

menu_execute_active_handler(): returned NULL - it's very bad!
WSOD detected! Checking for problems...
ERROR: menu_execute_active_handler() returned empty value!
Validating theme hooks...
Validation theme hooks completed.
Included render file: admin.inc
Checking views_ui_list_views() page callback...
ERROR: Callback: views_ui_list_views() returned empty content!
NOTICE: router_item = Array ( [path] => admin/build/views [load_functions] => [to_arg_functions] => [access_callback] => user_access [access_arguments] => a:1:{i:0;s:16:"administer views";} [page_callback] => views_ui_list_views [page_arguments] => Array ( ) [fit] => 7 [number_parts] => 3 [tab_parent] => [tab_root] => admin/build/views [title] => Views [title_callback] => t [title_arguments] => [type] => 6 [block_callback] => [description] => Views are customized lists of content on your system; they are highly configurable and give you control over how lists of content are presented. [position] => [weight] => 0 [file] => sites/all/modules/views/includes/admin.inc [href] => admin/build/views [options] => Array ( ) [access] => 1 [localized_options] => Array ( ) [map] => Array ( [0] => admin [1] => build [2] => views ) ) !
Cleared cache via cache_clear_all()
Cleared cache via drupal_flush_all_caches()
Rebuilded module cache.
Done.

Comments

merlinofchaos’s picture

That indicates something is wrong with the theme function that generates the view list, I think. Make sure the theme directory is intact?

reikiman’s picture

mainmini:~ david$ diff -ur drupal-6.10/themes/ drupalv6/themes/

This returns nothing.. 'drupalv6' is the copy I use for my sites, drupal-6.10 was just downloaded from drupal.org. Further my core drupal is unmodified from 6.10.

My site is currently configured for the garland theme. FWIW Some of the errors earlier in the day were theme related.. hmm..

reikiman’s picture

Hmm, checking more closely and finding my views & cck modules are out of date. Have updated them to latest w/ no change in the WSOD. The themes are all intact from their distribution.

reikiman’s picture

Put some tracing into menu_execute_active_handler and its last call is views_ui_list_views (with no arguments)

reikiman’s picture

Oh I See.. views_ui_list_views just does theme('views_ui_list_views') .. hmm..

reikiman’s picture

In views_ui_list_views, theme('views_ui_list_views') returns an empty string.

reikiman’s picture

I'm stuck here... I'm seeing that views_ui_list_views is declared with

    'views_ui_list_views' => array(
      'template' => 'views-ui-list-views',
      'path' => "$path/theme",
    ),

And therefore it should be processing theme/views-ui-list-views.tpl.php. The file is there etc. I'm at a loss to work out where in the database or files to look for the problem. Took a look in Pro Drupal Development and it talks about a theme registry and it's not clear where that is, though I do find with the cache browser module an item in the cache named 'cache' which is named 'theme_registry:garland' and when I switch to the Wabi themethat item changes name to 'theme_registry:wabi'. There is no objects in that table with 'views' in its name.

reikiman’s picture

Got further... this test in theme() is being triggered

  if (!isset($hooks[$hook])) {
    watchdog('theme', 'no hooks for %hook', array('%hook' => $hook), WATCHDOG_ERROR);
    return;
  }
merlinofchaos’s picture

This indicates that somehow the theme hook isn't being registered. I would investigate the function 'views_theme()' during theme registration (which only happens occasionally. The easiest way to force it is to clear the 'cache' table).

reikiman’s picture

Found a similar issue: http://drupal.org/node/251441

reikiman’s picture

I put watchdog statements in views_theme and views_ui_theme and haven't gotten any indication that these are being called. Nothing matching the watchdog statements makes it into the watchdog table.

I've tried clearing the cache through both the Performance settings, the Cache Browser page, and going to the database command line and typing "DELETE FROM cache_xyzzy"

As noted in the other issue, I've tried uninstalling the views module and re-enabling it. No go.

merlinofchaos’s picture

There's something really wrong with your Drupal install if views_theme() is not being called. It is a core hook and should always be called when the theme registry is rebuilt.

reikiman’s picture

Status: Active » Closed (fixed)

Thanks.. I decided to punt and take a look at import/export tools. I started with a fresh install, enabled the same modules, installed the backup/migrate module, exported selected tables, and imported them to the fresh install. It worked fine the second time through, though I still have a few bits and bobs to get right.

I think this kind of problem points to some of the horrible flaws of Drupal. e.g. there ought to be a core import/export functionality that exports nodes & fields to an XML file. e.g. the debugging and diagnosis tools are pitifully inadequate.

That said I'm still happy with Drupal.. I suppose someone would suggest putting my money where my mouth is and make some code to address these problems.

conniec’s picture

Ditto for me. I can't even get past /node Am reinstalling Drupal core right now.

this happened right after I deleted a view I was not using--but another view was cloned from it. Is this a clue?
Connie

conniec’s picture

My problem and my fix:
The problem occurred because I deleted a view I had made. But it gets a bit more complicated than that--
I had created a custom block so that I could add PHP code to use the view when a particular arg was called. The PHP code was not faulty. Everything worked great until I made the mistake of deleting that view before I disabled/deleted the custom block that called that view.

I couldn't get to anything but the front page, beucase that particular block was set to display on every page but the front page. Thank goodness I had access to the front page or I could not have found this. (Two days as it was {sigh}

So, I found this problem by going straight to the system table in my database and disabling the php module. This made the php code show up in the block on the front page and also gave me access to the admin pages. I disabled deleted the custom block in admin/build/block

This is a long write-up and may not help anyone else--but then again-maybe?
Merlin, I certainly don't expect you to be able to fix my sheer stupidity, but I'm not marking this as closed since I didn't open it and I can't say that this is anyone else's problem.

Connie

cubata’s picture

>>This is a long write-up and may not help anyone else--but then again-maybe?

It did help thanks. I stupidly deleted taxonomy terms used in a views-based menu-block. By disabling the views module in the system table I could regain access....