-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Edit Site: Extract gutenberg_find_template_post helper, use in edit-site-page #21959
Conversation
…name the latter to gutenberg_template_include_filter
Size Change: +55 B (0%) Total Size: 816 kB
ℹ️ View Unchanged
|
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.
Looks good. I just have one minor question.
Also, as a follow-up, we should also return template part IDs from the new function.
Co-Authored-By: Enrique Piqueras <[email protected]>
Co-Authored-By: Enrique Piqueras <[email protected]>
Yep, planning to work on that 👍 |
I addressed all feedback -- could I get approval so I can merge? 😄 |
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.
LGTM
…emplate_include_filter() (#21980) Previously, the template loader made gratuitous use of filters and globals in order to communicate data from one function to another. Specifically: 1. The `gutenberg_override_query_template` filter was added to `${type}_template`. It served two purposed: 1. It recorded the current template hierarchy in the `_wp_current_template_hierarchy` global. 1. It returned an empty string to indicate that no old-school theme template should be rendered. 2. The `gutenberg_template_include_filter` filter was added to `template_include`. That filter determined the relevant template post from `_wp_current_template_hierarchy`, and used it to render the template via the template canvas. 3. In order to populate the `$settings` variable (which is passed to the client), `edit-site-page.php` iterated over all template getters, calling each one of them, in order to trigger the `${type}_template` filters (and thus, `gutenberg_override_query_template`), to obtain the template hierarchies, and subsequently, the relevant template IDs. During each iteration, care had to be taken to evaluate and then reset the relevant globals. Due to the implicit nature of globals and filters, this is harder to follow and reason about than a call stack of functions with explicit arguments and return values. Hence, this PR makes the following changes: - Introduce a new `get_template_hierachy()` function that determines the template hierarchy for a given template type. This encapsulates adding and removing a filter (which is still required) so it doesn't have to leak a global, as the previous approach did. - Use that function to get the template hierarchy in `edit-site-page.php` (see item 3. above), getting rid of most globals involved in that file. - Now that determining the template hierarchy doesn't need to be a concern of `gutenberg_override_query_template` anymore (see item 1.1 above), re-purpose it to actually render the template canvas, cutting out the now-superfluous `gutenberg_template_include_filter` (item 2.), which is thus removed. This still requires two globals (`_wp_current_template_id` and `_wp_current_template_content`), to communicate the template that needs to be rendered to the canvas. However, their use is much more limited. This PR still does not touch the `_wp_current_template_part_ids` global, in order to ensure that the auto-draft saving behavior isn't changed. I'm planning to work on this in another follow-up. This is a follow-up to #21959, and another preparatory step for https://github.com/WordPress/gutenberg/pull/21877/files#r416075231. Co-authored-by: Enrique Piqueras <[email protected]>
Description
Extract a
gutenberg_find_template_post
helper function fromgutenberg_find_template
, and rename the latter togutenberg_template_include_filter
. Unlike the original function,gutenberg_find_template_post
makes no references to globals, and can thus be used inedit-site-page.php
without resorting to as many globals as before. (I've previously found the code inedit-site-page.php
somewhat hard to read, since it wasn't immediately clear where those globals where coming from.)This is a preparatory step to better encapsulate the logic that determines the relevant template post for a given page, so it can be more easily reused. Specifically, it's meant as a preparation for implementing an endpoint flag that would make the
wp_template
collection endpoint return only relevant templates, as discussed here.(In a follow-up, I might try to get rid of some other
$_wp_current_template_*
globals.)How has this been tested?
Verify that Full Site Editing still works as before. Specifically, verify that the template switcher still holds the same templates as on
master
, and that loading them (both front-end and editor) still works.Types of changes
Small refactor.
Checklist: