[wp-trac] [WordPress Trac] #59969: Conditional loading `build_template_part_block_variations` for performance improvement
WordPress Trac
noreply at wordpress.org
Wed Nov 29 19:54:00 UTC 2023
#59969: Conditional loading `build_template_part_block_variations` for performance
improvement
-------------------------------------------------+-------------------------
Reporter: thekt12 | Owner: thekt12
Type: defect (bug) | Status: assigned
Priority: normal | Milestone: 6.5
Component: General | Version:
Severity: normal | Resolution:
Keywords: has-patch 2nd-opinion needs-unit- | Focuses:
tests | performance
-------------------------------------------------+-------------------------
Changes (by joemcgill):
* keywords: has-patch => has-patch 2nd-opinion needs-unit-tests
* owner: (none) => thekt12
* status: new => assigned
* milestone: Awaiting Review => 6.5
Comment:
Thanks @thekt12! If I'm following all of this correctly (which your
detailed writeup has been super helpful for), it seems to me that we can
basically always assume that variations with the `scope` set to `inserter`
are not needed on the front end, and since
`build_template_part_block_instance_variations()` sets the scope to all of
these variations to `inserter`, then they're basically only needed in the
editor (or in REST API requests that are scope agnostic).
Ensuring variations are available to the `block_type_metadata_settings`
filter makes sense to me, but they still won't be available with the other
PR unless the user has `edit_theme_options` capabilities.
From what I understand, registering the core template block without
variations when the user doesn't have the right capabilities might be a
good workaround, but I'd love to get feedback from someone like @Mamaduka,
who was involved in the original Gutenberg discussion about this, to be
sure.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/59969#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list