Zach's $50 white-screen-of-death challenge! (celebrity challenger: views.module)

You should use php_flag to set boolean values instead of php_value.
(http://us2.php.net/configuration.changes)

I'd also use 'php_flag log_errors on' instead of 'php_flag log_errors 1'

You might also add an error_log directive with the file name of where to save the error log.

In looking at the PHP info it is reporting that both server-wide and for the local directory log_errors is set to OFF but likely because of the php_flag being needed.

------------------------------
Adding Understanding

Hmm, that looks right... (although I should mention that notices wouldn't stop anything else from being displayed).

The only thing I can think of is that the root configuration--in httpd.conf or php.ini or whichever--is disallowing you from enabling error reporting (not sure why it would be configured that way and foggy about how it could be). Presumably since you're using Drupal .htaccess files are already allowed to override stuff.

You could try a good old phpinfo(); in the directory to see whether the error reporting is actually being set as you are specifying. Of course, it's always possible phpinfo has been disallowed for security reasons. In that case, here's a simple test I might try: make a test.php file with some really invalid code in the same directory that has your .htaccess.

if (() {{

Visit the file directly in your browser and see if you get a parse error. If you don't, then error messages are still being suppressed for some reason. If you do, then it seems there is no error message and the problem is something else (drupal php isn't getting executed at all, or is and is just returning an empty string instead of the page source, or whatever other problem).

Another thought, you could try setting the error reporting level from within said PHP script in case .htaccess isn't being interpreted properly. See:
http://us3.php.net/manual/en/function.error-reporting.php

Because the views_theme_wizard kept returning you errors on functions that used the cache. Here's the reasoning.

This code was returning an undefined variable (namely, $items):

function views_theme_wizard_menu($may_cache) {
  if ($may_cache) {
    $items[] = array(
      'path' => 'admin/views/wizard',
      'access' => user_access('administer views'),
      'title' => t('theme wizard'),
      'callback' => 'views_theme_wizard_page',
      'type' => MENU_LOCAL_TASK,
    );
  }
  return $items;
}

...because it's somehow assuming that the $may_cache is set to TRUE. The code should actually read like:

function views_theme_wizard_menu($may_cache) {
  $items = array();
  if ($may_cache) {
  ...

(although apprently this is not a problem per se, since undefined variables take a NULL value, which is fine for hook_menu to return). Well that was the logic behind my reasoning: that by removing the theme_...module you'd somehow circumvent the problem (even though the *undefined variable* notice is not a problem normally.) Still, the $items array was left undefined, meaning that $may_cache is a parameter that is set to FALSE -- which in turn means that Drupal *thinks* the module is already set in admin and that it is cached (which in your case is an error, most likely triggered by the state of your database).

Everything points to a caching problem by Drupal. Even though views.module implements hook_menu -- function views_menu($may_cache) -- the function that implements it does initialize $items explicitely. Still, if the $may_cache is set to false, then the function will bypass building the navigation menu. This will create a problem as the menu block ends up with no content -- and God knows what this does to Drupal. In any case, I'd try the following steps:

remove the views module completely
run update.php on the database (from the administer/module: it's a link in the text, just in case you didn't know) : that will clear the Drupal cache
exit Drupal, put the views module back in the module folder, re-start Drupal and enable views and its related modules
run update.php again but this time for the views module only (and the related ones such as ui and rss and theme) -- choose the module name to update in the *select version* option.
finally, set the access rights accordingly

I guess the cache problem is due to the fact that you are using a database that's filled already. As to why this error comes up as critical under PHP5 but not under PHP4, I have no idea. lol

Hope this helps

efolia