An introduction to developing WordPress blocks

Block supports and styles

One of the benefits of blocks is the ability to control the block’s appearance on a per block level.

To do this, you can use something called block supports, as well as define the block’s styles.

Let’s take a look at how this works.

Block supports

Block Supports is the API that allows a block to declare support for certain common features.

For example, most blocks support the ability to set their alignment, background, and text color, typography, and more.

You can define support for these common features in the block metadata, and once enabled, the block will have those abilities enabled in the Editor.

Adding Block Supports

To add support for a feature, you define it in the supports property of the block’s metadata in the block.json file.

Open the block.json file in the src directory, and update the supports property to include the align support.

    "supports": {
        "html": false,
        "align": true
    },

Once the build process is complete, create a post, and add the block to the post. You’ll see that the block now has the ability to set its alignment.

As you can see, simply by enabling the alignment support, the block now has the ability to set its alignment, without any additional code.

Enabling any of the available block supports is as simple as adding them to the supports property in the block.json file, and it gives your users a wealth of options to customize the block’s appearance.

Block styles

There are some cases however where you would prefer to define the block’s styles yourself.

In the Copyright Date block requirements defined in the Scaffolding a new block lesson, we required the block to always have a specific border and border color.

This is where the style.scss and editor.scss files come in. These files allow you to set up specific block styles, and then those styles are applied in the editor and on the front end.

These two files are Syntactically Awesome Stylesheets, also known as Sass files. Just like the JSX format used to create blocks converts into regular JavaScript during the build step, Sass files convert into regular CSS. These files follow the new SCSS syntax, which you can learn more about on the Sass website. Fortunately, you can also just write plain CSS in Sass files, and that will work as well.

In the Scaffolding a new block lesson, you learned what those two files are used for:

  • style.scss: the styles in this file are applied to the block in the front end and in the editor
  • editor.scss: the styles in this file are applied to the block in the editor only

If you need a specific style to be applied to the block in the front end and in the editor, you would add the styles to the style.scss file.

Open the style.scss file in the src directory, and you’ll see the following scaffolded code:

.wp-block-create-block-copyright-date-block {
    background-color: #21759b;
    color: #fff;
    padding: 2px;
}

You may have noticed that this style is not being applied to the current block. This is because the class name applied to the parent container of the block via useBlockProps is automatically generated based on the block’s name.

In the block.json file the name of the block is copyright-date/copyright-date-block, so the class name is generated as wp-block-copyright-date-copyright-date-block.

The class name you see being targeted in the style.scss file is based on the original name of the block, so you need to change it to match the class name that is being generated.

At the same time, you can also add the border and border color to the block.

.wp-block-copyright-date-copyright-date-block {
    border: 1px solid #111111;
    padding: 5px;
}

Because you want the border to appear all the time, you don’t need to define any specific editor styles. This means you can delete the editor.scss file.

You can also delete the editorStyle property in the block.json file.

And the importing of the editor.scss file in the edit.js file.

Doing this might break your development server, so you may need to restart it.

Once the build process has been run, create a post, and add the block to the post.

You’ll see that the block now has the border and border color that you defined in the style.scss file. When you preview the block, the style is also applied on the front end.

Conclusion

When you’re developing your blocks, it’s useful to think about what appearance elements you want users to be able to edit, vs what should always apply to the block. Then you can either add the relevant support or hard code any specific styles into the relevant style file.

For more information on Block Supports, check out the detailed Supports page, in the Block Editor Handbook.

This is a preview lesson

Register or sign in to take this lesson.

Suggestions

Found a typo, grammar error or outdated screenshot? Contact us.