Full Site Editing: Stop using auto-draft for auto-generated templates and template parts #27277
Conversation
|
Size Change: +328 B (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
Copons
changed the title
Copons
added
[Feature] Full Site Editing
[Status] In Progress
Copons
requested review from
Addison-Stavlo,
david-szabo97,
vindl,
noahtallen,
mattwiebe and
jeyip
Copons
requested review from
ajitbohra,
chrisvanpatten,
nerrad,
ntwb,
spacedmonkey,
talldan and
TimothyBJacobs
as code owners
There was a problem hiding this comment.
Overall, this makes sense to me. It seems to clean up the code quite a bit, and I'm not really noticing any issues in the site editor. A bit tricky to test, though :)
I wonder, is _wp_is_original verbose enough? Should it be something like _wp_is_original_template_file?
Also curious if others have opinions about going with this approach instead. But from my PoV, I'm in favor
| * [ | ||
| * 'is_file_based', // Whether the template is based upon a theme-provided file. | ||
| * 'is_original', // Whether the template is the original theme-provided file. | ||
| * 'themes', // An array of themes that this template belongs to. |
There was a problem hiding this comment.
How can a template belong to multiple themes?
There was a problem hiding this comment.
It can't right now. But in the future we might want to share templates between multiple themes. Which would be possible by assigning it to multiple themes.
Something like that I guess.
There was a problem hiding this comment.
We will also eventually decide what to do with child themes that inherit templates from their parent.
One (naive, probably) way to handle it is to have both child and parent themes slugs in the array. 🤔
| select( 'core' ).getEntityRecords( 'postType', 'wp_template_part', { | ||
| theme: currentTheme, | ||
| status: [ 'auto-draft' ], | ||
| theme: [ currentTheme, '_wp_is_original' ], |
There was a problem hiding this comment.
Why does it all go into a single array?
There was a problem hiding this comment.
They are stored in the same taxonomy.
There was a problem hiding this comment.
What if a theme is called _wp_is_original or _wp_file_based
|
I like it, but I find the naming of |
|
I like those names better too 👍 |
|
Although even |
|
I can also imagine users saying something like, "I made an original template," which would mean the exact opposite of what "original" means here. |
|
|
| $themes = wp_get_post_terms( $post_id, 'wp_theme' ); | ||
| if ( ! $themes ) { | ||
| wp_set_post_terms( $post_id, array( wp_get_theme()->get_stylesheet() ), 'wp_theme', true ); | ||
| } | ||
| if ( $update && has_term( '_wp_is_original', 'wp_theme', $post_id ) ) { | ||
| wp_remove_object_terms( $post_id, '_wp_is_original', 'wp_theme' ); | ||
| } |
There was a problem hiding this comment.
I think this would wrongly remove the term if it's being updated based on a file change?
| select( 'core' ).getEntityRecords( 'postType', 'wp_template_part', { | ||
| theme: currentTheme, | ||
| status: [ 'auto-draft' ], | ||
| theme: [ currentTheme, '_wp_is_original' ], |
There was a problem hiding this comment.
What if a theme is called _wp_is_original or _wp_file_based
|
I've pushed a rather big update to this in 27f2166. Remember: names are up for discussion!
The
|
|
Good. I'm glad you've done this. I'm currently battling with I've also noted a problem where the Finally, when will synchronization be performed? |
@bobbingwide Excellent reminder.
We are not explicitly setting the post author of templates and template parts, so it will default to the current user.
Currently it's on every single load. I wonder if we might only sync while in wp-admin, though. |
Yeah, I guess that would be good enough, assuming this flow still works:
In that case, the templates would need to have been synced for the site to work. I'm not sure if wp_load is run at all after the theme is activated before you visit a different wp-admin page. |
In
So, Now, if we want to start locking down the re-sync logic, we can look instead at using the That won't, however, deal with resyncing a theme that's in active development locally. Some ideas for that:
|
Nice, thanks for that extra detail! Does that also happen if activating a theme programmatically? |
Could there be a way to use the post author to determine whether the update is being done by the system or by the user, as an alternative to all these extra flags? I'm thinking to set it to 0 when the system is updating it, and set it to the current user when they are doing a manual edit? |
It won't be exactly that, but the very next request to the site will call |
Description
This PR proposes a change of direction regarding templates and template parts automatically generated from theme-provided files.
Instead of creating
auto-draftposts, we createpublishposts with a new internal_wp_is_originalterm (in the recently introducedwp_themetaxonomy).The
_wp_is_originalterm indicates those templates and template parts provided by the theme, that haven't been customized by the user yet.Auto-generated templates and template parts will be created with a
_wp_is_originalterm.Once updated, they will lose that term, and won't be able to get it back.
✨ Props to @david-szabo97 for the idea! ✨
Reasons
The
auto-draftstatus is a rather unwieldy beast.It's supposed to be used for posts that have been created and not manually saved yet; once they are saved, they gain a "stable" status, such as
draftorpublish. While the description seems to fit auto-generated templates, there are more quirks to consider.auto-draftis not supposed to be handled by the user. It doesn't appear in normal queries (we always need to query specifically for that status) and it doesn't show up in wp-admin. WP doesn't even provide localized labels to it when it's registered.In Gutenberg,
auto-draftposts are not supposed to have titles. Whileauto-draftposts per se can have titles, Gutenberg strips it from them.auto-draftposts don't create revisions. This is logical, given the "auto-draft" state should only be a bridge between editor load and first save.But even manually calling
wp_save_post_revisionisn't of any help, since it's a no-op forauto-draftposts.auto-draftposts can be pruned by functions such aswp_delete_auto_draft, and also typically by database cleaning plugins. (Props to @carlomanf for noticing this!)Impact
This PR shouldn't change the behaviour of Site Editor and front-end with one exception: the Template Part block's preview selector doesn't return "theme-agnostic" template parts anymore.
I'm considering this not an issue, considering we are removing that feature for the foreseeable future in Site Editor: Only request templates and template parts for the current theme #27152 anyway.
I'm marking this PR as "breaking change", but in fact it should be relatively backward-compatible.
Templates and template parts that have been already customized won't be affected.
Old
auto-drafts will be ignored (not deleted, though), and replaced with new auto-generated posts with statuspublishand_is_wp_originalterm.How has this been tested?
Smoke test everything! 🎉
Types of changes
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Checklist: