Gutenberg 11.6 introduces new API for interlocking blocks – WP Tavern
Gutenberg 11.6 released this week with a new API to handle lock checking 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 deleted. The PR features parts of the locking support mechanisms offered by Matias Ventura in a separate issue earlier this year.
Ventura explained that while the publisher already supports template locking to prevent inserting or moving blocks (i.e. for custom post type templates), it does not offer still a lot of granular or user interface control for the various lock states. He identified block themes as an important use case to establish a new block-level API to represent
lock status. Block themes might require the ability to lock key things, such as preventing the removal of post content for a single post template. If you’ve ever played with the template editor, you’ve probably discovered how easy it is to delete important items by accident.
“Another use case that we are building for is to have a payment block with different blocks that act as fundamental steps,” said WooCommerce and Gutenberg engineer Seghir Nadir. “We don’t want people to delete or move these steps because they are fundamental and their order is also important, but we want to allow people to select them, access settings and insert blocks between them.”
During this week’s lead editor chat, Paal Joachim Romdahl highlighted the need for a locking mechanism for reusable blocks.
“For the moment, it is too easy to accidentally modify a reusable block”, said Romdahl. “I’m afraid that only having the hover overlay and the initial click [to] select the reusable parent block just isn’t good enough, that we should be putting in place a locking mechanism soon. There is a lot of feedback from users who accidentally deleted the internal content of the blocks and wondered what happened.
Romdahl created several issues regarding the ability to add a locking mechanism to the online toolbar for reusable blocks, where users would need to unlock to edit content.
Now that the basic infrastructure is in place to handle lock control at the block type level, contributors can start building a user interface to control it, as discussed in the Locking and Locking Models issue. Ventura said future iterations should include a user interface that indicates which blocks are user editable and also show the status of blocks in the List View and Block Inspector.