_default_wp_die_handler css referencing logic is fragile and doesn't always work

[westi]

The logic for determining where the install and install-rtl css files are in the default wp_die handler is fragile and breaks relatively easily.

For example calling wp_die in sunrise.php in a multisite install when someone accesses anywhere except for the root of a site.

The best solution to this is to move the CSS inline and remove all the wp-admin determining logic from the code.

[kawauso]

type="text/css" for validation

[kawauso]

Added a patch with type="text/css" for the <style> tag because I'm a pedant.

[westi]

In [18534]:

Move the CSS inline to wp_die so that it is always available. Fixes #17975, props kawauso for the style type update.

[dd32]

This has removed some styles which are used by the config creater, The installer error pages might also be affected.

Specifically, h1 styling, list styling, button styling and the fonts don't seem right, Simplest way to see this is to attempt an install with incorrect credentials, the next page uses the most missing styles.

[dd32]

Once I've started going through this, I've got at least another 100 lines of CSS which the installer uses.

My suggestion here is to re-instate the wp-admin guessing, or at least part of it, If we can tell for 100% certaintity the location of the CSS files, use them, otherwise fall back to the minimal inline styles.

POC patch coming up..

[dd32]

Another reason why the installer can't just have all the CSS inline, the Go back button backgrounds are set via CSS backgrounds, causing the admin path needing to be known anyway.

An alternate suggestion would be to pass the admin stylesheet in via the $args, and fallback to the inline styles if thats not provided.. but feels like that'd break too under certain conditions.

[westi]

maybe the installer should not use wp_die to displayerror messages and instead display the itself?

[dd32]

maybe the installer should not use wp_die to displayerror messages and instead display the itself?

I completely agree with you there actually, the validation errors should be inline, and i'll be attacking that in a seperate ticket shortly i think.

That being said, The wp_die() instance I was refering to there comes directly from wpdb, and I expect a number of plugins which utilise wp_die() expect the h1 and button stylings at least.

The suggested patch from me could be vastly simplified, instead, if it just checked for admin_url() being valid and enqueued the stylesheet then perhaps..

[dd32]

The wp_die styling changes have also affected The "no configuration file exists" screen along with the Database upgrade screen.

[SergeyBiryukov]

Replying to dd32:

The wp_die styling changes have also affected The "no configuration file exists" screen

Just stumbled upon this while submitting #18576. In particular, link colors and button styles are missing.

[ocean90]

Related: #18866

[ocean90]

Closed as a dup #18866.

[ocean90]

Question is stylesheet or inline style?

[SergeyBiryukov]

Styles for installation screens were revamped in [19297].

The only regression is that "Create a Configuration File" is now a link rather than a button, the rest seems good.

[westi]

Inline style additions to fix the create a config button

[westi]

17975-create-config-button-style.diff fixed the create a config button for me.

If everyone is happy with this patch I think we can then close off this ticket.

[SergeyBiryukov]

17975.button.patch​ is a slightly updated olleicua's patch from #18866. Removed unneeded vendor prefixes for border-radius as per azaozz's comment in #18576.

17975-create-config-button-style.diff​ seems to be more comprehensive and matches 3.2 style better.

[westi]

In [19417]:

Add button styles to the inline styles in _default_wp_die_handler so that the Create a Config button is styled again. Fixes #17975.

[dd32]

In [20209]:

Restore the h1 styling for wp_die(), primarily affects database down messages. See #17975