Widget Visibility: restore controls for legacy widgets in block widget editor#50015
Draft
agent-sandbox-automattic[bot] wants to merge 2 commits into
Draft
Widget Visibility: restore controls for legacy widgets in block widget editor#50015agent-sandbox-automattic[bot] wants to merge 2 commits into
agent-sandbox-automattic[bot] wants to merge 2 commits into
Conversation
…t editor
In the Gutenberg block-based widget editor (Appearance > Widgets since
WordPress 5.8), the Visibility button for legacy PHP widgets was rendered
by PHP via `in_widget_form`, but clicking it did nothing.
Two bugs caused this:
1. `widget-conditions.js` used `closest('div.widget')` to find the widget
container, but in the Gutenberg legacy-widget block the container is
`.wp-block-legacy-widget__edit-form`, not `div.widget`. The jQuery
call returned an empty set, so every subsequent DOM operation on
`$widget` silently did nothing (the conditions panel never toggled).
2. `widget_admin_setup()` (which enqueues the CSS/JS and localises the
`widget_conditions_data` global) was wired to the `sidebar_admin_setup`
action. In the Gutenberg block widget editor that action may not fire,
meaning the assets were never enqueued. For the Gutenberg path we now
register on `enqueue_block_editor_assets` instead, which reliably fires
on the widgets.php block-editor page. The `widgets` style handle (only
registered in the classic editor) is also skipped as a CSS dependency
when the block editor is active to prevent a silent enqueue failure.
Co-authored-by: nerrad <darren.ethier@automattic.com>
Contributor
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
github-actions
Bot
added
[Feature] Widget Visibility
[Plugin] Jetpack
Contributor
|
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! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
github-actions
Bot
added
the
[Status] Needs Author Reply
Code Coverage SummaryCoverage changed in 1 file.
|
Wrap the .closest().find().click() chain across lines to satisfy prettier/prettier, which was failing ESLint (and in turn the linter exclude-list check, which tried to add the file to the eslint excludelist).
Contributor
|
My initial read is that this is a no-op. The functionality appears to be working for me on trunk. Replied back to the issue to the OP asking for more details in order to reproduce the failure. |
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
2 participants
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.
Fixes JETPACK-1757
Fixes #49860
Proposed changes
In the Gutenberg block-based widget editor (Appearance > Widgets, available since WordPress 5.8), the "Visibility" button for legacy PHP widgets was rendered by PHP via
in_widget_formbut clicking it had no effect — the conditions panel never appeared.Two bugs were present:
JS DOM mismatch —
widget-conditions.jsusedclosest('div.widget')to locate the widget container when the "Visibility" button was clicked. In the Gutenberg legacy-widget block the container element is.wp-block-legacy-widget__edit-form, notdiv.widget. Theclosest()call returned an empty jQuery set, so every subsequent operation on$widgetsilently did nothing. Fixed by extending the selector to'div.widget, .wp-block-legacy-widget__edit-form'in the two affected event handlers.Assets not enqueued in Gutenberg —
widget_admin_setup()(which enqueueswidget-conditions.js,widget-conditions.css, and thewidget_conditions_dataglobal required by the block-editor visibility script) was registered on thesidebar_admin_setupaction. In the Gutenberg block widget editor that action may not fire, so assets could silently be absent. For the Gutenberg path (!wp_use_widgets_block_editor()is false) we now registerwidget_admin_setuponenqueue_block_editor_assetsinstead, which reliably fires when the block editor page loads. The'widgets'style handle (only registered in the classic editor) is also conditionally omitted as a CSS dependency to prevent a silent style-enqueue failure.Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
add_filter('use_widgets_block_editor', '__return_false').Linear: JETPACK-1757
Co-authored-by: nerrad darren.ethier@automattic.com