Right now, full site editing UI and frontend rendering fetch templates from the wp_template and wp_template_part CPT, whether it's for the templates that are edited by the user or the ones that are provided by the theme. This means a "synchronization" step is needed between the theme files and the CPT.

This synchronization simplifies the fetching by allowing us to only use the CPT endpoints and WPQuery to retrieve the desired templates but it has its drawbacks:

• Performance: on each wp_load or QPQuery for the templates, we compare the file modification data to ensure whether we need to update the templates or not. This might become costly depending on the number of templates and templates parts we need to deal with.
• Stale templates: Each time we switch to another theme, a new set of templates and template parts are created and added to the database, we could consider removing the unmodified templates on theme switch but it comes at a cost.
• Dynamic templates: we're considering introducing PHP templates for translations, the syncing would need to be performed on each local switch. (and this scales to any dynamic behavior we might want to introduce and might not be easy to "detect")

Proposal

We should consider checking what would it take to update the framework to rely on the files directly for unmodified templates. Some potential challenges here will be:

• Make the editor work with entities created on the client.
• Potential changes to core-data saveEntity actions to map temporary ids with real ones.
• Resolving a template would require fetching both the saved templates and the available files in order to find the right template for a given page.

cc @vindl @Copons @david-szabo97 @Addison-Stavlo @noahtallen @jeyip @mattwiebe @mtias @aristath @ockham @carlomanf