Category: WordPress snippets

If a PHP script runs, the page loads typically as long as the script needs to finish (or throws an error). That is fine for many cases, but if the script needs to process complex and/or many tasks, that take a few minutes or even hours, it would be nice to put that tasks in the background. This post shows you how to create background processes in WordPress.

Continue reading "Creating background processes in WordPress"

I am currently working on a side project, which needs to create a copy of a WordPress installation. Because I do not know the server environment where it is used by the users, I can neither expect that I can run Linux commands, nor that there is a long PHP max_execution_time.

So copying needs to be done via PHP and also work when, for example, the maximum execution time for scripts is 30 seconds. 30 seconds are not much for a script that should copy many files. Creating a list of the files and looping it without copying files can already take longer.

Continue reading "Copying directory with many files in multiple steps via PHP"

In a project, I wanted to use the sizes attribute for the images in a slider block. But because the slider is used in different widths, the value of the sizes attribute needs to change depending on the position of the slider block.

Continue reading "Set block attributes depending on the block position"

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,
},
Code language: JavaScript (javascript)

Easy, isn’t 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"

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"

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' },
    },
],
Code language: JavaScript (javascript)

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.

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"

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"

It is possible to disable the publish/update button in Gutenberg. With that, we could, for example, force the user to add data to a custom block that adds metadata to a custom post type.

Continue reading "Conditionally prevent publishing/updating in Gutenberg"

The document sidebar of the block editor contains various panels, for example, one for the featured image and, for posts, one for tags. If specific panels are not used, it could be useful to hide them, to make the sidebar clearer. This post shows you how to do this.

Read more