Adding Custom HTML Attributes With the Block Attributes Plugin

Earlier this week, websevendev released its fourth WordPress plugin to the official directory named Block Attributes. The extension allows end-users to add any HTML attribute to nearly any block.

One of the problems with the WordPress editor is that it can be a bit fussy about customizing HTML. Blocks are built on a set of standards, and the markup is supposed to meet those expectations. If something does not fit, users see an invalid markup warning.

However, there are times when users need to drop in a custom HTML attribute for various reasons. For example, I sometimes need to add a custom data- attribute for working with a bit of JavaScript. Since I know my way around code well enough, I typically write out the HTML in those situations via the Custom HTML block. But, that does not make sense when minor attribute additions are called for.

WordPress currently allows users to add classes and IDs (called an “HTML anchor” in the admin) to almost every block. It does not allow for direct input of the dozens of other possible attributes that HTML supports. The use cases for the average user are few and far between.

For those scenarios where some users could use the extra feature, the Block Attributes plugin is handy.

The plugin is straightforward to use. It adds a new field named “Additional attributes” under the Advanced tab of every block. Users can add the attribute name and click the “Add” button. From there, it creates a new field for adding the attribute value.

Adding a custom attribute for JavaScript handling to a Button block in the WordPress editor via the Block Attributes plugin panel.
Adding an onclick attribute to a Button block.

The plugin also supports multiple attributes. Once you add one, you simply use the same input field to create more.

For my first test drive, I added a simple onclick attribute with a value of myFunction(). Then, I hopped over to my theme and created that function via JavaScript to output a simple message in the console. Everything looked good under the hood, and it worked.

Most of the use cases I have in mind are for integrating with JavaScript, and this was a simple example of what is possible. There are far more complex things a developer could do with such a feature. That is reason enough to keep this plugin in the toolbox — sometimes you need a wrench instead of a hammer.

I could also see Block Attributes being used for adding ARIA attributes in other situations where it might aid accessibility.

Users could add custom styles to a specific block via a style attribute with the plugin. However, unless this is a simple one-off, I would recommend against it. For more advanced use cases, Blocks CSS is a far more suitable plugin. It has a built-in syntax highlighter. Plus, a textarea is friendlier than a one-line text input box.

The only downside to Block Attributes I have seen is upon deactivation. You will see the dreaded “this block contains unexpected or invalid content” message in the editor if you have added any custom attributes. The editor has managed to resolve any issues I have run into with the core blocks.

Side-by-side view of the block resolution popup modal in the WordPress editor.
Resolving block warning after deactivating plugin.

Deactivating the plugin should not affect the front-end output. Because the custom attributes are a part of the HTML markup, they will still be there. The error message should only show in the editor.