Introduce `wp_template` post type and use it for full-site templates #17513

felixarntz · 2019-09-22T17:20:30Z

This PR is the initial piece for addressing #17512. It registers a wp_template post type, as a foundation for storing template-wide block data.

Types of changes

Register wp_template post type.

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.

youknowriad

😍Thanks for your work on this PR Felix. I tried running some quick tests on it, it's a great start.

To ease the reviews and to keep the discussions focused, I'd like to propose that we split this PR into three separate PRs.

One for the CPT addition (it would be a blocker for the two others)
One for the template hierarchy matching and rendering behavior
One for the temporary UI to edit templates. I think this UI might not be the end UI we end up with as we might prefer something more tied to the post/page editing instead but I think it's a great way to start building these templates as we move forward with the parallel work in terms of editor refactoring, FSE blocks...

What do you think?

epiqueras · 2019-09-23T20:36:06Z

lib/template-loader.php

+	if ( ! is_array( $_wp_current_template_hierarchy ) ) {
+		$_wp_current_template_hierarchy = $templates;
+	} else {
+		$_wp_current_template_hierarchy = array_merge( $_wp_current_template_hierarchy, $templates );


Why do we merge here? Merging two ordered lists like this doesn't seem like it would result in the right ordering.

How so? As these are regular indexed arrays, the $templates one would always be appended to the $_wp_current_template_hierarchy one.

Exactly, I'm not even sure if this runs more than once, but the code looks like it expects it too and if on every run $templates contains a priority ordered list, what guarantees that the head of the next list is the tail of the previous list?

epiqueras · 2019-09-23T20:46:20Z

lib/template-loader.php

+ * @param string $template_file Original template file. Will be overridden.
+ * @return string Path to the canvas file to include.
+ */
+function gutenberg_find_template( $template_file ) {


Shouldn't we still load a template file when all available wp_templates have less preference in the hierarchy?

That was one of the goals of #4659.

I'm certainly open to it, but let's discuss first. It leads to the question whether we would want to enable the usage of wp_template blocks in an "all-or-nothing" mode (e.g. only if something like add_theme_support( 'block-templates' ) is given) or whether we want to go for a hybrid. The latter at first glance certainly sounds nicer, but it might open a can of worms, as I think supporting both "old" PHP file templates and block templates would make theme development overly complex. Thoughts on this @youknowriad?

I see the latter approach as a way for theme authors to opt-in iteratively into block-templates. For example a first step could be to adopt it for "static page templates" only...

Even in terms of shipping strategy, I feel like we can decide to only allow block templates in static ones first and then open to the whole hierarchy as a second step. It's good to start thinking about these discussions but I'm not too concerned at the moment, this will come in time as we move forward, I feel we have room to adapt our approach as we move forward with the implementation.

I think the hybrid approach is important, because it allows users to still leverage wp_templates in old themes that will never be updated.

felixarntz · 2019-09-26T11:34:11Z

@youknowriad

To ease the reviews and to keep the discussions focused, I'd like to propose that we split this PR into three separate PRs.

One for the CPT addition (it would be a blocker for the two others)

One for the template hierarchy matching and rendering behavior

One for the temporary UI to edit templates. I think this UI might not be the end UI we end up with as we might prefer something more tied to the post/page editing instead but I think it's a great way to start building these templates as we move forward with the parallel work in terms of editor refactoring, FSE blocks...

Makes sense, I'll make these updates tomorrow. I suggest the following "PR hierarchy":

The CPT registration PR (add/wp-template-post-type) against master
The UI PR (add/wp-template-post-type-ui) against add/wp-template-post-type
The hierarchy matching (add/wp-template-hierarchy-matching) against add/wp-template-post-type

That would be because the last two each depend on the first.

felixarntz · 2019-09-27T08:26:37Z

@youknowriad I've simplified this PR to only register the post type itself (without any UI), and opened #17625 and #17626 against this branch with the UI and template loader changes respectively.

youknowriad

This is looking good to me 👍

epiqueras · 2019-09-27T16:43:27Z

lib/experiments-page.php

@@ -124,6 +135,7 @@ function gutenberg_experiments_editor_settings( $settings ) {
 		'__experimentalEnableLegacyWidgetBlock' => $experiments_exist ? array_key_exists( 'gutenberg-widget-experiments', get_option( 'gutenberg-experiments' ) ) : false,
 		'__experimentalEnableMenuBlock'         => $experiments_exist ? array_key_exists( 'gutenberg-menu-block', get_option( 'gutenberg-experiments' ) ) : false,
 		'__experimentalBlockDirectory'          => $experiments_exist ? array_key_exists( 'gutenberg-block-directory', get_option( 'gutenberg-experiments' ) ) : false,
+		'__experimentalEnableFullSiteEditing'   => $experiments_exist ? array_key_exists( 'gutenberg-full-site-editing', get_option( 'gutenberg-experiments' ) ) : false,


There's a few more places where we have to update things because of this change.

See: 2aa1d04

epiqueras · 2019-09-27T16:44:56Z

lib/templates.php

+	$args = array(
+		'labels'          => $labels,
+		'description'     => __( 'Templates to include in your theme.', 'gutenberg' ),
+		'public'          => false,


This is already the default.

epiqueras · 2019-09-27T16:45:19Z

lib/templates.php

+		'labels'          => $labels,
+		'description'     => __( 'Templates to include in your theme.', 'gutenberg' ),
+		'public'          => false,
+		'has_archive'     => false,


This is already the default.

felixarntz added 5 commits September 22, 2019 18:18

Introduce wp_template post type.

a4285d1

Improve (temporary) admin UI for wp_template post type by exposing slug.

62e9d0e

Implement template loader overrides to rely on 'wp_template' posts.

230a234

Render viewport meta tag.

915f34b

Prevent deletion of fallback 'wp_template' post 'index'.

3a61491

felixarntz added Framework Issues related to broader framework topics, especially as it relates to javascript Customization Issues related to Phase 2: Customization efforts labels Sep 22, 2019

felixarntz requested review from westonruter, mtias and aduth September 22, 2019 17:20

felixarntz requested a review from TimothyBJacobs as a code owner September 22, 2019 17:20

youknowriad requested review from epiqueras and youknowriad September 23, 2019 11:19

youknowriad reviewed Sep 23, 2019

View reviewed changes

epiqueras reviewed Sep 23, 2019

View reviewed changes

felixarntz added 2 commits September 27, 2019 10:05

Scope PR to just basic wp_template post type registration.

d835348

Merge branch 'master' into add/block-templates

a7cc91f

This was referenced Sep 27, 2019

Add logic for basic (temporary) wp_template editing UI #17625

Merged

Implement core template loader overrides to rely on wp_template posts #17626

Merged

youknowriad approved these changes Sep 27, 2019

View reviewed changes

felixarntz merged commit 13e1519 into master Sep 27, 2019

epiqueras reviewed Sep 27, 2019

View reviewed changes

youknowriad added this to the Gutenberg 6.6 milestone Sep 30, 2019

youknowriad added the Full Site Editing label Oct 9, 2019

felixarntz mentioned this pull request Oct 12, 2019

Block Patterns: Add ability for predefined block layouts to be added to a document #17335

Closed

6 tasks

aristath deleted the add/block-templates branch November 10, 2020 14:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce `wp_template` post type and use it for full-site templates #17513

Introduce `wp_template` post type and use it for full-site templates #17513

felixarntz commented Sep 22, 2019 •

edited

Loading

youknowriad left a comment

epiqueras Sep 23, 2019

felixarntz Sep 26, 2019

epiqueras Sep 26, 2019

epiqueras Sep 23, 2019

felixarntz Sep 26, 2019

youknowriad Sep 26, 2019

epiqueras Sep 26, 2019

felixarntz commented Sep 26, 2019

felixarntz commented Sep 27, 2019

youknowriad left a comment

epiqueras Sep 27, 2019

epiqueras Sep 27, 2019

epiqueras Sep 27, 2019

Introduce wp_template post type and use it for full-site templates #17513

Introduce wp_template post type and use it for full-site templates #17513

Conversation

felixarntz commented Sep 22, 2019 • edited Loading

Types of changes

Checklist:

youknowriad left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felixarntz commented Sep 26, 2019

felixarntz commented Sep 27, 2019

youknowriad left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Introduce `wp_template` post type and use it for full-site templates #17513

Introduce `wp_template` post type and use it for full-site templates #17513

felixarntz commented Sep 22, 2019 •

edited

Loading