Explore removing wpmu activation styles

[joedolson]

This was briefly raised in #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.

[johnjamesjacoby]

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?

[johnjamesjacoby]

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 it completely.

[sabernhardt]

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

[joedolson]

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.

[rishabhwp]

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?

[johnjamesjacoby]

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.

Experiments with more thorough styling in wp-activate.php

• Adds max-width, padding, text-align, and background-color for main wrapper.
• Updates margins
• Adds link color
• Separately handles sizing for submit and key inputs.
• Changes error background color to meet accessibility standards
• Adds base font sizing

Trac ticket: https://core.trac.wordpress.org/ticket/63861

[joedolson]

This is actually pretty nasty to wrestle with. The practical truth is that because this is implemented by just appending the site's theme header and footer, but isn't aware of any other wrappers, there's no realistic way for the activation page to reliably inherit the site's styles.

So, in my opinion, we either need to be more opinionated: and impose quite a few additional styles, so that colors and backgrounds are reliably set, or we need to be less opinionated, and set no styles, so we're not imposing any barriers to overriding styles.

I agree with @johnjamesjacoby that this is something that's used by a relatively tiny percentage of sites, but when it *is* used, it's definitely a style.

After exploring this, and exploring alternate styles, I'm still leaning more towards just removing the styles entirely. I do think, however, that this would require being committed very early in a cycle and broadcast widely, to give implementers any chance to check.

No colors we choose can realistically mesh with a site, so I think we should limit ourselves to pretty basic colors if we go with styling.

[sabernhardt]

This is actually pretty nasty to wrestle with.

Yes. I would recommend fewer new or opinionated styles, though I still wanted to set the #key input text direction to LTR ​for RTL languages.

These styles are unlikely to be generally useful in design, and are specifically problematic for contrast in dark mode or dark designs.

Could you share how the styles were problematic with the ​Gravity Forms User Registration plugin? If it was from the .error colors, I could not find where the class might be added in core (even going back to when ​wp-activate.php was created).

Looking at each of the current selectors:

1. Container: On #40361, I wanted to prevent text touching the side of the window/viewport, and I moved the 90% width value from the input fields to the container. Adding a small amount of padding (PR 10823 has 1.5rem) would achieve the same purpose. Of course, almost all block themes have header and footer text that touches the side because they still use the old theme-compat templates for the signup and activate pages (#63499, #55023).
2. Form: Using a rem measurement can make the value more uniform among themes, but wp-signup uses 2em and 1.5rem would still have some differences when the themes set the root font size. For example, Twenty Fifteen sets the root size to 62.5% (usually 10 pixels) and Twenty Nineteen sets it to 22 pixels.
3. Inputs (#submit, #key): Inputs inherit colors and focus styles from the theme, so adding a specific background color to the container is not very friendly. I do not mind changing the submit to auto width, which could help when the paragraphs have no margin (such as Twenty Twenty-One).
4. #language element: Unless someone knows where this is added, I would remove the rule.
5. .error class: I was going to suggest removing this rule because I could not find the class in core. If the background color is changed, it could reuse #ffebe8 from wp-signup styles.
6. span.h3: I considered switching these elements to strong tags so they would fit better with theme styles, but some sites can have special CSS for those span elements. Directory searches found ​one theme and ​a few plugins that matched span.h3. If the font weight remains at 600, I agree with removing the padding and larger font size.