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 this styling 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.

[joedolson]

What adding the background/foreground colors does is ensure that the container will have adequate contrast. There is no guarantee that the colors will be inherited appropriately; it depends on what container they end up in and how colors are applied in the CSS.

But I also agree that just *not* applying any colors at all ensures that we're at least not causing any problems, and means there's no risk of accidentally overriding existing colors.

Removing the error class seems fine.

I don't think it's an option to remove span.h3, as those will definitely have styles targeting them; but reducing the customizations is helpful, to me.

#language is used by wp_install_language_form(), which is rendered in install.php and in setup-config.php; but I don't think there's any case where it would appear in wp-activate.php. But this CSS selector has been present since this was originally added to core 17 years ago, and I don't see anything obvious. I don't think it has any current relevance, even if it once did.

[joedolson]

And in response to sharing how this caused problems with GF; unfortunately, I don't remember. I don't really see how these styles could have caused the problem I was experiencing.

[joedolson]

To test:

1) Set up a multisite network.
2) Add a new user, sending them an email to activate their account.
3) Follow the link in the email to the activation screen.
4) Compare the previous styles to the new styles.

Ideally, the new styles should be an objective improvement in most themes. It is not necessarily the expectation that they will "work" with all themes, but they shouldn't create any new problems.

Preferably, test with all WordPress bundled themes at minimum.

[r1k0]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/10823

Environment

• WordPress: 7.0-alpha-20260213.003526
• PHP: 8.3.30
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 144.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Email Logger
  • Test Reports 1.2.1

Steps taken

In wp-activate.php while add a new user:

1. In a multisite install, add a new user, sending them an email.
2. I used an Email Logger plugin, to capture the email.
3. In your network dashboard, click the email log menu item.
4. Go to the activation link.
5. Observe the pages styling before applying the patch and after.
6. ✅ Patch is solving the problem

In wp-activate.php with an input field to enter activation key:

1. In a multisite, head over to yoursite.com/wp-activate.php
2. Observe the pages styling before applying the patch and after.
3. ✅ Patch is solving the problem.

In wp-signup.php:

1. In a multisite install, ensure that the Both sites and user accounts can be registered under Settings > Network settings > Allow new registrations is selected.
2. In an incognito tab head over to yoursite.com/wp-signup.php.
3. Observe the pages styling before applying the patch and after.
4. ✅ Patch is solving the problem.

Expected result

• Font size and font weight of some of the elements in the wp-activate.php and `wp-signup.php has changed.
• Margin and paddings of the some of the elements in the wp-activate.php and `wp-signup.php has changed.
• Submit button width has been reduced.

Additional Notes

• While most elements have the new styling after applying the patch, the submit button in the 2015 theme has a width:100%, making it fill its container. The theme styles for this button have a higher specificity than the styles in this patch.
• The submit button in 2013,2014, and 2016 has a width of auto(does the same thing as the patch), which comes from the theme's styles. This isn't really an issue, but something to take note of.
• Tested with all WordPress bundled themes and Shopress too.
• All the other screenshots can be found in the link below in the Support Content

Screenshots/Screencast with results

Before	After
Activate page in 2025 theme:	Activate page in 2025 theme:
Activate page in 2021 theme:	Activate page in 2021 theme:
Activate page in 2011 theme:	Activate page in 2011 theme:
Activate page in shopress theme:	Activate page in shopress theme:
Activate page in 2020 theme:	Activate page in 2020 theme:

Support Content

• Link to Email Logger Plugin used: ​https://make.wordpress.org/test/files/2026/02/wp-email-logger.zip
• Additional Screenshots: ​https://drive.google.com/drive/folders/19DcvaOg_w91VWt5PMmt0SK5xicAj-vE1?usp=sharing

[johnjamesjacoby]

This looks OK to commit once the merge conflict is resolved.

Thanks for doing this!

I’m thinking this might deserve a developer note, to outline that the old styles are gone and a suggested method to override the new ones. Thoughts?

[joedolson]

@johnjamesjacoby I think a dev note will be in order, yes. Mostly because these styles have been in core with relatively minimal changes for such a long time. I can own that.

[joedolson]

In 61662:

Login and Registration: Update CSS for multisite user actions.

Update the front-end CSS used for multisite user activation and signup. Modify both styles to help prevent conflicts with existing theme styles and provide more consistent margins, paddings, widths, and font sizes.

Props joedolson, sabernhardt, rishabhwp, r1k0, johnjamesjacoby.
Fixes #63861.