Forms: fix phantom unread counter badge when no submissions are unread#47281
Forms: fix phantom unread counter badge when no submissions are unread#47281
Conversation
When Forms has 0 unread submissions, unread_count() was absorbing the My Jetpack red bubble notification count and re-emitting it as a Forms-styled badge (jp-feedback-unread-counter). This made it look like there were unread form submissions when there were none. Skip writing both the main menu and submenu badges when $unread is 0, letting My Jetpack's own badge remain as-is.
kraftbj
added
Bug
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug where the Jetpack admin sidebar displayed a phantom red "1" badge next to the Jetpack menu when there were zero unread form submissions but My Jetpack had alerts. The root cause was that Forms' badge rendering logic would absorb and re-emit My Jetpack's notification count using Forms' CSS class, making it appear as if there was an unread form submission.
Changes:
- Added conditional checks to skip badge rendering when Forms has zero unread submissions
- Preserved existing combined badge behavior when Forms does have unread items
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| projects/packages/forms/src/contact-form/class-contact-form-plugin.php | Added if ( $unread > 0 ) guards around main menu and submenu badge rendering logic to prevent phantom badges |
| projects/packages/forms/changelog/forms-phantom-unread-badge | Added changelog entry documenting the patch-level bug fix |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Code Coverage SummaryCoverage changed in 1 file.
|
Fixes FORMS-592
Proposed changes:
The Jetpack admin sidebar shows a phantom red badge next to the Jetpack menu even when there are zero unread form submissions. The badge has class
jp-feedback-unread-counter count-1 awaiting-mod—it looks like an unread Forms submission, but it isn't one.The root cause is Forms'
unread_count()method absorbing other badges from the Jetpack top-level menu and re-emitting them as Forms-styled badges. Here's the chain:maybe_show_red_bubble()runs atadmin_init:1001and appends<span class="awaiting-mod">N</span>to the Jetpack menu for things like backup failures, missing connections, expiring plans, etc.unread_count()runs later atcurrent_screen, finds the Jetpack menu item, and callsparse_menu_item()which extracts theawaiting-modbadge value.$jetpack_badge_count(starting at the Forms unread count of 0), then Forms writes a newjp-feedback-unread-counter count-1badge back to the menu—replacing My Jetpack's badge entirely.I confirmed this on a live site: the REST endpoint
my-jetpack/v1/red-bubble-notificationsreturned abackup_failurealert, the server-rendered HTML showeddata-unread-diff='1'(meaning Forms unread = 0 but 1 "other" count was absorbed), and the Forms submenu correctly showedcount-0. The top-level Jetpack badge was purely the absorbed My Jetpack alert, presented misleadingly as a Forms counter.The intermittent nature reported in the ticket makes sense—the My Jetpack red bubble uses a transient cache. When the cache is empty, no server-side badge gets added (an async JS fetch runs instead), so the phantom badge disappears. On next page load, if the cache has been repopulated, it reappears.
The fix: skip writing the Forms badge when
$unreadis 0. My Jetpack's own badge stays untouched. When Forms does have unread items, behavior is unchanged—the combined badge withdata-unread-diffstill works.Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
No.
Testing instructions:
Red_Bubble_Notifications::get_red_bubble_alerts()to return a non-silent alert).count-1badge withjp-feedback-unread-counterclass. The Forms submenu showscount-0.awaiting-modbadge (not wrapped injp-feedback-unread-counter), or no badge if there are no alerts. The Forms submenu shows no badge.Changelog