Speaker Name
Speaker Description—Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus luctus urna sed urna ultricies ac tempor dui sagittis.
```
Now, let’s apply the `"templateLock": "contentOnly"` attribute to the block markup
of the Group block. You only need to modify the attribute object. The rest of the
block markup should remain the same.
```language-markup
```
To follow along, open a WordPress Playground instance running WordPress 6.7. [Here’s a handy link](https://playground.wordpress.net/?php=8.0&wp=beta&networking=no&language=&multisite=no).
1. Navigate to a new page.
2. Open the Code Editor, and copy and paste the original block markup above.
3. Add the `"templateLock": "contentOnly"` attribute to the Group block.
4. Switch back to the Visual Editor.
With those steps completed, you should see something like this.
If you compare the block layout in content-only mode to the default editing experience,
you will quickly notice a few things:
1. The List View is simplified and only displays the container (Group) and any internal
blocks with editable content.
2. The Settings Sidebar no longer displays block settings or styles, only the block
style variations that are available to the container Group block.
3. There is a new Content panel in the Settings Sidebar displaying the editable content
blocks within the container.
4. The icons in the Social Icons block are no longer editable. (Note this for later
in the article)
## Why support this editing mode?
Content-only editing is a powerful tool for creating curated and simplified user
experiences. To make this feature effective, blocks must be designed to support
it. For instance, as noted earlier, the Social Icons block currently does not function
in this mode.
While future WordPress updates will address full support across core blocks, most
sites include at least one custom block. For block developers, ensuring compatibility
with content-only editing is essential. Prior to WordPress 6.7, enabling this feature
in custom blocks required an experimental property in `block.json` called `__experimentalRole`.
Now that the `role` property [has been stabilized](https://github.com/WordPress/gutenberg/pull/65484),
adding support is generally straightforward.
You still might wonder why content-only editing is so important, especially since
it has remained relatively niche until now. The answer lies in the new [Write mode](https://make.wordpress.org/core/2024/10/09/whats-new-in-gutenberg-15-9-31-may-2/#new-write-design-modes)
in Gutenberg and the increased emphasis on content-only editing outlined in the
[Design Editor Overview](https://github.com/WordPress/gutenberg/issues/66499) issue
on GitHub.
These developments underline the future importance of content-only editing and its
role in creating a simpler, more controlled editing experience within WordPress’s
broader design tools. It’s time to get your blocks ready.
## How to add content-only support to a block
Although I initially planned to create an example block plugin for this article,
let’s instead examine the Social Link block in WordPress since it’s currently disabled
in content-only mode as of WordPress 6.7. You can view the [source code](https://github.com/WordPress/gutenberg/tree/wp/6.7/packages/block-library/src/social-link)
in the Gutenberg plugin.
The Social Link block is a child of the Social Icons (Social Links) block, which
displays a row or column of icons that link to social profiles or websites. In many
cases, you might want users to be able to modify link URLs in content-only mode.
This is especially useful when a block layout is provided as a pattern that can
be used in different contexts, such as the speaker profile block design shown earlier.
Here’s a quick demonstration of how these blocks work. Notice how toggling **Show
text** displays a label for each icon.
For the remainder of this article, I will refer to the blocks by their technical
names as used in the WordPress source code and block markup: `wp:social-links` and`
wp:social-link`. Just remember that the Social Links block appears as the Social
Icons block in the Editor, while the Social Link block is represented by the individual
platform names such as WordPress, Facebook, LinkedIn, Link, Mail, etc.
So, let’s assume that the Social Link block is your custom block that needs content-
only editing support. How do you go about implementing this?
### Updating block.json
The first step is to update the [`block.json`](https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/social-link/block.json)
file of the Social Link block by adding the `"role": "content"` property to each
attribute that should be editable when `"templateLock": "contentOnly"` is set.
For this example, the `url` and `label` attributes should be available. The `url`
attribute holds the link for the social icon, while the `label` attribute represents
an optional text label for the icon when **Show text** is enabled in the parent
Social Links block.
The updated attributes section of the `block.json` file should look like this:
```language-json
{
"$schema": "https://schemas.wp.org/trunk/block.json",
"apiVersion": 3,
"name": "core/social-link",
"title": "Social Icon",
"category": "widgets",
"parent": [ "core/social-links" ],
"description": "Display an icon linking to a social profile or site.",
"textdomain": "default",
"attributes": {
"url": {
"type": "string",
"role": "content"
},
"service": {
"type": "string"
},
"label": {
"type": "string",
"role": "content"
},
"rel": {
"type": "string"
}
},
...
```
If you are adding content-only editing to your own block and need to support older
versions of WordPress, use `__experimentalRole` instead of `role` until you are
ready to set the minimum WordPress version to 6.7. The only downside to this approach
is a minor deprecation warning in the console.
With these changes, URL editing for social icons will be enabled automatically.
This works because the `url` attribute is managed using the [`