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"

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 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"

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.