Gutenberg 11.6 was released this week with a new API for managing lock control at the block-type level. When defining a block, developers can now use the lock attribute to designate whether a block can be moved or removed. The PR introduces parts of the locking support mechanisms proposed by Matias Ventura in a separate issue earlier this year.

Ventura explained that while the editor already has template locking support to prevent inserting or moving blocks (i.e. for custom post type templates), it doesn’t yet offer much granular control or a UI for the different locking states. He identified block themes as an important use case for establishing a new block-level API for representing lock status. Block themes may necessitate the ability to lock down key elements, such as preventing the removal of the post-content for a single post template. If you have ever played around with the template editor then you have likely discovered how easy it is to remove important elements by accident.

“Another use case that we’re building for is having a Checkout Block with different blocks that act as fundamental steps,” WooCommerce and Gutenberg engineer Seghir Nadir said. “We don’t want people to delete or move those steps since they’re fundamental and their order is also important, but we want to allow people to select them, access settings, and insert blocks in between them.”

During this week’s core editor chat, Paal Joachim Romdahl highlighted the need for a locking mechanism for Reusable blocks.

“At the moment it is too easy to make an accidental change to a Reusable block,” Romdahl said. “I worry that only having the hover overlay and the initial click [to] select the parent Reusable block is just not good enough, that we soon should get a lock mechanism in place. There is a lot of feedback from users who have accidentally deleted the inner contents of the blocks and wondered what happened.”

Romdahl has created several issues about to the possibility of adding a locking mechanism to the inline toolbar for reusable blocks, where users would need to unlock to edit the contents.

Now that the foundational infrastructure is in place for managing lock control at the block-type level, contributors can begin building a UI to control it, as outlined in the Locking and TemplateLocking issue. Ventura said future iterations should include a UI that indicates which blocks are user-editable and also display block status in the list view and block inspector.