Full Site Editing: Add Support for Templates Default and Custom Titles and Descriptions by Copons · Pull Request #26394 · WordPress/gutenberg

Copons · 2020-10-22T16:36:39Z

Description

Update the templates handling to allow for custom titles and descriptions.

Created a theme-provided (the name is bad, I'm open to suggestions!) custom status for wp_template CPT to indicate those templates that have been imported from files and not touched by the user. Previously we were using auto-draft, which wasn't super appropriate, and created a few complications (e.g. autodrafts can't have titles, aren't supposed to show up anywhere, etc.).
Added support for excerpts to the wp_template CPT. Right now titles and excerpts are only editable when editing the template in its own post editor.
Added a theme post meta, containing the source theme for theme-provided templates.
Updated the Templates wp-admin list to display more details (title, slug, excerpt, status, source), so that now it's at least slightly useful. It also now lists theme-provided and (at least temporarily) auto-draft templates.
Created a list of default template types definitions in PHP, containing titles and descriptions of all the "generic" (not containing variables in their slugs) templates.
The list is filterable with the new template_types_definitions filter, which is already used to temporarily remove the embed definition, since it's currently not supported.
The list is available in JS via Redux: it's in settings.defaultTemplateTypesDefinitions of core/edit-site.
Templates imported from files will automatically obtain the title and excerpt from the default definitions, if possible.
New templates created from the Site Editor sidebar will also automatically use the default definitions, and will be saved as draft. They will become published once saved the first time.
The default definitions are used across the Site Editor as a fallback for templates without title or excerpt.

Follow up

Update the template definitions copy!
Add a way to edit the title (and maybe excerpt too) of a template from the Site Editor (e.g. in the Document Settings dropdown).
Extend the wp-admin Templates list's quick edit with the excerpt (and maybe the slug too?).
Update the template saving logic to allow for going back and forth between draft and publish.

How has this been tested?

Note: this will create new templates which are only accessible with the changes included in this PR. Changing branch would make the new templates inaccessible; they shouldn't be used by the site, but are still there, and may cause unexpected conflicts with pre-existing auto-draft templates.

Open the Site Editor. Behind the scenes, all theme's and plugins' templates will be converted into new wp_template items of status theme-provided; this means that there will be duplicates.
Open the wp-admin Templates list (/edit.php?post_type=wp_template).
Make sure it shows the following columns: title, slug, description, status.
Notice it shows also auto-draft templates. Feel free to wipe this list clean by moving all templates to trash. New theme-provided templates will be generated again once opening the Site Editor.
Open the Site Editor (if you wiped the templates, now it will generate new ones, hopefully without duplicates).
Open the sidebar, and navigate into the Templates menu.
Make sure the items use the title and description as provided by the definitions list introduced in this PR.
Create a new template with the New Template dropdown (click on + in the Templates menu).
Make sure the items in the New Template dropdown use the definitions list.
Make sure the new template's name is the one provided by the definitions list (it should match the one from the New Template dropdown).
Check in the sidebar that the new template shows up (it might be easier to just look in the All Templates menu), it has the correct title and description, and is marked as "[Draft]".
Click on "Update Design" (it might be disabled: do some changes to enable it).
The template has now been published, so make sure it lost the "[Draft]" label.
Open the wp-admin Templates list, and make sure the new template shows up with the right title, description, and status.

Screenshots

The new Templates wp-admin list:

The Site Editor sidebar using the new default definitions, and including a draft template:

The Site Editor documents settings using the new default definitions:

Types of changes

Breaking change (fix or feature that would cause existing functionality to not work as expected)

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.
I've updated all React Native files affected by any refactorings/renamings in this PR.

Copons · 2020-10-22T16:44:59Z

lib/load.php


 // Include FSE related files only if the experiment is enabled.
 if ( gutenberg_is_experiment_enabled( 'gutenberg-full-site-editing' ) ) {
+	require dirname( __FILE__ ) . '/full-site-editing/templates-definitions.php';


We are starting to have a lot of FSE-related library files, so I think it's the case to group them in a separate folder.
I haven't moved the others to avoid bloating this PR.

github-actions · 2020-10-22T16:45:18Z

Size Change: +958 B (0%)

Total Size: 1.21 MB

Filename	Size	Change
`build/block-directory/index.js`	8.72 kB	-2 B (0%)
`build/block-editor/index.js`	130 kB	+6 B (0%)
`build/block-library/editor.css`	8.94 kB	-1 B
`build/block-library/index.js`	146 kB	+609 B (0%)
`build/block-library/style-rtl.css`	7.82 kB	+54 B (0%)
`build/block-library/style.css`	7.82 kB	+56 B (0%)
`build/blocks/index.js`	48.1 kB	+1 B
`build/components/index.js`	172 kB	+365 B (0%)
`build/components/style-rtl.css`	15.2 kB	-120 B (0%)
`build/components/style.css`	15.2 kB	-120 B (0%)
`build/core-data/index.js`	12.3 kB	+3 B (0%)
`build/data/index.js`	8.77 kB	+2 B (0%)
`build/edit-site/index.js`	22 kB	-1 B
`build/edit-site/style-rtl.css`	3.85 kB	+51 B (1%)
`build/edit-site/style.css`	3.85 kB	+51 B (1%)
`build/edit-widgets/index.js`	26.4 kB	+2 B (0%)
`build/redux-routine/index.js`	2.85 kB	+2 B (0%)

ℹ️ View Unchanged

Filename	Size	Change
`build/a11y/index.js`	1.14 kB	0 B
`build/annotations/index.js`	3.78 kB	0 B
`build/api-fetch/index.js`	3.45 kB	0 B
`build/autop/index.js`	2.84 kB	0 B
`build/blob/index.js`	665 B	0 B
`build/block-directory/style-rtl.css`	943 B	0 B
`build/block-directory/style.css`	942 B	0 B
`build/block-editor/style-rtl.css`	11.1 kB	0 B
`build/block-editor/style.css`	11.1 kB	0 B
`build/block-library/editor-rtl.css`	8.94 kB	0 B
`build/block-library/theme-rtl.css`	837 B	0 B
`build/block-library/theme.css`	838 B	0 B
`build/block-serialization-default-parser/index.js`	1.88 kB	0 B
`build/block-serialization-spec-parser/index.js`	3.1 kB	0 B
`build/compose/index.js`	9.81 kB	0 B
`build/data-controls/index.js`	772 B	0 B
`build/date/index.js`	31.8 kB	0 B
`build/deprecated/index.js`	768 B	0 B
`build/dom-ready/index.js`	571 B	0 B
`build/dom/index.js`	4.46 kB	0 B
`build/edit-navigation/index.js`	11.2 kB	0 B
`build/edit-navigation/style-rtl.css`	881 B	0 B
`build/edit-navigation/style.css`	885 B	0 B
`build/edit-post/index.js`	306 kB	0 B
`build/edit-post/style-rtl.css`	6.37 kB	0 B
`build/edit-post/style.css`	6.36 kB	0 B
`build/edit-widgets/style-rtl.css`	3.09 kB	0 B
`build/edit-widgets/style.css`	3.09 kB	0 B
`build/editor/editor-styles-rtl.css`	480 B	0 B
`build/editor/editor-styles.css`	482 B	0 B
`build/editor/index.js`	43.1 kB	0 B
`build/editor/style-rtl.css`	3.85 kB	0 B
`build/editor/style.css`	3.85 kB	0 B
`build/element/index.js`	4.65 kB	0 B
`build/escape-html/index.js`	735 B	0 B
`build/format-library/index.js`	7.7 kB	0 B
`build/format-library/style-rtl.css`	547 B	0 B
`build/format-library/style.css`	548 B	0 B
`build/hooks/index.js`	2.13 kB	0 B
`build/html-entities/index.js`	623 B	0 B
`build/i18n/index.js`	3.57 kB	0 B
`build/is-shallow-equal/index.js`	712 B	0 B
`build/keyboard-shortcuts/index.js`	2.52 kB	0 B
`build/keycodes/index.js`	1.94 kB	0 B
`build/list-reusable-blocks/index.js`	3.11 kB	0 B
`build/list-reusable-blocks/style-rtl.css`	476 B	0 B
`build/list-reusable-blocks/style.css`	476 B	0 B
`build/media-utils/index.js`	5.34 kB	0 B
`build/notices/index.js`	1.79 kB	0 B
`build/nux/index.js`	3.42 kB	0 B
`build/nux/style-rtl.css`	671 B	0 B
`build/nux/style.css`	668 B	0 B
`build/plugins/index.js`	2.56 kB	0 B
`build/primitives/index.js`	1.43 kB	0 B
`build/priority-queue/index.js`	791 B	0 B
`build/reusable-blocks/index.js`	3.06 kB	0 B
`build/rich-text/index.js`	13.2 kB	0 B
`build/server-side-render/index.js`	2.77 kB	0 B
`build/shortcode/index.js`	1.69 kB	0 B
`build/token-list/index.js`	1.27 kB	0 B
`build/url/index.js`	4.06 kB	0 B
`build/viewport/index.js`	1.84 kB	0 B
`build/warning/index.js`	1.14 kB	0 B
`build/wordcount/index.js`	1.22 kB	0 B

_{compressed-size-action}

lib/full-site-editing/templates-definitions.php

Copons · 2020-10-27T13:23:05Z

When I've replaced getTemplateInfo with the useTemplateInfo hook, I've also removed the former's tests.
This is because I'm not exactly sure how to test a hook, which also relies on useSelect to work. 🤔
I'd be happy to restore the tests if anyone could give me a pointer on where to ~~copy~~ look for other hooks tests.

EDIT: sorted out thanks to @david-szabo97! ✨

Copons · 2020-10-28T12:10:32Z

Similarly to wp_template_part, I've added a new theme post meta to wp_template.

When a template file provided by a theme is converted into a wp_template, it stores the theme's slug (stylesheet) in this new theme post meta.

(Note: at the moment we only convert templates provided by the current theme, hence we simply get the current theme's stylesheet.)

This "source" meta is displayed in the wp_template wp-admin list.
theme-provided templates' source will be "Theme: {theme name or slug}"; all other templates (edited by user) will simply show "Site".
This means that if a theme-provided template is edited by a user, and its status turns into publish, it's source will be "Site" and not "Theme" anymore".

I haven't added this new info to the Site Editor sidebar or documents settings, as I think at this point it's becoming very crowded, and I'd rather wait for design feedback.

Still, I believe the "source" is an essential information, and we should record it, and (at least temporarily while in development) display it in the wp_template wp-admin list.

Addison-Stavlo

Similarly to wp_template_part, I've added a new theme post meta to wp_template.

Great!

all other templates (edited by user) will simply show "Site".
This means that if a theme-provided template is edited by a user, and its status turns into publish, it's source will be "Site" and not "Theme" anymore".

I think we should try to make templates and template-parts consistent with how they behave regarding this sort of thing.

Currently, when a template-part is created by a user its theme is labeled as custom. I think either we should update template parts to be 'site' as well, or change it here to be 'custom' as well.

The other difference is that this only happens for new template parts. Template parts that originally come from a theme file will still have its theme's name saved in the meta once it goes from auto-draft to publish. I think this is by design as it corresponds to a template part from a specific theme that you have made customizations to, but the information about the theme it came from still exists as that information may still be useful.

If we are going with a status such astheme-provided, then we know that publish state is customized even if its theme meta still references the theme in which it came from. And maybe 'site' or 'custom' should only be given to templates that are created from scratch, and not those that are customized from a theme supplied one? 🤔

Yes!
But in a follow up, if we think this is the right way to go.

Sounds good 👍

Also, we need to be 100% sure about the new status name
theme-provided was my first idea, but it's not great (e.g. plugin can provide templates as well).
Ideally the name should convey that it originates from a file (file-based?),

Ah yeah, I'm not great with coming up with names either. Maybe something as simple as unedited would imply it came from an outside source and hasn't been changed?

Copons · 2020-10-28T17:15:56Z

all other templates (edited by user) will simply show "Site".
This means that if a theme-provided template is edited by a user, and its status turns into publish, it's source will be "Site" and not "Theme" anymore".

I think we should try to make templates and template-parts consistent with how they behave regarding this sort of thing.

Currently, when a template-part is created by a user its theme is labeled as custom. I think either we should update template parts to be 'site' as well, or change it here to be 'custom' as well.

The other difference is that this only happens for new template parts. Template parts that originally come from a theme file will still have its theme's name saved in the meta once it goes from auto-draft to publish. I think this is by design as it corresponds to a template part from a specific theme that you have made customizations to, but the information about the theme it came from still exists as that information may still be useful.

If we are going with a status such astheme-provided, then we know that publish state is customized even if its theme meta still references the theme in which it came from. And maybe 'site' or 'custom' should only be given to templates that are created from scratch, and not those that are customized from a theme supplied one? 🤔

I've definitely failed to explain how the meta is used. 🤦

When a user edits a theme-provided template, making it their own, the theme meta is unaffected, and keeps its original value (which is: the theme that provided it in the first place).

Then, the Source column in the wp_template wp-admin list will show it as "Site" rather than "Theme: Foobar".
The code should make this "switcheroo" clear:

gutenberg/lib/templates.php

Lines 207 to 217 in 4b9eb4b

    
           if ( 'source' === $column_name ) { 
        
           	$post_status = get_post_status( $post_id ); 
        
           	$theme = get_post_meta( $post_id, 'theme', true ); 
        
           	if ( $theme && 'theme-provided' === $post_status ) { 
        
           		$theme_data = wp_get_theme( $theme ); 
        
           		echo sprintf( __( 'Theme: %s' ), $theme_data->display( 'Name' ) ); 
        
           		return; 
        
           	} 
        
           	echo __( 'Site' ); 
        
           	return; 
        
           }

I guess this might be improved a little bit. 🙂

If theme-provided: source is "Theme: Foobar".
If fully custom: source is "Custom".
If customized from a theme-provided template: source is "Custom - Originally from theme: Foobar"

Currently, when a template-part is created by a user its theme is labeled as custom. I think either we should update template parts to be 'site' as well, or change it here to be 'custom' as well.

That's not a very consistent behaviour...
For example, you can create a template part from the wp_template_part wp-admin list, and it would show up with theme: ''.

IMHO the empty string should be the way to go here, rather than using custom (or any other arbitrary string).
An empty string automatically means that the element doesn't belong to any theme, and has the additional side effect of not conflicting with an hypothetical theme named custom. 😄

Templates are already like this: fully custom templates will be theme: '', while theme-provided ones (even once customized) will have the theme slug (stylesheet).

Addison-Stavlo

That makes sense, thanks for clarifying!

I guess this might be improved a little bit. 🙂

If theme-provided: source is "Theme: Foobar".

If fully custom: source is "Custom".

If customized from a theme-provided template: source is "Custom - Originally from theme: Foobar"

Yeah that amount of distinction makes sense to me 👍 . (Maybe "Theme: Foobar (customized)" to keep it shorter if need be.)

IMHO the empty string should be the way to go here, rather than using custom (or any other arbitrary string).

I think you have convinced me that the empty string would also make more sense in the template-part case! This will be more consistent and we can always label them as 'Custom' in the interface if the theme meta is blank.

Copons · 2020-11-02T17:10:40Z

Replaced by #26636

Copons added [Status] In Progress Tracking issues with work in progress [Feature] Full Site Editing labels Oct 22, 2020

Copons self-assigned this Oct 22, 2020

Copons commented Oct 22, 2020

View reviewed changes

mtias reviewed Oct 23, 2020

View reviewed changes

lib/full-site-editing/templates-definitions.php Outdated Show resolved Hide resolved

Copons force-pushed the try/fse-templates-definitions branch 2 times, most recently from 7902652 to 69b1ccc Compare October 26, 2020 13:46

Copons changed the title ~~Try/fse templates definitions~~ Full Site Editing: Add Support for Templates Default and Custom Titles and Descriptions Oct 26, 2020

Copons requested review from Addison-Stavlo, david-szabo97, jeyip, mattwiebe, noahtallen, shaunandrews, vindl and youknowriad October 26, 2020 17:48

Copons marked this pull request as ready for review October 26, 2020 17:49

Copons requested review from TimothyBJacobs, nerrad and spacedmonkey as code owners October 26, 2020 17:49

Copons added Needs Copy Review Needs review of user-facing copy (language, phrasing) Needs Design Feedback Needs general design feedback. Needs Technical Feedback Needs testing from a developer perspective. and removed [Status] In Progress Tracking issues with work in progress labels Oct 26, 2020

Copons mentioned this pull request Oct 26, 2020

Site Editor: Reduce the Amount of Data Passed Through the Components Tree #26463

Merged

6 tasks

Copons force-pushed the try/fse-templates-definitions branch from ff8b5c4 to e751630 Compare October 26, 2020 19:19

Copons removed the Needs Copy Review Needs review of user-facing copy (language, phrasing) label Oct 26, 2020

Copons force-pushed the try/fse-templates-definitions branch from e751630 to a9256b8 Compare October 27, 2020 13:20

Copons added 12 commits October 28, 2020 11:27

Use the PHP templates definitions before falling back to the JS ones

6a0589b

Localize template types definitions

1d692be

Make the definitions filterable

a421ade

Update the new template dropdown to use the new status

36e6eab

Improve names and clean up

8e17c0c

Completely replace the JS definitions with the PHP ones

93306f3

New templates use definitions too

c8f6b4b

Fix templates wp-admin list

87997d1

Sort out merge issues

a009e0d

Replace getTemplateInfo with useTemplateInfo

be61a93

Prevent editor crash

0b39c35

Add useTemplateInfo tests

15e1b3e

Copons force-pushed the try/fse-templates-definitions branch from 5ac7875 to 15e1b3e Compare October 28, 2020 11:27

Copons added 2 commits October 28, 2020 11:58

Add a theme source to templates

d636c9a

Fix source for customized theme templates

4b9eb4b

This was referenced Oct 28, 2020

Full Site Editing: Templates and Template Parts Duplicates #26546

Closed

Site Editor: old template part drafts appear in the sidebar #26402

Closed

Addison-Stavlo reviewed Oct 28, 2020

View reviewed changes

Improve the template list columns output

24ef74a

gziolo self-requested a review October 29, 2020 11:41

Addison-Stavlo mentioned this pull request Oct 29, 2020

Fix custom template part theme meta. #26587

Merged

6 tasks

Copons mentioned this pull request Oct 30, 2020

Site Editor: reorder template creation dropdown #26610

Merged

6 tasks

Copons added the [Status] Blocked Used to indicate that a current effort isn't able to move forward label Nov 2, 2020

Copons mentioned this pull request Nov 2, 2020

Full Site Editing: Add Support for Templates Default and Custom Titles and Descriptions (Second Attempt) #26636

Closed

6 tasks

Copons closed this Nov 2, 2020

Copons deleted the try/fse-templates-definitions branch November 2, 2020 18:02

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Full Site Editing: Add Support for Templates Default and Custom Titles and Descriptions#26394

Full Site Editing: Add Support for Templates Default and Custom Titles and Descriptions#26394
Copons wants to merge 19 commits intomasterfrom
try/fse-templates-definitions

Copons commented Oct 22, 2020 •

edited

Loading

Uh oh!

Copons Oct 22, 2020

Uh oh!

github-actions bot commented Oct 22, 2020 •

edited

Loading

Uh oh!

Uh oh!

Copons commented Oct 27, 2020 •

edited

Loading

Uh oh!

Copons commented Oct 28, 2020 •

edited

Loading

Uh oh!

Addison-Stavlo left a comment

Uh oh!

Copons commented Oct 28, 2020

Uh oh!

Addison-Stavlo left a comment

Uh oh!

Copons commented Nov 2, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Copons commented Oct 22, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Follow up

How has this been tested?

Screenshots

Types of changes

Checklist:

Uh oh!

Copons Oct 22, 2020

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Oct 22, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Copons commented Oct 27, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copons commented Oct 28, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Addison-Stavlo left a comment

Choose a reason for hiding this comment

Uh oh!

Copons commented Oct 28, 2020

Uh oh!

Addison-Stavlo left a comment

Choose a reason for hiding this comment

Uh oh!

Copons commented Nov 2, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copons commented Oct 22, 2020 •

edited

Loading

github-actions bot commented Oct 22, 2020 •

edited

Loading

Copons commented Oct 27, 2020 •

edited

Loading

Copons commented Oct 28, 2020 •

edited

Loading