Forms: add awaiting-mod class to Jetpack menu feedback unread counter badge#50060
Forms: add awaiting-mod class to Jetpack menu feedback unread counter badge#50060enejb wants to merge 4 commits into
Conversation
…tyling Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
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! Boost plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 1 file.
|
…ard WP styling" This reverts commit e07c0b3.
…andard WP styling Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
LiamSarsfield
left a comment
There was a problem hiding this comment.
Nice fix, and awaiting-mod is the right class for the sidebar bubble styling.
One thing worth sorting out before it merges: I think it collides with My Jetpack's red-bubble script. async-notification-bubble.ts queries .awaiting-mod inside #toplevel_page_jetpack .wp-menu-name, then rewrites or removes whatever it matches. Right now that's only its own bubble. Once our badge carries awaiting-mod, it matches ours too. On any admin screen other than My Jetpack, if the red-bubble transient has expired and the site has no MJ alerts, the count comes back 0 and the script calls bubble.remove(). Our unread counter then vanishes even when responses are unread. On a non-zero count it overwrites the class list and text instead, which drops jp-feedback-unread-counter and breaks the live count updates. Could you check with the My Jetpack folks about scoping their selector, or give our badge its own identifier instead of the shared class?
The tests also don't assert the new awaiting-mod output, so you could pull that arg back out and the suite would stay green. A one-line assertStringContainsString( 'awaiting-mod', ... ) on the nonzero menu test would lock it in.
Minor: is main-menu-only deliberate? The submenu badge doesn't get the class, so on the classic admin color schemes it'll still render flat.
| private function get_unread_count_badge_markup( $count, $unread_diff = null ) { | ||
| $attributes = "class='menu-counter jp-feedback-unread-counter count-" . (int) $count . "'"; | ||
| private function get_unread_count_badge_markup( $count, $unread_diff = null, $extra_classes = '' ) { | ||
| $attributes = 'class=\'' . esc_attr( $extra_classes ) . ' menu-counter jp-feedback-unread-counter count-' . (int) $count . ' \''; |
CGastrell
left a comment
There was a problem hiding this comment.
Left a nit, no blocker. LGTM! ![]()
Address review feedback: use sprintf for the badge markup and trim the class list so it no longer emits stray leading/trailing spaces. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fixes JETPACK-1572
Before:
After:
Proposed changes
$extra_classesparameter toContact_Form_Plugin::get_unread_count_badge_markup()so callers can attach additional CSS classes to the feedback unread-count badge.awaiting-modclass when building the combined Jetpack top-level menu badge ($jetpack_unread_tag), so the badge uses the same markup core uses for admin-menu notification bubbles and picks up the active admin color scheme's bubble color.menu-counter jp-feedback-unread-counter).Note: the boost menu-counter change that originally started this branch was reverted; the net change in this PR is only the Forms package update above.
Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
jetpack_feedback_unread_count> 0), or set it manually:wp option update jetpack_feedback_unread_count 3.Note on visual impact: on a connected site under the default and alternate color schemes, the badge already renders a correctly-colored bubble via the existing
jp-feedback-unread-counterclass, so this change is not expected to be visually different in those cases — it aligns the markup with core'sawaiting-modconvention.