Template Loader: Drop $_wp_current_template_id
#22196
Conversation
|
Size Change: 0 B Total Size: 1.13 MB ℹ️ View Unchanged
|
ockham
force-pushed
the
update/template-hierarchy-no-current-template-id-global
branch
from
9875c5e
to
e1f8148
Compare
lib/template-loader.php
Outdated
|
|
||
| if ( ! $post || ! post_type_exists( 'wp_template' ) || ! post_type_exists( 'wp_template_part' ) ) { | ||
| return $settings; | ||
| } | ||
|
|
||
| // Create template part auto-drafts for the edited post. | ||
| $post = isset( $_wp_current_template_id ) | ||
| ? get_post( $_wp_current_template_id ) // It's a template. | ||
| $post = isset( $settings['templateId'] ) |
There was a problem hiding this comment.
I think this is only set in edit-site. This would break the post editor with template parts then.
There was a problem hiding this comment.
Revisiting this, I'm not sure we actually need the ternary checking for $_wp_current_template_id at all.
That global is (only) set by gutenberg_override_query_template(), which (via gutenberg_find_template_post_and_parts()) also calls create_auto_draft_for_template_part_block(). So the template case should be covered, leaving only the post editor case.
There was a problem hiding this comment.
But that sounds wrong, since this is clearly targeted to the editor case, and gutenberg_override_query_template() is only called for front-end template resolution. That might be an oversight on my part going back to #21959 😕
There was a problem hiding this comment.
However, gutenberg_find_template_post_and_parts is called for all template types in lib/edit-site-page.php, so template part auto-drafts are indeed auto-generated for the site editor.
There was a problem hiding this comment.
How would this make sense in the post editor anyways? i.e. how would there be a template set for an individual post? And if there is a template set, why do we care about the template parts associated with the template (at this point in time)? Wouldn't we only care about template parts inside the post_content of the post?
There was a problem hiding this comment.
Wouldn't we only care about template parts inside the post_content of the post?
Exactly, yeah 🤔
There was a problem hiding this comment.
Pushed d6dc5a3 to reflect these musings in code.
There was a problem hiding this comment.
I think this is leftover from when you could switch to a template view in the post editor.
ockham
force-pushed
the
update/template-hierarchy-no-current-template-id-global
branch
from
8958614
to
c8e32f5
Compare
ockham
changed the title
$_wp_current_template_id
ockham
deleted the
update/template-hierarchy-no-current-template-id-global
branch
Description
Final piece of a refactor that started with #21959, #21980, and #22143.
This PR changes the
gutenberg_template_loader_filter_block_editor_settingsfilter to detect if we're dealing with the Site Editor from the$settingsarray, allowing us to drop the$_wp_current_template_idglobal.How has this been tested?
Verify that Full Site Editing still works as before.
Checklist: