Skip to content
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

Add fallback content when creating templates according to template hierarchy #37054

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Expand Up @@ -30,8 +30,40 @@ const DEFAULT_TEMPLATE_SLUGS = [
'index',
];

// The "Template Hierarchy" mapping from registered templates.
// @see https://developer.wordpress.org/themes/basics/template-hierarchy/
const TEMPLATE_HIERARCHY = {
'font-page': 'home',
home: 'index',
'single-post': 'single',
single: 'singular',
singular: 'index',
page: 'singular',
archive: 'category',
category: 'index',
Comment on lines +42 to +43
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is slightly incorrect. A new category template should use archive as the fallback. A new archive template should use index as the fallback.

Edit: We don't currently allow the creation of category templates at all, so perhaps that can be omitted for now?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and if neither archive or category exist, archive should fall back to index too

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I just found a helper that already does something like this:

export function isTemplateSuperseded( slug, existingSlugs, showOnFront ) {

It's using this const:

export const TEMPLATE_OVERRIDES = {
singular: [ 'single', 'page' ],
index: [ 'archive', '404', 'search', 'singular', 'home' ],
home: [ 'front-page' ],
};

We might wanna reuse that (unless we decide to go with #37258 😊).

search: 'index',
404: 'index',
};

function getFallbackTemplateContentFromHierarchy( templateSlug, templates ) {
const fallbackTemplateSlug = TEMPLATE_HIERARCHY[ templateSlug ] || 'index';

const fallbackTemplate = templates.find(
( template ) => template.slug === fallbackTemplateSlug
);

if ( ! fallbackTemplate ) {
return getFallbackTemplateContentFromHierarchy(
fallbackTemplateSlug,
templates
);
}

return fallbackTemplate.content.raw;
}

export default function NewTemplate( { postType } ) {
const { templates, defaultTemplateTypes } = useSelect(
const { templates, defaultTemplateTypes, defaultBlockTemplate } = useSelect(
( select ) => ( {
templates: select( coreStore ).getEntityRecords(
'postType',
Expand All @@ -41,6 +73,8 @@ export default function NewTemplate( { postType } ) {
defaultTemplateTypes: select(
editorStore
).__experimentalGetDefaultTemplateTypes(),
defaultBlockTemplate: select( editorStore ).getEditorSettings()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was initially an API suited for "custom templates" and not "hierarchy templates". Is it fine to use it consistently no matter the template?

Also should we sync the logic here with the fallback done in the template mode? (post editor)

.defaultBlockTemplate,
} ),
[]
);
Expand All @@ -52,13 +86,18 @@ export default function NewTemplate( { postType } ) {
slug,
} );

const newTemplateContent =
defaultBlockTemplate ??
getFallbackTemplateContentFromHierarchy( slug, templates );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit weird to rely on existing templates to create a fallback template content? Is this how it's supposed to work or should we actually provide a list of default fallbacks?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The motivation for using existing templates is to ensure that the new template matches the current theme design (IE include the appropriate header / footer template parts and general block structure).

A much simpler approach would be to prescribe a template including the base header / footer template parts, then the user would need to select which one to use whilst creating the template. So a new search template might look like:

Screenshot 2021-12-08 at 10 06 45

The drawback here is that if the theme has a complex layout (maybe the header is actually a sidebar) then this won't match at all.


const template = await apiFetch( {
path: '/wp/v2/templates',
method: 'POST',
data: {
excerpt: description,
// Slugs need to be strings, so this is for template `404`
slug: slug.toString(),
content: newTemplateContent,
status: 'publish',
title,
},
Expand Down