Make custom block full-width in Gutenberg by default

By default, all blocks are inserted with the same width in the Gutenberg editor. Depending on the block and theme support, you get the option to set blocks to wide or full width, to let the block go beyond the normal content width on the website.

Now I had the case that a custom block should be displayed full-width by default, without the option to change that. On the frontend, I just modified the styling, but in the editor, there are a few more adjustments necessary because the block controls for a full-width block are above the block, not on the left side.

Continue reading Make custom block full-width in Gutenberg by default

Create block variations in Gutenberg

WordPress 5.4 introduced the Block Variations API. The API can be used to create variations of blocks, which get listed as own blocks in the block inserter. An example from core are the social media buttons, that are all variations of the social link block.

A variation can predefine attributes of the block, in case of the social link block, for example, each variation defines the service attribute with the identifier of the specific social network.

Like shown in the dev post on, variations are created like that:

variations: [ { name: 'wordpress', isDefault: true, title: __( 'WordPress' ), description: __( 'Code is poetry!' ), icon: WordPressIcon, attributes: { service: 'wordpress' }, }, { name: 'google', title: __( 'Google' ), icon: GoogleIcon, attributes: { service: 'google' }, }, { name: 'twitter', title: __( 'Twitter' ), icon: TwitterIcon, attributes: { service: 'twitter' }, }, ],

variations is a key in the object that is passed to registerBlockType(), like title, edit, attributes, et cetera. Each variation gets a name and a title, which is displayed to the user.

Additionally, an icon can be set, and via attributes we can set values for one or more block attributes. isDefault specifies with variation should be the default. Moreover, the innerBlocks key can be used to fill an InnerBlocks component of the block with a set of blocks. That is used, for example, in the columns block, to create the different predefined column layouts.

With scope, we can define in which area the variation should be available, but I did not quite understand what the options block and inserter do. Maybe block means that the variation can only be used as part of another block. When leaving that option, both areas are set.

Currently, the variations do not appear as suggestions when using the / command to add a new block. The pull request for that is merged, but part of Gutenberg 8.5, so will not be part of WordPress 5.5, which contains new Gutenberg releases up to 8.4.

Change block edit wrapper attributes

In Gutenberg, the markup from the edit function is wrapped in a few other elements. The outer wrapper of each block has the wp-block class and a data-block attribute that contains the name of the block with its namespace – core/group for the group block, for example.

We can change the attributes of that wrapper, so we could add class names depending on the selected/changed block options, what could make the styling of blocks in the backend easier.

Continue reading Change block edit wrapper attributes

Create Gutenberg field like the one for post tags

For a project I needed the feature to link posts of a custom post type with posts of another custom post type. I did not know which Gutenberg component would be the best match for that, but then the tags field for post tags seemed like a good fit: the user types something and gets suggestions which he can add to a selection.

The FormTokenField can be used to create that behavior, all possible options can be found in the linked readme. With that, I had my component of choice, just with custom post type posts instead of tags.

Continue reading Create Gutenberg field like the one for post tags

Block plugin updates and the sometimes delayed effect on the frontend

I am a big fan of Gutenberg. But a few weeks back I had multiple content pages that got destroyed in the frontend after updating, without changing much.

The reason: a block plugin had an update earlier which changes block markup, and with that, a few of my custom CSS rules did not apply any longer. Well, that could also happen with plugins that use shortcodes, but…

Continue reading Block plugin updates and the sometimes delayed effect on the frontend

Get correct metadata after post update in block editor

Sometimes it is necessary to do something after a post was saved. When using the old hooks like save_post and post_updated, the result is not as expected with the block editor: the metadata values are the old ones from before saving.

The rest_after_insert_{$this->post_type} action hook comes to the rescue ({$this->post_type} needs to be replaced with the post type, for example, post or page). It gets the post object as the first param and when fetching data via get_post_meta(), we get the correct data.

Define block templates for new pages, posts, and custom post types

WordPress’ block editor comes with the feature of block templates. This allows us to defined a set of blocks that will be present in the content of new pages, posts and/or custom post types. This post shows you how to use that functionality and how to use reusable blocks in templates.

Continue reading Define block templates for new pages, posts, and custom post types