Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Regression in 0.17.0: Jetpack SSO override CSS is now outweighed by Jetpack's own CSS due to load-order change (#807)

Closed Beginner friendly
  • Is something wrong?
#1,008 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
css
Domain
authentication, frontend

Research direction

Start with user-edit.css and the wp-login.php two-factor challenge screen, reproducing the issue with Jetpack SSO enabled. Inspect the matching CSS rules and the order in which the styles are loaded; the work is done when the auth code and backup-method controls remain visible as they did in 0.16.0.

Written by the indexing model from the issue text.

Description

Describe the bug
Description

Since 0.17.0, the login form controls (auth code input, backup methods, etc.) are hidden again when Jetpack SSO is active, even though the CSS override that fixes this (originally for Automattic/jetpack#3747) is still present in the codebase, in user-edit.css:

​css .jetpack-sso-form-display #loginform > p, .jetpack-sso-form-display #loginform > div { display: block; } ​

What I checked

Using browser devtools on the wp-login.php two-factor challenge screen:

  • user-edit.css is enqueued and loaded (confirmed in the <head>).
  • The .jetpack-sso-form-display #loginform > p / > div rule does match the hidden element and shows up in the matched rules panel.
  • However, it is struck through / overridden — a competing rule from Jetpack (same specificity) wins the cascade.
Suspected cause

I believe this is a side effect of #807 ("Move class-two-factor-core.php login styles from inline to enqueued stylesheet"), merged between 0.16.0 and 0.17.0.

  • Before #807, this override lived in an inline <style> block printed directly in the 2FA challenge page body, right before login_footer(). That placed it very late in the document source, so it won the cascade tie-break against Jetpack's own SSO CSS regardless of specificity.
  • After #807, the same rule now ships in user-edit.css, enqueued via wp_enqueue_style() and printed in <head> (early in the source). If Jetpack prints its own conflicting rule later in the document (e.g. via a login_head/login_footer-hooked inline style), it now wins the tie, since both rules have equal specificity and CSS cascade order is decided by source order for ties.

So the rule itself was never deleted — the move to an enqueued stylesheet in #807 unintentionally changed its position in the cascade relative to Jetpack's own CSS.

Steps to Reproduce
Steps to reproduce
  1. Activate Jetpack with SSO enabled.
  2. Install Two Factor 0.17.0.
  3. Trigger the two-factor challenge screen on wp-login.php for a user with 2FA enabled.
  4. Inspect the hidden #loginform > p/> div element in devtools — the .jetpack-sso-form-display override rule matches but is crossed out / overridden.
Expected behavior

The two-factor prompt should remain visible, as it did in 0.16.0.

Suggested fix

Increase specificity (or add !important) on this specific override rule so it isn't sensitive to enqueue/source order, or confirm the enqueue priority so user-edit.css is guaranteed to print after any Jetpack-injected style on this page.

Environment
  • Two Factor version: 0.17.0 (regression from 0.16.0)
  • WordPress version: 7.1.2
  • Jetpack version: 16.2
  • Browser: Google Chrome
Image
Screenshots, screen recording, code snippet

No response

Environment information

No response

Please confirm that you have searched existing issues in this repository.

Yes

Please confirm that you have tested with all plugins deactivated except Two-Factor.

Yes

Dominant language
PHP
Stars
825
Forks
190
Avg merge
1d 17h
Merged PRs (30d)
32

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WordPress/two-factor

All issues in WordPress/two-factor

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.