Bug #6644: White Screen at Login Pge - CUNY Academic Commons - CUNY Graduate Center - Project Tracking System

Custom queries

. 2.4.11 open
2.5.0 open
2.5.0 open (by category)
2.5.0 open (by tracker)
High Priority Issues by User
Inbox (no milestone)
My Assigned Issues (by milestone)
My Watched Issues (by milestone)
Not Tracked - grouped by assignee
Not tracked (milestone-independent)

Actions

Copy link

Bug #6644

closed

White Screen at Login Pge

Added by Luke Waltzer about 8 years ago. Updated 3 months ago.

Status:

Duplicate

Priority name:

High

Assignee:

Raymond Hoh

Category name:

Target version:

Not tracked

Start date:

2016-11-08

Due date:

% Done:

Estimated time:

Deployment actions:

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

Related to CUNY Academic Commons - Bug #12108: Password reset styling/scripts don't work correctly

Resolved

Raymond Hoh

2019-11-18

Actions

Issue # Delay: days Cancel

History
Notes
Property changes

Actions

Copy link

Updated by Boone Gorges about 8 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;
}

Actions

Copy link

Updated by Luke Waltzer about 8 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.

Actions

Copy link

Updated by Boone Gorges about 8 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?

Actions

Copy link

Updated by Raymond Hoh about 8 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.

Actions

Copy link

Updated by Boone Gorges about 8 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?

Actions

Copy link

Updated by Boone Gorges about 8 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?

Actions

Copy link