Store Editing Templates: Clearing customizations requires a refresh.

[tjcafferkey]

Describe the bug

If you customize a block template, and then via the "Browse All Templates" view, clear those customizations when you click the block template they still exist in the Editor and require a browser refresh to clear. At first I thought this was a Gutenberg issue, but this issue does not occur when disabling WooCommerce & WooCommerce Blocks.

To reproduce

Steps to reproduce the behavior:

1. With WP 5.9 + WooCommerce activate go to Appearance > Site Editor
2. Go to "Browse all templates" and select a template to make customizations to.
3. Save the customizations, go back to "Browse all templates" view and clear the customizations via this view.
4. Aftering clearing the customizations, click into the block template again and see that your customizations are still there.
5. Refreshing the browser here fixes the problem.

Expected behavior

On step 4 I expect that the customizations will have cleared.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

WordPress (please complete the following information):

• Core version: 5.9
• WooCommerce version: 6.1.1
• WooCommerce Blocks version: 6.8.0

[tomasztunik]

Easier steps to reproduce:

• Go to template editor
• Add a block to any page template (Woo or not)
• Open dropdown with area/template switcher
• Hit "Clear customisations"
• Changes are persisted

Confirmed that with WooCommerce disabled this path works fine as well.

[tomasztunik]

I've found that reverting this change #5342 fixes the issue.

Problem here is that we alter behaviour of the get_block_file_template and instead of allowing it to retrieve the original theme for given template or part when it's called explicitly we return current state.

When reverting theme to get the original state we call the WP_REST_Templates_Controller->get_item where $request['source'] === 'theme'. Without WooCommerce installed it goes through that method and returns it with get_block_file_template, and as desired returns original theme state of the template.

When WooCommerce is enabled BlockTemplatesController will capture this action with maybe_return_blocks_template hooked on pre_get_block_file_template. Instead of using the get_block_file_template it either falls back to gutenberg_get_block_template which returns database version and original only as a fallback, or if gutenberg_get_block_template is not present will return get_block_template which which works same as above - will return latest version and original as fallback.

I'm not aware of all possible implications reverting #5342 can bring so will leave it at this - Hopefuly we can wrap it up on Monday 🚀

cc: @Aljullu

[tjcafferkey]

Thanks @tomasztunik! Reverting #5342 will fix the "Clear Customisations" functionality accessed from inside the Site Editor (see screenshot below) although will reintroduce the bug which is described here #5272. I believe these are separate issues that we have been looking into.

The more I look into the issue described in the reproduction steps the more I think it's an issue with the Site Editor, perhaps some frontend caching between route changes that is incorrectly persisting between the All Templates list and the Site Editor view. There is some real funny business going on. Even though the below videos show two slightly different issues I suspect these are symptoms of the same underlying problem.

With WooCommerce & WooCommerce Blocks installed:

Site.Editor.-.With.WooCommerce.mp4

Without WooCommerce & WooCommerce Blocks installed:

Site.Editor.-.Without.WooCommerce.mp4

For reference this is the package we use for routing: history