Template Part: Add fallback to the current theme when not provided #55965
Conversation
This file contains 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
gziolo
added
[Type] Enhancement
|
Size Change: +111 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
felixarntz
approved these changes
Nov 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What?
Follow-up to #55217 and WordPress/wordpress-develop#5455.
Similar to #53423, #55858.
I'm looking at adding the fallback for the current theme in places where template parts are loaded from the server without preprocessing through
_inject_theme_attribute_in_template_part_blockto work correctly in all cases in the editor. It's an alternative to https://core.trac.wordpress.org/ticket/59583 where we were trying to inject the default theme attribute into the template part blocks serialized in HTML stored for templates and patterns.Why?
I'm seeking ways to the whole logic to the client to bring back the performance improvements we measured for the homepage in the Twenty Twenty-Four theme during the WordPress 6.4 release cycle. It was an accidental discovery caused by the regression introduced in https://core.trac.wordpress.org/changeset/56805 where
_inject_theme_attribute_in_template_part_blockwas conditionally removed from processing in block patterns.If the approach seems reasonable and also solid enough, we might give it another try to remove (this time purposefully) the same processing on the server slightly improving the performance in certain scenarios. /cc @felixarntz
How?
The default theme gets always provided as a fallback with the core data store by calling:
getCurrentTheme()?.stylesheet. This way, that information doesn't need to come from the server with the REST API response containing HTML for templates and patterns.Testing Instructions
To test the changes I applied the following patch to WordPress Core when using https://github.com/WordPress/wordpress-develop:
It might also be as simple as removing the body of
_inject_theme_attribute_in_template_part_blockto ensure it doesn't apply the modifications to template parts serialized in HTML.With that in place: