Anchor support for dynamic blocks

For some core Gutenberg blocks, like heading, you can set an HTML anchor in the Advanced section of the block sidebar. The value defines the id attribute of the element, to make it possible to create a link that jumps directly to that element.

All you have to do during block registration is add the following code:

supports: { anchor: true, },

Easy, isnt it? Yes, except we have a dynamic block. In that case, a PHP function does the rendering of the block markup for the frontend. For dynamic blocks, the above code snippet creates the input field, but we cannot access its value in the rendering function, because it is not stored as an attribute.

I found a not-so-nice workaround for that.

Continue reading "Anchor support for dynamic blocks"

wp_kses filters block markup for non-admin users

WordPress only allows admin users to save unfiltered HTML in the editor and removes elements for all other user roles that are not specified in a set of allowed elements and attributes. Disallowed elements and attributes, for example, are the svg element and the sizes attribute for the img element. That is a problem when markup generated by a block contains those elements or attributes and leads to interesting results.

Continue reading "wp_kses filters block markup for non-admin users"

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 WordPress.org, 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"

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"