Skip to content

Fixed: Admin Style: Plugin links change styles on updates on 7.0#11390

Open
OpuRockey wants to merge 2 commits intoWordPress:trunkfrom
OpuRockey:ticket/64976
Open

Fixed: Admin Style: Plugin links change styles on updates on 7.0#11390
OpuRockey wants to merge 2 commits intoWordPress:trunkfrom
OpuRockey:ticket/64976

Conversation

@OpuRockey
Copy link
Copy Markdown

@OpuRockey OpuRockey commented Mar 30, 2026

Ticket: https://core.trac.wordpress.org/ticket/64976

Summary

Fixes an issue where plugin action links in the admin interface change styles unexpectedly after updates (targeted for WordPress 7.0).

Problem

On the Plugins screen, action links (e.g., Activate, Deactivate, Settings) do not consistently retain their intended admin styles after a plugin update. This results in inconsistent UI appearance and deviates from the expected admin design system.

Solution

This PR ensures that plugin action links consistently use the correct admin styles after updates by aligning them with the updated admin design system and preventing unintended style overrides.

Changes Included

  • Fixed inconsistent styling of plugin action links after updates
  • Ensured alignment with current WordPress admin color and style guidelines

Testing Steps

  • Go to Plugins → Installed Plugins
  • Update any plugin
  • Observe the action links (Activate, Deactivate, etc.)
  • Confirm that styles remain consistent before and after the update

Expected Result

Plugin action links should maintain consistent styling aligned with the WordPress admin UI both before and after plugin updates.

@github-actions
Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props opurockey.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@github-actions
Copy link
Copy Markdown

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Copy link
Copy Markdown

@rbcorrales rbcorrales left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this locally. The base fix works and the underline and color shift on plugin action links go away after adding .updated to the <tr>.

I think the selector approach should follow @joedolson's suggestion though. The rest of common.css already uses div.updated consistently, so changing to div.updated a would match the existing pattern. Admin notices are always rendered as <div> elements (via wp_get_admin_notice()), so scoping to div.updated is safe and more precise than :not(tr).
The main difference is that div.updated a is an allowlist (only match the known good case) while .updated:not(tr) a is a blocklist (exclude the known bad case).

The .updated a:hover and .updated a:focus selectors have the same issue and should get the same treatment. In practice the hover color doesn't change visibly because table-specific hover rules win the cascade, but the selectors still technically match tr.updated and should be fixed for correctness.

I left inline suggestions on all three selectors.

.notice a,
.error a,
.updated a {
.updated:not(tr) a {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.updated:not(tr) a {
div.updated a {


.notice a:hover,
.error a:hover,
.updated a:hover {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
div.updated a:hover {


.notice a:focus,
.error a:focus,
.updated a:focus {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
div.updated a:focus {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants