Make WordPress Core

Opened 3 months ago

Last modified 13 days ago

#63861 assigned enhancement

Explore removing wpmu activation styles

Reported by: joedolson's profile joedolson Owned by:
Milestone: 7.0 Priority: normal
Severity: normal Version:
Component: General Keywords: needs-patch
Focuses: accessibility, multisite Cc:

Description

This was briefly raised in https://core.trac.wordpress.org/ticket/40361, but wasn't resolved in that ticket.

The wpmu_activate_stylesheet action loads inline CSS when activating a user on the front end. These styles are unlikely to be generally useful in design, and are specifically problematic for contrast in dark mode or dark designs.

Even if they're potentially useful for backwards compatibility, it seems past time to reconsider them. There are many other ways to provide styles in this context.

Change History (8)

#1 @johnjamesjacoby
3 months ago

  • Keywords needs-patch added
  • Type changed from defect (bug) to enhancement

I am +1 to modernizing this, both visually and the overall approach to getting the CSS into the page contents.

I am probably -1 to removing it entirely without adding something better, because the experience is pretty bad with no styling at all and this CSS is limited only to wp-activate.php. See: #mu724

The same goes for wpmu_signup_stylesheet and wp-signup.php. See: #mu292.

I'm switching this from a bug to an enhancement – my thinking is, it'd be nice to enhance but isn't currently buggy?

#2 @johnjamesjacoby
3 months ago

These styles are unlikely to be generally useful in design

I agree!

I wonder if the default styling of these pages were some % more attractive, if more people would rely on them.

Multisite represents such a small number of installs, fewer still use these default pages, and building a world-class user registration system is unlikely to ever be a core focus, so I can totally understand the desire to nuke this styling completely.

Last edited 3 months ago by johnjamesjacoby (previous) (diff)

#3 @sabernhardt
3 months ago

The .wp-activate-container .error text color added in #40361 is a bug (and my mistake) with a contrast of 4.41:1.
I wanted to assign both text and background color, but I apparently copied #333 from the signup styles without noticing that the activate page's #f66 background was significantly darker than #ffebe8.

Related: #23637, #31928

#4 @joedolson
3 months ago

I would consider it buggy, although the *existence* of it isn't necessarily a bug.

I'd like to see these styles easily disabled, and I'd like to see all of the color references removed, as there really isn't any way of ensuring that colors declared in this context are able to adapt to the design context.

#5 @rishabhwp
3 months ago

Hey,
I went through the issue and the concerns raised about the hardcoded styles. One solution I can think of is adding a filter to make these styles easily disableable, something like:

function wpmu_activate_stylesheet() {
    /**
     * Filters whether to output the default activation page styles.
     *
     * @param bool $load_styles Whether to load the default styles. Default true.
     */
    if ( ! apply_filters( 'wpmu_activate_stylesheet', true ) ) {
        return;
    }
    
    // existing styles here (with problematic colors removed)
}

This will allow developers to easily disable the default styles with:

add_filter( 'wpmu_activate_stylesheet', '__return_false' );

The same approach could be applied to wpmu_signup_stylesheet() in wp-signup.php.
This addresses the immediate need for disabling these styles while maintaining backward compatibility. Developers who want custom styling can disable the defaults and provide their own, while sites that rely on the current behavior continue to work.

Would this be a reasonable approach to move forward with?

#6 @johnjamesjacoby
3 months ago

Would this be a reasonable approach to move forward with?

I don’t think so.

These styles can already be completely unhooked without adding any new code to WordPress.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


13 days ago

#8 @joedolson
13 days ago

  • Milestone changed from Awaiting Review to 7.0
Note: See TracTickets for help on using tickets.