Perform template synchronisation in the InnerBlocks component

[john-freedman]

Describe the bug
When creating a post that uses 'template_lock'=>'all' and contains InnerBlocks with templateLock={false}, everything works as it should (top level of the template is locked, but InnerBlock sections are unlocked). But after adding content to those InnerBlocks using the editor, next time you edit that post, Gutenberg prompts, "The content of your post doesn’t match the template assigned to your post type."

To Reproduce
Steps to reproduce the behavior:

1. Make a custom post type with a template defined:

register_post_type( 'test', array(
  'label' => 'Test',
  'public' => true,
  'show_in_rest' => true,
  'template' => array(
    array( 'test/test_block', array(), array() ),
  ),
  'template_lock' => 'all'
) );

2. registerBlockType

registerBlockType( 'test/test_block', {
  // usual code here

  edit( { className } ) {
    return (
      <div className={ className }>
        <InnerBlocks templateLock={ false } />
      </div>
    );
  },
  save() {
    return (
      <div>
        <InnerBlocks.Content />
      </div>
    );
  }
}

3. In the WordPress admin, create a new post of this post type, put anything inside the block that's on this page, and publish the post.
4. Refresh the post edit page (or leave this page and navigate to it again) and you'll see this error:

Expected behavior
I think there isn't supposed to be an error, but I'm not sure. I can't find this specific issue mentioned anywhere, so I could easily just be doing something wrong, but I can't figure out what it is. If it is user error, then I'm sorry for the trouble.

Additional context

• Gutenberg 4.2.0
• Wordpress 4.9.8

[skript-cc]

I have exactly the same problem when setting a custom template for the 'post' post type. My template has the same template locking setup.

[janeschindler]

I have the same problem with the same setup.

[youknowriad]

Yes, I think nested templates validation should not happen at the root level like it's done now but it should happen inside the InnerBlocks component as it's the one that is aware of its locking config.

[youknowriad]

cc @jorgefilipecosta

[FerrielMelarpis]

Is there a workaround for this issue?

[mmtr]

Is there a workaround for this issue?

You can manually force the template validity by dispatching a setTemplateValidity action:

dispatch( 'core/block-editor' ).setTemplateValidity( true );

[chrisvanpatten]

This bit me today as well. I solved it with the trick @mmtr shared; here's my full code if anyone wants to steal it:

/**
 * WordPress dependencies
 */
import { compose } from '@wordpress/compose';
import { withDispatch } from '@wordpress/data';
import { InnerBlocks } from '@wordpress/editor';

/**
 * Container block
 *
 * @return {Object}
 */
const Editor = () => (
	<InnerBlocks templateLock={ false } />
);

// This is a hack which forces the template to appear valid.
// See https://github.com/WordPress/gutenberg/issues/11681
const enforceTemplateValidity = withDispatch( ( dispatch, props ) => {
	dispatch( 'core/block-editor' ).setTemplateValidity( true );
} );

export default compose(
	enforceTemplateValidity,
)( Editor );

Definitely feels hacky though; I'd love to see it resolved in a better way :)