-
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
Avoid using auto-drafts for theme templates and template parts #27910
Conversation
Size Change: -870 B (0%) Total Size: 1.3 MB
ℹ️ View Unchanged
|
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.
Left feedback mainly on the REST API controllers. A number of issues apply to both, I only commented on the template parts controller since that was first.
I also wonder if we should instead be using the correct edit_post
etc... caps here and setting up the CPT to use edit_theme_options
when registering. That way developers can give more fine-grained capabilities if needed. Cc @peterwilsoncc, @swissspidy.
Can templates / template parts not be deleted?
lib/full-site-editing/class-wp-rest-template-parts-controller.php
Outdated
Show resolved
Hide resolved
lib/full-site-editing/class-wp-rest-template-parts-controller.php
Outdated
Show resolved
Hide resolved
lib/full-site-editing/class-wp-rest-template-parts-controller.php
Outdated
Show resolved
Hide resolved
lib/full-site-editing/class-wp-rest-template-parts-controller.php
Outdated
Show resolved
Hide resolved
lib/full-site-editing/class-wp-rest-template-parts-controller.php
Outdated
Show resolved
Hide resolved
lib/full-site-editing/class-wp-rest-template-parts-controller.php
Outdated
Show resolved
Hide resolved
lib/full-site-editing/class-wp-rest-template-parts-controller.php
Outdated
Show resolved
Hide resolved
For me, |
I'll add this. I just didn't use it initially. |
I agree that's what Core should use under the hood. But if the controller itself uses |
packages/block-library/src/template-part/edit/placeholder/index.js
Outdated
Show resolved
Hide resolved
packages/block-library/src/template-part/edit/placeholder/index.js
Outdated
Show resolved
Hide resolved
The REST API bits are looking good to me! Can we get some tests on this please? |
5d664da
to
34b0c07
Compare
About the tests, this is actually already well covered with the e2e tests which is what allowed me to have confidence in such a big refactor. That said, some additional PHP specific tests won't hurt. I'll see what I can do. |
Yes, you will also need to:
|
Can I get a ✅ here? I'd like to land this before the next RC so it can be tested properly. There are still a few things to consider in follow-ups and specifically the removal of the "theme" attribute from the template and template parts files. |
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.
Great work here Riad! I agree that this PR is in good shape to land, so it can be tested better.
Thanks!
I hope I didn't miss anything, that's a big PR with a lot of reviews :P |
closes #27321
borrows ideas from #27624
This PR borrows some ideas from #27624 and tries to avoid using auto-drafts for the template and template-parts that come from the theme (unmodified). It is based on the following principle:
Based on this premise, it provides two abstraction layers: the
full-site-editing/block-templates.php
provides simple functions to retrieve templates (or template parts) given a simple query, or an id. This abstract away the fact that template can come from a file or from a CPT depending on whether it's customized or not.On top of this "PHP" layer, it overrides the REST Controllers to provide endpoints for the templates and template parts. The client uses these endpoints similarly to how it's done today, the difference is that instead of using regular IDs, the actual ids are "theme+slug".
This proved to have a lot of advantages: