Site Editor: Revert templates to their original theme-provided files #27208
Conversation
Copons
requested review from
mattwiebe,
jameskoster,
vindl,
david-szabo97,
jeyip,
noahtallen and
Addison-Stavlo
|
Size Change: +1.73 kB (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Going through these steps:
- Use the 2021 Blocks theme.
- Directly edit the Front Page autodraft (/wp-admin/edit.php?post_type=wp_template&post_status=auto-draft).
- Change its title in something like "CUSTOM FRONT PAGE", and make sure it's published.
Then:- Open the Site Editor.
- Make sure it's showing the "CUSTOM FRONT PAGE".
- Open the document actions (in the editor header), and click on "Revert".
- Wait a little bit.
Im getting the notice that "this template is not revertable" 🤔 I have tried cleaning my environment and starting over and am still getting this message.
Nice! That did it 😄 |
@Addison-Stavlo apologies, in one case I was passing the wrong parameter to the Speaking of: is "revertable" the correct word? The "This template is not revertable" notice shows up for 2 different errors:
Now, the case 2 is not really testable, and would cause many headaches if it happens for real. Given how the sync mechanism work, it shouldn't be possible to happen, but I've still decided to add an error notice there just in case. Case 1 could be reworded as "It's not possible to revert this template". |
| if ( ! fileTemplates.length ) { | ||
| yield controls.dispatch( | ||
| 'core/notices', | ||
| 'createErrorNotice', | ||
| __( 'This template is not revertable' ), | ||
| { type: 'snackbar' } | ||
| ); | ||
| return; | ||
| } |
There was a problem hiding this comment.
It looks like we can create this notice in 2 places:
- Prior to this step when
isTemplateRevertablecomes back falsy. - Here after we have already sent the
apiFetchto delete the template and fail to find the auto-draft to replace it with.
Should we be checking that autodraft and conditionally sending this notice before sending the apiFetch to delete?
There was a problem hiding this comment.
Oh, Yeah I see why we have to do it this way and missed your recent note above:
Now, the case 2 is not really testable, and would cause many headaches if it happens for real. Given how the sync mechanism work, it shouldn't be possible to happen, but I've still decided to add an error notice there just in case.
Maybe the notice could change into "An unexpected error occurred. Please reload."
The unexpected error message may make more sense in this case. 🤔
Perhaps it would make sense to always create the auto-draft if the auto-draft doesn't exist. So the new auto-draft would be created as soon as the original one was customized and published, as opposed to right after it is deleted? Not a blocker for this PR, but a follow up if necessary.
It seems correct to me. And "This template is not revertable" sounds better than "It is not possible to revert this template" from my perspective. Maybe design will have a different opinion, but updating the copy in the future could be pretty simple if there is an issue with it. |
|
🛑 After clicking |
| yield apiFetch( { | ||
| path: `/wp/v2/${ postType.rest_base }/${ template.id }`, | ||
| method: 'DELETE', | ||
| } ); |
There was a problem hiding this comment.
| yield apiFetch( { | |
| path: `/wp/v2/${ postType.rest_base }/${ template.id }`, | |
| method: 'DELETE', | |
| } ); | |
| yield controls.dispatch( | |
| 'core', | |
| 'deleteEntityRecord', | |
| 'postType', | |
| 'wp_template', | |
| template.id | |
| ); |
There was a problem hiding this comment.
Using the built-in deleteEntityRecord should take care of invalidating the cache and doing a rerequest.
There was a problem hiding this comment.
Nice catch @david-szabo97, I didn't think of checking the sidebar. ✨
Copons
added
the
[Status] Blocked
|
Replaced by #28141 |
Description
Fixes #23421
core/edit-siteaction that reverts a template to its original theme-provided file.WIP Notes
themeparameter used in this PR. I've introduced it in Site Editor: Only request templates and template parts for the current theme #27152.Technical Notes
"Reverting a template" means:
auto-draft.auto-drafttemplates for the current theme, with the same slug of the deleted template."Revertable template" indicates a template that:
auto-draft.wp_themetaxonomy includes the current theme's slug)._wp_file_based(itswp_themetaxonomy includes_wp_file_based).Edge Case Issue (see 19951bd)
This approach relies on the templates sync that runs automatically whenever the site detects differences between the theme-provided file templates and the template posts.
As far as I understand, this should reliably work in all scenarios I could think of, except in one.
What if the theme used to provide a file template and it doesn't anymore?
For example, let's say a theme at version 1.0 provided an
indextemplate.The sync creates an
indexauto-draft and tags it as_wp_file_based.The user customizes that
indextemplate.Then, the theme updates to version 2.0, dropping support for the
indextemplate by removing theindextemplate file.The
indextemplate post is still tagged as_wp_file_based, but it doesn't have an original file to revert to.My first idea was to revert to the first revision of the template post, but as it turns out,
auto-draftdon't have revisions.In other word, the first revision of a custom template would be the first time the user customized it.
Another idea could be to update the templates endpoint for
_wp_file_basedtemplates to check if the theme still has their original file to revert to.I'm going to explore this, and see how complicated it would be.
How has this been tested?
To simplify this test, set up your site like this:
/wp-admin/edit.php?post_type=wp_template&post_status=auto-draft).Change its title in something like "CUSTOM FRONT PAGE", and make sure it's published.
Then:
/wp-admin/edit.php?post_type=wp_template).Harder test:
/wp-content/themes/THEME_NAME/block-templates.Types of changes
New feature (non-breaking change which adds functionality)
Checklist: