Size Change: -870 B (0%)

Total Size: 1.3 MB

_{compressed-size-action}

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.

For me, edit_theme_options is better because these are more "theme related" than "content related". It also matches the widgets endpoint.

Can templates / template parts not be deleted?

I'll add this. I just didn't use it initially.

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.

For me, edit_theme_options is better because these are more "theme related" than "content related". It also matches the widgets endpoint.

I agree that's what Core should use under the hood. But if the controller itself uses edit_post, read_post etc... Then a developer can customize those caps checks to be more/less restrictive as needed. This would be done with the capabilities register_post_type arg.

The REST API bits are looking good to me! Can we get some tests on this please?

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.

So, I think I've addressed all the questions and suggestions here, this seems ready to land for me.

The last question I have is whether we should include a migration or not for existing FSE sites as this will probably break them. We never did database migrations before in Gutenberg, some leads here would be appreciated.

If I'm not wrong, the changes we need to make are

• Remove all auto-draft wp_template and wp_template-part records.
• Remove all _wp_file_based terms in the wp-theme taxonomy and the corresponding links to posts.

Anything else I'm missing?
Should we include the migration? How?

Yes, you will also need to:

• remove the definition of _wp_file_based from the wp_terms and wp_term_taxonomy tables (the relationships will be deleted automatically with wp_delete_term)
• remove the gutenberg_last_synchronize_theme_template_checks and gutenberg_last_synchronize_theme_template-part_checks entries from the wp_options table

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.

I hope I didn't miss anything, that's a big PR with a lot of reviews :P