-
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
Add fallback content when creating templates according to template hierarchy #37054
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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', | ||
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', | ||
|
@@ -41,6 +73,8 @@ export default function NewTemplate( { postType } ) { | |
defaultTemplateTypes: select( | ||
editorStore | ||
).__experimentalGetDefaultTemplateTypes(), | ||
defaultBlockTemplate: select( editorStore ).getEditorSettings() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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, | ||
} ), | ||
[] | ||
); | ||
|
@@ -52,13 +86,18 @@ export default function NewTemplate( { postType } ) { | |
slug, | ||
} ); | ||
|
||
const newTemplateContent = | ||
defaultBlockTemplate ?? | ||
getFallbackTemplateContentFromHierarchy( slug, templates ); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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: 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, | ||
}, | ||
|
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.
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?
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.
and if neither archive or category exist, archive should fall back to index too
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.
BTW I just found a helper that already does something like this:
gutenberg/packages/edit-site/src/components/navigation-sidebar/navigation-panel/template-hierarchy.js
Line 21 in 2e5af3f
It's using this
const
:gutenberg/packages/edit-site/src/components/navigation-sidebar/navigation-panel/constants.js
Lines 64 to 68 in 5562482
We might wanna reuse that (unless we decide to go with #37258 😊).