Bug #6644
openWhite Screen at Login Pge
Added by Luke Waltzer over 7 years ago. Updated over 7 years ago.
0%
Description
Getting a white screen at https://jitpstaging.commons.gc.cuny.edu/wp-login.php (all browsers). Once logged into Commons in the browser, I can navigate to the Dashboard by manually navigating to https://jitpstaging.commons.gc.cuny.edu/wp-admin/, but the http://jitpstaging.commons.gc.cuny.edu/wp-login.php stays white.
This issue was first reported by Amanda Licastro.
Related issues
Updated by Boone Gorges over 7 years ago
- Status changed from New to Reporter Feedback
An element div#loader is being overlaid over the rest of the login page.
It appears that it's coming from the Roma theme. Maybe you know more about how/why this loader element appears? (Looks like it's supposed to be a spinner, but is broken on wp-login.)
I'm not sure why this would be coming up only now. Is this the same theme you run on the production JITP site?
A CSS rule can be used to override:
body.login #loader {
display: none;
}
Updated by Luke Waltzer over 7 years ago
Yes, same as on production, and same issue there. Could have been missed before, or could have been introduced in a recent update.
Will implement override rule-- thanks, Boone.
Updated by Boone Gorges over 7 years ago
- Assignee changed from Boone Gorges to Raymond Hoh
- Target version set to Not tracked
Thanks, Luke.
It dawned on me that this is probably due to the feature (introduced in 1.10) that allows wp-login.php to be styled like the rest of the site. In this specific case, there appeared to be a few weird things happening - the theme expected a certain wrapper div, and perhaps expected fontawesome to be enqueued. I wonder if this is something we should be worried about more generally, or if it's something we should take on a case-by-case basis. Ray, do you have thoughts?
Updated by Raymond Hoh over 7 years ago
Boone Gorges wrote:
In this specific case, there appeared to be a few weird things happening - the theme expected a certain wrapper div, and perhaps expected fontawesome to be enqueued.
The problem is Roma's JS doesn't appear to be outputted. This means that Roma's JS cannot remove the loading wrapper div. Loading containers that are later removed by JS is really poor UX. I wish designers would stop doing this.
Anyway, I spent about an hour trying to figure out why Roma's JS isn't being rendered, but Roma's theme appears to be enqueued properly in its theme's functions.php file.
I'll need to do more debugging here.
I wonder if this is something we should be worried about more generally, or if it's something we should take on a case-by-case basis.
The way that the native login code is written means that it expects the header.php and footer.php template parts to be functional without the "middle" portion of the template.
WordPress default themes and most well-coded themes should work, but others might not.
Updated by Boone Gorges over 7 years ago
Thanks, Ray. We do have a CSS-based workaround for Roma, so I don't think it's worth spending a lot more timing debugging.
Given your comments, it sounds reasonable that we'd expect your login styling to work on the vast majority of themes, and it should be feasible to fix specific themes when the problem arises.
We already have an infrastructure for shipping theme-specific fixes. See wp-content/mu-plugins/cac-theme-fixes.php. Shall we roll the Roma fix into a stylesheet loaded here, and call it good enough?
Updated by Boone Gorges over 7 years ago
Hi Ray - I happened to have need of your themed wp-login.php code last week, so I stole it :) In the process, I ran into some weird issues - which may be connected to this ticket - with scripts not being properly enqueued. Because get_header() was being called twice - once for $header and once for $template_header - some scripts were getting moved to the `WP_Scripts::done` array when the first of these headers was rendered. But your output buffer trick uses the second rendered header, which means that the <script> elements are lost. The solution I ended up with is kinda bonkers, but maybe not any crazier than the rest of what you're doing. Basically, I fished out all the <script> tags from each header chunk, and combined them, something like this:
// Grab a list of all script elements (ignoring those that span multiple lines, which are generally inline scripts)
preg_match_all( '/<script[^>]+[^<]+<\/script>/', $header, $matches_1 );
preg_match_all( '/<script[^>]+[^<]+<\/script>/', $template_header, $matches_2 );
$scripts = array_merge( $matches_1[0], $matches_2[0] );
$login_classes = esc_attr( implode( ' ', $cac_login_classes ) );
$template_header = str_replace( '<body class="', '<body class="login ' . $login_classes . ' ', $template_header );
$body_pos = strpos( $header, '<body class' );
$body_close_pos = strpos( $header, '>', $body_pos );
$body_pos_2 = strpos( $template_header, '<body class' );
$body_close_pos_2 = strpos( $template_header, '>', $body_pos_2 );
$template_header = preg_replace( '/<script[^>]+[^<]+<\/script>/', '', $template_header );
// Make sure that the combined script list is included in the end result. To be sure it's in a valid location in <head>, I put it just before the first <script> tag that is already in $template_header #shrug
$script_pos = strpos( $template_header, '<script' );
$template_header = substr( $template_header, 0, $script_pos ) . implode( "\n", $scripts ) . substr( $template_header, $script_pos );
echo $template_header;
echo substr( $header, $body_close_pos + 1 );
In theory, the same thing could be done for stylesheets. Is this ridiculous?
Updated by Raymond Hoh over 4 years ago
- Related to Bug #12108: Password reset styling/scripts don't work correctly added