Rename "Content only" template lock API to something else

[talldan]

The template lock feature currently has the following values:

• all - everything is locked
• insert - blocks cannot be inserted
• false - there is no template locking

#43037 introduced a new 'contentOnly' template lock feature that allows content to be edited. The naming of this new feature is inconsistent. The existing values imply the aspect of the blocks that are locked, so 'contentOnly' would mean that content can't be edited.

If there's the possibility of renaming this it would be good to do it early. It's difficult to come up with suggestions. Maybe something like 'editableContent'. @noisysocks suggested 'chrome' or 'allButContent'.

cc @jorgefilipecosta

[stokesman]

It seems there’s no getting around the fact that the new feature is a greater level of locking than the existing all and any name is going to conflict with the concept of all. So wouldn't the fix be to surface the new feature separately and have it override templateLock when enabled. Something like:
editOnlyContent: boolean
Or maybe:
editable = 'all': 'all' | 'content'

If we really hate having them separate the latter of those suggestions (or something like it) could expand to include the templateLock features so as to deprecate it (though it'd probably never become unsupported)

[noisysocks]

It seems there’s no getting around the fact that the new feature is a greater level of locking than the existing all

This isn't correct, is it? all locks everything but contentOnly allows the content to be edited. Hence my (bad) suggestion of renaming contentOnly to allButContent.

[stokesman]

Screen recording demonstrating that contentOnly is a greater level of locking than all:

demo-template-lock.mp4

If anyone cares to try it for themselves here’s the code for the block demo'd in the recording:

A snippet that can be pasted into the console that registers a block with a template and configurable `templateLock`.

// Template lock testing block
( ( {
  blocks: { registerBlockType },
  blockEditor: {
    InspectorControls,
    useInnerBlocksProps,
  },
  components: { PanelBody, SelectControl },
  element: { createElement: el, Fragment },
} ) => {
  registerBlockType( 'test/template-lock', {
    title: 'Test Template Lock',
    edit: Edit,
    attributes: { templateLock: { default: 'all' }},
    save: () => null,
  } );
  function Edit({attributes: { templateLock }, clientId, setAttributes}) {
    return (
      el( Fragment, null,
        el( InspectorControls, null,
          el( PanelBody, {title: 'Template Lock'},
            el( SelectControl, {
              onChange: v => setAttributes({templateLock: v}),
              value: templateLock,
              options: [
                {value: 'all', label: 'All'},
                {value: 'insert', label: 'Insert'},
                {value: 'contentOnly', label: 'Content Only'},
                {value: false, label: 'None (false)'},
              ]
            }),
          )
        ),
        el( 'div', useInnerBlocksProps({}, {
          templateLock: templateLock === 'false' ? false : templateLock,
          template: [
            ['core/paragraph', {content:'How do I lock thee?'}],
            ['core/columns', {}, [
              ['core/column', {}, [
                ['core/paragraph', {content:'Let me count the ways.'}]
              ]],
              ['core/column', {}, [
                ['core/paragraph', {content:'“all”, “insert”, “contentOnly”, false'}]
              ]]
            ]],
            ['core/separator', { className:'is-style-wide'}],
            [
              'core/social-links', {
                layout:{type:'flex',justifyContent:'center'},
                size:'large',
              }, [
                ['core/social-link', {service:'wordpress', url: '❤️'}]
              ]],
          ]
        }))
      )
    );
  };
} )( wp );

From what I gather, templateLock was designed for the scope of inner block placement. That is, insertion, movement, or deletion and all pertains to just that. This new level of locking doesn't fit cleanly into that scope.

[noisysocks]

Aha, thanks :)

Curious what @WordPress/gutenberg-core thinks. If we're going to clarify this API best to do so now before it's too late.

[talldan]

That's a great point about it being a stronger level of locking. That's nuance that's easily missed.

Around the idea of separate properties, a question is would you ever have templateLock set to false along with editable: 'content'? Being able to set templateLock to its own value probably contradicts the purpose of contentOnly, so I think that's a reasonable argument for making it part of templateLock.

[oandregal]

For reference, the names considered/used at some point:

• content: original proposal
• noContent: name after this conversation
• contentOnly: name after testing

In essence, the thing I struggle the most with any of the names proposed so far is how it fits with the other values:

• while insert and all communicate what they lock, the new name communicates what it does not lock
• the new name is not composable or related to the existing values: it operates at a higher level than all and, at the same time, it allows the users to do more things than all (edit)

I don't think I have any suggestion, but wanted to share this context.

[talldan]

Thanks for sharing the history @oandregal.

it allows the users to do more things than all (edit)

I think you can still edit with 'all', so 'contentOnly' seems purely a higher level of locking.

Given this is now documented, it may not be the best idea to change it.

[mtias]

The naming problem is just a symptom of the fact this isn't really about template locking, or better put, it's combining a couple features that we should aim to untangle a bit:

• Controlled children.
• Template locking (disabling movers, appenders, removals).

Controlled children is about being able to select the parent and see the children in the sidebar, or selecting the children and still seeing the parent as a unit. This is a cool feature but is actually not dependant on template locking. For example, the new navigation block is making use of a very similar view without locking the contents.

You could combine controlled children + template locking to get this "patterns feel like a single block where you only modify content". The original work aimed at making it simple for a pattern author to make this combination with a single flag.

[talldan]

Closing as this is impossible to change now.