-
Notifications
You must be signed in to change notification settings - Fork 219
Fix broken post/page editor screens in WordPress versions earlier than 6.2 #9090
Conversation
The release ZIP for this PR is accessible via:
Script Dependencies ReportThere is no changed script dependency between this branch and trunk. This comment was automatically generated by the TypeScript Errors Report
🎉 🎉 This PR does not introduce new TS errors. |
Size Change: +29 B (0%) Total Size: 1.11 MB
ℹ️ View Unchanged
|
Note As a followup, the previous subscribe callback in the same file should also implement something similar as a local cache. The same |
…plateId from the Site Editor for 6.1.1 compatibility
I was able to fix the Site Editor and initial testing looks good. Like @nerrad said though we should still implement this if possible in a follow-up PR unless we find this is necessary during review/testing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on WP 6.1.1 without Gutenberg, and with Woo 7.6, post/page and site editors load and work flawlessly on my end. I can't see any infinite loop as well.
…n 6.2 (#9090) * Fix infinite loop (range error) on subscribe callback. * Replace getEditedPostContext with getEditedPostId to retrieve the templateId from the Site Editor for 6.1.1 compatibility --------- Co-authored-by: tjcafferkey <[email protected]>
FYI: I added a WC core/feature plugin testing section with testing steps specially targeting the feature plugin and WC core. The Single Product block for now is only available in experimental builds. |
hum, i had a similar issue with Woo / Woo Blocks yesterday but with also multisite. |
Thanks, @Marc-pi! We just released 10.0.2 a few minutes ago that should fix this issue. You can grab it from WordPress.org and, assuming the issue is the same, it will be fixed. 🙌 |
* Empty commit for release pull request * Add 10.0.2 changelog * Update versions to 10.0.2 * Fix broken post/page editor screens in WordPress versions earlier than 6.2 (#9090) * Fix infinite loop (range error) on subscribe callback. * Replace getEditedPostContext with getEditedPostId to retrieve the templateId from the Site Editor for 6.1.1 compatibility --------- Co-authored-by: tjcafferkey <[email protected]> * Add 10.0.2 testing steps --------- Co-authored-by: github-actions <[email protected]> Co-authored-by: Darren Ethier <[email protected]> Co-authored-by: tjcafferkey <[email protected]>
thanks for the fix |
🤖 Generated by Copilot at 656de50
Improve block registration performance and reliability in
registerBlockSingleProductTemplate
. Use a local cache to prevent duplicate calls toregisterBlockType
andregisterBlockVariation
for single product blocks. This also prevents an infinite loop.This fixes an issue that surfaced where the WordPress core post (or page) editor was broken with WooCommerce Blocks active.
Explanation of Changes
WordPress 6.2 introduces an update to the
subscribe
function returned by registeredwp.data
stores that enables passing along as an (optional) second argument the specific store that the subscribe callback should be registered to. On previous versions of WordPress, this second argument is ignored (there is no handling) which means the subscribe callback will be registered and invoked on every store change.Where this is problematic is when the
core/blocks
store is updated which typically happens when registering a block or a variation. So the existing checks in this callback were insufficient for preventing an infinite loop from happening.Edit by @tjcafferkey: In addition to the above, it looks like the store method
getEditedPostContext
is also not present in 6.1.1 (presumably also introduced in 6.2) resulting in a crashing Site Editor. This was replaced withgetEditedPostId
similar to how the Classic Template block retrieves the template Id.Accessibility
prefers-reduced-motion
Other Checks
Testing
Automated Tests
User Facing Testing
Note to reviewer: Please assist with these testing notes to verify that the single product block (and inner blocks) are registered correctly and work as expected. Expand user testing notes below as necessary.
Experimental testing:
WC core/feature plugin testing:
WooCommerce Visibility
Performance Impact
Changelog