To reproduce:
1) Install 1/1/2012 7.x dev(overlay module enabled by default)
2) Got to admin appearance and enable Garland(or any other theme)
3) All calls to admin function there-on results in WSOD

To point to overlay module repeat above but add step
1.5) Disable overlay module from admin/modules
3) No problems

Did try doing other admin things before enabling a theme, but that is only thing that seems to cause failure. Can go back to drupal home after failure and other functions work, but admin always fails.

CommentFileSizeAuthor
#15 wtf.patch545 bytesAnonymous (not verified)

Comments

dcrocks’s picture

dcrocks commented

I can confirm the same failure on drupal 8 from git.

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented

WSOD often means that you have not configured your PHP environment for development, see http://php.net/manual/en/errorfunc.configuration.php

Any error messages after tweaking those settings?

xjm’s picture

xjm
she/her
Primary language English
commented
Version: 7.x-dev » 8.x-dev
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

I am unable to duplicate this using the latest D8 from git, with either standard or minimal install profiles. In both cases both enabling a theme and setting an admin theme at admin/appearance work fine whether or not overlay is enabled.

dcrocks’s picture

dcrocks commented

I have slightly older versions of drupal previously installed and I don't get the error there. Plus I got it on 2 different machines. I am on OS X 10.6.8, php 5.3.6, and using sqlite for the database. I use the standard install. I can't think of anything I have changed on my system that might cause this.

I am not seeing any errors on the apache error console, nor anything with firefox's error console.

xjm’s picture

xjm
she/her
Primary language English
commented

Is it possible to turn on error reporting in your php.ini? I'm also using OSX, but with MAMP.

I'll try again with a fresh clone in case it's an issue with missing files or something.

xjm’s picture

xjm
she/her
Primary language English
commented
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

Okay, I CAN reproduce this with a fresh clone after installing D8 with the standard profile, going to admin/appearance, and enabling Stark. The fact that it happens with a fresh clone leads me to suspect missing files or suchlike. It's a blank screen with no PHP errors (error reporting and xdebug and enabled).

This would be a release blocker.

dcrocks’s picture

dcrocks commented
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

log_errors is on in php.ini but I am not seeing any php errors. Nor am I seeing errors on firefox's error console or any place else. Got a clean clone of 7,x, went through standard install with sqlite, everything is fine until I enable a disabled theme(stark this time), then any call to admin menu results in a white screen.

xjm’s picture

xjm
she/her
Primary language English
commented
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

xpost

dcrocks’s picture

dcrocks commented
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

I should note that the theme is getting enabled. If I got back to drupal home after the WS I see "The Stark theme has been enabled" in the message area. And it look ok in the database.

xjm’s picture

xjm
she/her
Primary language English
commented
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

There appears to be a problem with the path writing. I get redirected to http://mysite/admin when I try to visit http://mysite/#overlay=admin after enabling a new theme.

dcrocks’s picture

dcrocks commented

I didn't mean to reset the issue.

xjm’s picture

xjm
she/her
Primary language English
commented

beejeebus tracked this to #1371484: Private properties in abstract class DrupalCacheArray. We confirmed that this issue's commits introduce this bug in both D7 and D8.

xjm’s picture

xjm
she/her
Primary language English
commented
Assigned: Unassigned » xjm

Attempting to write a test that catches this.

xjm’s picture

xjm
she/her
Primary language English
commented
Assigned: xjm » Unassigned

Alright, so the bug is only reproducible if you click the enable link from within the overlay, which means it cannot be reproduced in our test suite. Alas.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs review
StatusFileSize
new wtf.patch545 bytes

so, here's a rollback patch, fixes the problem for me.

dcrocks’s picture

dcrocks commented

Tested against 7.x. Works. Cache, can't live without it.

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Needs review » Closed (duplicate)

The commit that caused this has been reverted. We'll need to do some more work in #1371484: Private properties in abstract class DrupalCacheArray to figure out why ThemeRegistry is changing the private variables once we let it.

Thanks dcrocks for reporting this!

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Further info