fix(plugins-window): align dock badge with in-window update count (#258)#263
Merged
Conversation
Core builds the Plugins menu badge from `count( $update_plugins->response )`,
which the dock-builder regex captures verbatim. That raw count can include
orphan rows the in-window "Update available" filter ignores — entries for
deleted plugin files or rows injected by third-party update servers
(`update_plugins_{hostname}` filter, custom `site_transient_update_plugins`
filters) that key on a file `get_plugins()` doesn't return. Reported on a
Bricks + Admin Columns Pro site: badge says 3, filter says 2, hard reload
doesn't help because the orphans persist in the transient.
Override the badge for the `plugins.php` slug on non-multisite with the
intersection of `update_plugins->response` and `get_plugins()` — the same
intersection the REST `/wp/v2/plugins` rows already apply — so the dock
count provably matches what the user sees inside the window. Multisite
keeps Core's intentional "no badge" posture untouched.
Contributor
✅ WordPress Plugin Check Report
📊 ReportAll checks passed! No errors or warnings found. 🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check |
Plugin Check's `plugin_updater_detected` rule treats the literal string `site_transient_update_plugins` as evidence of a self-updater regardless of whether it appears in code or a comment. The previous wording named the filter in a docblock; reword to reference the standard `Update URI` mechanism instead. No behavior change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #258.
The Plugins dock badge could show a higher count than the "Update available" filter inside the Plugins window (reporter saw badge=3, filter=2, persistent across hard reload).
Root cause. The dock badge is regex-extracted from
$menu['plugins.php']title HTML, which Core builds fromcount( $update_plugins->response )— the raw transient count. The in-window filter counts REST/wp/v2/pluginsrows wheredesktop_mode_update_available.available === true, which is set only when the transient entry maps to a plugin fileget_plugins()returns. They drift when the transient holds orphan rows — entries for deleted plugin files, or rows injected by third-party update servers that key on a fileget_plugins()doesn't return. The reporter's site runs Bricks + Admin Columns Pro, both of which use that pattern.Fix. Override the badge for
plugins.phpwith the intersection ofupdate_plugins->responseandget_plugins()— the same intersection the REST endpoint already applies.desktop_mode_plugins_window_count_visible_updates()inrest-fields.phpnext to the related transient logic.desktop_mode_build_dock_items()calls it for theplugins.phpslug after the regex extraction (the regex stays as a fallback for the generic case).themes.phpso it still exercises the generic path.Reproduction (verified live)
Seeded
update_pluginswith 3 rows where only one (crowdsignal-forms/crowdsignal-forms.php) matchedget_plugins(). Without the override the dock badge rendered3while the window filter showedUpdate available 1. With the override the badge correctly rendered1.Test plan
npm run test:php -- --filter='Tests_DesktopMode_BuildDockItems'passes (new + existing).update_plugins(docker exec ... wp eval 'set_site_transient("update_plugins", …);'), hard reload → badge does not over-count.