Lazily load Duotone settings only when needed. #4831
Conversation
There was a problem hiding this comment.
@spacedmonkey Nice work, lazy-loading the duotone configuration only when needed makes a lot of sense to me. Code looks solid to me and quite straightforward, simply replacing the variable access with calling the private method to lazy-load 👍
Can you share before & after profiling results to see how that changes overall load time?
spacedmonkey
requested review from
westonruter,
youknowriad,
joemcgill,
audrasjb,
felixarntz,
tellthemachines and
swissspidy
Co-authored-by: Mukesh Panchal <[email protected]>
There was a problem hiding this comment.
Thanks for the PR @spacedmonkey!
I tested this on 6.3-beta4 (patched with this PR) on Twenty-Twenty Three (classic themes continue to not load duotone), with Gutenberg active and inactive, using the following blocks:
Supports duotone
- Site Logo
- Post Featured Image
- Image
- Gallery
- Cover
Doesn't support duotone
- Media & Text
- Video
- Video with poster image
I also added global duotone filters for the first group above. These were correctly used when duotone filters weren't applied in the post editor, and were correctly ignored when duotone filters were applied in the post editor.
Note: When the Gutenberg plugin is active, duotone filters seem to get stronger. This seems to happen with 6.3-beta4 though, so I don't think this PR has anything to do with it. Not sure what's going on there (I'm on mobile so not checking release notes and code at the moment).
I've also included some docblock feedback in this review.
There was a problem hiding this comment.
@spacedmonkey Other than the one feedback from https://github.com/WordPress/wordpress-develop/pull/4831/files#r1261443459, this looks good to me code-wise.
While this looks like quite some refactoring, most line changes are just indented code, so I think that's fine. The ideas of changing the get_selector() method signature and usage to expect a WP_Block_Type instance and to use block_has_support() where applicable make sense to me and are fairly straightforward enhancements.
However, there seems to be a bug caused by this based on #4831 (review)? From that perspective, I am slightly worried about the refactoring in this PR. While I'm onboard with the PR in its current state, we may want to be more cautious and go with the much simpler change based on the changes from yesterday, before you refactored further.
I've tested it and it is fixed by f10a53f. |
There was a problem hiding this comment.
This is testing well for me.
With the addition of this suggestion https://github.com/WordPress/wordpress-develop/pull/4831/files#r1261443459, it gets a 👍 from me.
There was a problem hiding this comment.
This looks good to me. 👍
Thanks for working on this @spacedmonkey :)
There was a problem hiding this comment.
Thanks for the PR @spacedmonkey! This is testing well for me, both on its own and together with #4839. I can confirm duotone filters are working as expected both in the editor and on the front end, with block themes and (after applying #4839) with classic themes too.
|
Can we rebase this now that 4839 has been merged? |
There was a problem hiding this comment.
Thanks for the updates @spacedmonkey! As @swissspidy mentioned, a rebase would be good! 🙂
Co-authored-by: Pascal Birchler <[email protected]>
|
Committed https://core.trac.wordpress.org/changeset/56226 🎉 |
This PR does a number of things.
tblock_has_supportutil.render_duotone_support, by reuse type already passed in filter.When testing this, it is important to test with pages / posts with and without blocks that support duo tone.
Trac ticket: https://core.trac.wordpress.org/ticket/58673
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.