3

Here are the facts:

  • Made a clean install of Drupal 6.20
  • Installed and enabled Admin Menu module

From this point on I can't access any admin/* page however I can access to both node/* and user/*...

PHP log:

No entries

Apache error log:

No entries

Apache access log:

127.0.0.1 - - [10/Mar/2011:16:22:16 +0000] "GET /drupal_testes/ HTTP/1.0" 200 5771
127.0.0.1 - - [10/Mar/2011:16:22:14 +0000] "GET /drupal_testes/admin HTTP/1.1" 200 -

DB table watchdog:

Nothing serious... 

And that's all, for a single access to /drupal_testes/admin...
Disabling admin_menu (at the system table) does work. Also, as a side note, when I go to admin/build/modules and try to enable Admin Menu again the page will take forever to load and end in a WSOD.
After that if I go to drupal_testes/node the admin_menu is active and working, except for the admin/* pages.

I'm aware of WSOD Walkthrough but none of the reasons seems to apply this case..
Any idea why can this be happening?


Edit #4

  • Exactly the same behaviour when installing Token

Edit #5

  • Installing CCK, which in theory is much heavier than Token or Admin Menu, presents no problems.
  • Flushing the cache_* tables changes nothing.
  • Increasing php.ini memory_limit didn't make any difference...

Although the problem is solved by disabling the offending modules, the goal is to have them active and working properly...

  • Fully documented article about WSOD: The White Screen of Death (Completely Blank Page) – Nikit Mar 10 '11 at 22:12
  • why a downvote? setting the devel error reporting in the index.php is the best practice to bebug a wsod. – Strae Mar 11 '11 at 0:47
  • "I'm aware of WSOD Walkthrough but none of the reasons seems to apply this case.." have you added the error reporting in the index.php? Do you get some errors then? – Strae Mar 11 '11 at 0:48
  • @Nikit, that isn't helpful at all. I said I was aware of it in the OP and nothing in there applied/helped this case. – acm Mar 11 '11 at 10:28
  • @DaNieL, yes, I did. No errors. Just a long wait for the page to load and a final WSOD. – acm Mar 11 '11 at 10:29
4

If you just started a new site / doesn't contain any data yet as you seem to indicate in your question, it may be faster to reinstall Drupal than search for the source of the WSOD.


Otherwise, you could have a look in the database directly:

  • first, check the watchdog table: it may have error messages that don't show up in Apache and PHP logs

  • then, empty the caches by truncating every table named cache_something

  • then if you're sure this module is the one that caused the problem, you can edit the list of enabled modules in table system: find the module in the list and change its status to "0"

But if you make any modification directly in the database, make sure to save a backup first, just in case ;-)

  • Uops, forgot to mention it: there are no errors @ watchdog. Thanks for the other advices, will check those now. – acm Mar 10 '11 at 16:43
  • 1
    About the second point, empty all cache_something table except cache_form. That's not actually a cache but contains build information about forms. It doesn't matter for a new/development site, but it would for example invalidate all forms that users are currently filling out somewhere, so don't delete that on a production site. – Berdir Mar 10 '11 at 17:01
  • @Berdir Ah yes, good point – wildpeaks Mar 10 '11 at 18:10
  • Well, since the only thing that really worked was to reinstall.. You'll get the rep. :-) – acm Mar 15 '11 at 18:12
1

Make sure your PHP memory limit is set to 32 MB (or greater), and that you have output buffering enabled.

  • I actually set my memory_limit to 62M in development and adjust it up or down as needed. – Codeblind Mar 10 '11 at 22:02
  • I would recommend setting it to 256 MB if you can just to see if this is the issue, you can always bring it down later – wiifm Mar 11 '11 at 0:22
  • I had my memory_limit = 16M. But increasing the value changed nothing. Good effort though. – acm Mar 11 '11 at 10:31
  • Check if output buffering is enabled and a buffer handler has been set. Core doesn't require it, but some modules do. – Codeblind Mar 11 '11 at 14:38
0

I don't know if this is what is happening in your case, but a BOM signature present before the starting <?php is difficult to be seen. I had a problem with a module, and it came out that the WSOD was caused by the BOM signature added by the editor I was using, which then didn't show when I edited the file with my usual editor. I then discovered that the editor was set to add the BOM signature by default.

There are also some Unicode characters that have a purpose similar to a space, but they are not show on some editors. This happened to me too, and I was not able to understand the reason of the WSOD until I didn't post the content of the file in a forum, and used Firefox to see that forum page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.