Dynamic Template Parts brings unparalleled flexibility to your WordPress site. Want a unique header for a specific post or a custom footer for a landing page? Now you can do it all directly in the block editor, without the hassle of creating multiple templates or touching theme files.

Why You’ll Love Dynamic Template Parts

• Simplified Template Management
  No more juggling dozens of templates—use one and swap parts dynamically.

• Customisation Without Code
  Select and preview Template Parts in real time using an intuitive interface.

• Versatile Design Options
  Works seamlessly with posts, pages, and custom post types for tailored layouts.

• Full Site Editing Integration
  Built to enhance the native WordPress Full Site Editor experience.

See It in Action

Want to see how easy it is to use? Watch the demo video to learn more:
Watch the Demo

Or take a look at the product page here:
Dynamic Template Parts Product Page

Or skip all that and just download it directly to see what all the fuss is about:
Dynamic Template Parts on WordPress.org

Dynamic Template Parts is here to save you time, simplify your workflow, and unlock endless customisation options. Whether you’re a developer or a site owner, this plugin is the design tool you didn’t know you needed.

Sidebars serve as quick-access control panels within the block editor, perfect for custom settings and content controls.

You’ll see how to set up each one with @wordpress/create-block or in some cases @wordpress/scripts, and we will add unique settings and functionality to each sidebar.

If you are completely new to WordPress development environments and block creation, please read the getting started with WordPress development guide first.

What are WordPress Sidebars?

In the WordPress block editor, sidebars are panels on the right-hand side of the screen that offer quick access to settings and configuration options. These sidebars can be customised to provide controls specific to your content and enhance the editing experience.

There are several types of sidebars you can create:

1. Block Sidebar (Inspector Controls): Ideal for configuring individual block settings, such as adding specific styling options, or other customisation for specific blocks in a post or page.

2. Block Filters for All Blocks: By using block filters, you can add controls to all blocks (even core blocks). This allows for consistent settings across different block types without modifying each block individually.

3. Post Sidebar: Provides options applicable to the entire post, such as a control for post meta.

4. Custom Plugin Sidebar: Acts as a dedicated settings panel, usually for broader configurations that need to be accessed across different content types or pages.

5. Full Site Editor (FSE) Sidebar: Ideal for site-wide settings and controls when working within the FSE, allowing global options that apply to all pages and posts.

In this article we will take a look at how to implement each type of sidebar and controls.

1. Block-Level Sidebar: Toggle Block Visibility

Blocks can render pretty much any type of content. When you select a block the block sidebar usually becomes visible. It is here we can add controls so that we can customise our blocks layout, style or behaviour.

To showcase our block sidebar, we’ll create a custom block with a visibility toggle. When disabled, this toggle will prevent the block from rendering on the front end.

1.1: Setting Up the Block Attributes

First, we’ll use @wordpress/create-block to scaffold a new block plugin. Open your terminal and run the following command:

npx @wordpress/create-block block-visibility-toggle

This command will generate all the necessary files for a basic block plugin called block-visibility-toggle.

Next, open the generated src/block.json file in your code editor. We’ll need to add an attribute to control the visibility of the block. To do this add the following code inside the generated "attributes" object.

"attributes": {
    "isVisible": {
        "type": "boolean",
        "default": true
    }
}

Your block.json file should now look like the following screenshot.

1.2: Building the Sidebar Toggle

Next, we’ll create a toggle control in the block’s sidebar to allow users to show or hide the block. Open the src/edit.js file and modify it as follows:

import { InspectorControls, useBlockProps } from '@wordpress/block-editor';
import { ToggleControl, PanelBody } from '@wordpress/components';
import { __ } from '@wordpress/i18n';

export default function Edit( { attributes, setAttributes } ) {
    const { isVisible } = attributes;

    return (
        <>
            <InspectorControls>
                <PanelBody title={ __( 'Block Settings', 'block-visibility-toggle' ) }>
                    <ToggleControl
                        label={ __( 'Display Block', 'block-visibility-toggle' ) }
                        checked={ isVisible }
                        onChange={ ( value ) => setAttributes( { isVisible: value } ) }
                    />
                </PanelBody>
            </InspectorControls>
            <div { ...useBlockProps() }>
                { isVisible ?
                    <p>{ __( 'Your content here.', 'block-visibility-toggle' ) }</p>
                :
                    <p>{ __( 'Your block will be hidden.', 'block-visibility-toggle' ) }</p>
                }
            </div>
        </>
    );
}

1.2.1: Display Controls to the Advanced Section

If you prefer, you can place the visibility toggle under the “Advanced” section of the block sidebar.

To do this, replace InspectorControls with InspectorAdvancedControls in your edit.js file. You can also remove the PanelBody too, as the Advanced section acts as its own Panel.

import { InspectorAdvancedControls, useBlockProps } from '@wordpress/block-editor';
import { ToggleControl } from '@wordpress/components';
import { __ } from '@wordpress/i18n';

export default function Edit( { attributes, setAttributes } ) {
    const { isVisible } = attributes;

    return (
        <>
            <InspectorAdvancedControls>
                <ToggleControl
                    label={ __( 'Display Block', 'block-visibility-toggle' ) }
                    checked={ isVisible }
                    onChange={ ( value ) => setAttributes( { isVisible: value } ) }
                />
            </InspectorAdvancedControls>
            <div { ...useBlockProps() }>
                { isVisible ?
                    <p>{ __( 'Your content here.', 'block-visibility-toggle' ) }</p>
                :
                    <p>{ __( 'Your block will be hidden.', 'block-visibility-toggle' ) }</p>
                }
            </div>
        </>
    );
}

1.3: Altering the Save Function to Hide the Block

Modify the save function in src/save.js to check the isVisible attribute. Open src/save.js and update it as follows:

import { useBlockProps } from '@wordpress/block-editor';
import { __ } from '@wordpress/i18n';

export default function save( { attributes } ) {
    const { isVisible } = attributes;

    if ( ! isVisible ) {
        // If the block is set to not visible, return null to render nothing.
        return null;
    }

    return (
        <div { ...useBlockProps.save() }>
            <p>{ __( 'Your content here.', 'block-visibility-toggle' ) }</p>
        </div>
    );
}

By returning null when isVisible is false, the block will not output any HTML on the front end, effectively hiding it.

1.4: Using the Sidebar

Remember to run npm run build in your block directory and to activate the block.

Once you have done this, you can insert the custom block you created by typing / and searching for Block Visibility Toggle.

After you have inserted the block, click on it to reveal the “Block” section of the “Post” sidebar. Here you will see the new “Display Block” toggle.

Do not toggle it just yet, first check that the block displays as expected on the front end.

Now toggle the “Display Block” toggle in the backend, and save your post.

If all worked as expected, you should no longer be able to see the block on the front end of the site.

As mentioned in section 1.2.1 you can display controls in the Advanced section of the sidebar with InspectorAdvancedControls. That should look a little like the following screenshot.

2. Using Block Filters: Adding Block Visibility Toggle to All Blocks

Sometimes you cannot alter the markup of a block. Perhaps it is a WordPress Core block that you wish to add additional controls to, or one provided by a plugin, or perhaps you just want to register one control that can be used on several blocks (gotta keep it DRY).

We will showcase this by using block filters to inject the toggle control into the sidebar of every block (realistically you would probably restrict which blocks use it).

2.1: Setting Up the Plugin

Since we need to create a plugin that modifies existing blocks, @wordpress/create-block might not be the most suitable tool. Instead, we’ll manually create a plugin and use @wordpress/scripts (also known as wp-scripts) to handle the build process.

Create a new folder in your wp-content/plugins directory called global-block-visibility-toggle. Inside this folder, create a PHP file named global-block-visibility-toggle.php and add the following plugin header:

<?php
/**
 * Plugin Name: Global Block Visibility Toggle
 * Description: Adds a visibility toggle to all blocks using a block filter.
 * Version: 1.0.0
 * Author: Your Name
 * Text Domain: global-block-visibility-toggle
 */

2.2: Setting Up the Development Environment with wp-scripts

We’ll use @wordpress/scripts to simplify our build process. This package provides a pre-configured build setup for WordPress development, allowing us to write modern JavaScript without manually configuring tools like webpack and Babel.

wp-scripts gives you a build process very similar to the create-block script. To do this we will need to run a few commands, if you need to re-familiarise yourself with some of the concepts, give the WordPress development guide a read.

2.2.1: Initialise package.json

Make sure you are in the plugins directory. Open your terminal and navigate to the plugin directory:

cd global-block-visibility-toggle

Initialize a new package.json file by running:

npm init -y

This will create a basic package.json file in your plugin directory.

2.2.2: Install @wordpress/scripts

Install @wordpress/scripts as a development dependency:

npm install @wordpress/scripts --save-dev

2.2.3: Update package.json Scripts

In your package.json file, add the following scripts:

"scripts": {
    "build": "wp-scripts build",
    "start": "wp-scripts start",
    "format": "wp-scripts format",
    "lint:css": "wp-scripts lint-style",
    "lint:js": "wp-scripts lint-js",
    "lint:md:docs": "wp-scripts lint-md-docs"
},

To add in the description and to save some time, you can copy the below to your `package.json file.

{
  "name": "global-block-visibility-toggle",
  "version": "1.0.0",
  "description": "Adds a visibility toggle to all blocks using a block filter.",
  "main": "index.js",
  "scripts": {
    "build": "wp-scripts build",
    "start": "wp-scripts start",
    "format": "wp-scripts format",
    "lint:css": "wp-scripts lint-style",
    "lint:js": "wp-scripts lint-js",
    "lint:md:docs": "wp-scripts lint-md-docs"
  },
  "author": "Your Name",
  "license": "GPL-2.0-or-later",
  "devDependencies": {
    "@wordpress/scripts": "^24.0.0"
  }
}

2.2.4: Create the src Directory and index.js File

Create a src directory inside your plugin folder:

mkdir src

Inside the src directory, create a file named index.js. This is where we’ll write our JavaScript code to add the visibility toggle to all blocks.

2.3: Registering the Block Filter

In src/index.js, add the following code:

import { addFilter } from '@wordpress/hooks';
import { InspectorControls } from '@wordpress/block-editor';
import { PanelBody, ToggleControl } from '@wordpress/components';
import { __ } from '@wordpress/i18n';

/**
 * Add the 'isVisible' attribute to save the visibility state.
 *
 * @param {Object} settings Original block settings.
 * @returns {Object} Modified block settings with new attribute.
 */
function addVisibilityAttribute( settings ) {
    settings.attributes = {
        ...settings.attributes,
        isVisible: {
            type: 'boolean',
            default: true,
        },
    };

    return settings;
}

addFilter(
    'blocks.registerBlockType',
    'gbvt/add-visibility-attribute',
    addVisibilityAttribute
);

/**
 * Wraps the block's edit component to include the visibility toggle control in advanced settings.
 *
 * @param {Function} BlockEdit The original block edit component.
 * @returns {Function} Wrapped component with visibility toggle control.
 */
const addVisibilityToggleControl = ( BlockEdit ) => ( props ) => {
    const { attributes, setAttributes } = props;
    const { isVisible } = attributes;

    return (
        <>
            <BlockEdit { ...props } />
            <InspectorControls>
                <PanelBody title={ __( 'Block Settings', 'block-visibility-toggle' ) }>
                    <ToggleControl
                        label={ __( 'Display Block', 'global-block-visibility-toggle' ) }
                        checked={ isVisible }
                        onChange={ ( value ) => setAttributes( { isVisible: value } ) }
                        help={ __( 'Toggle block visibility on the front end.', 'global-block-visibility-toggle' ) }
                    />
                </PanelBody>
            </InspectorControls>
        </>
    );
};

addFilter(
    'editor.BlockEdit',
    'gbvt/add-visibility-toggle-control',
    addVisibilityToggleControl
);

2.4: Applying the Visibility on the Front End

Now, we need to ensure that blocks with isVisible set to false do not render on the front end. We’ll use a PHP filter to modify the rendered content.

In your global-block-visibility-toggle.php file, add the following code:

<?php
/**
 * Plugin Name: Global Block Visibility Toggle
 * Description: Adds a visibility toggle to all blocks using a block filter.
 * Version: 1.0.0
 * Author: Your Name
 * Text Domain: global-block-visibility-toggle
 */

/**
 * Enqueue block editor assets.
 */
function gbvt_enqueue_block_editor_assets() {
    wp_enqueue_script(
        'gbvt-editor-script',
        plugins_url( 'build/index.js', __FILE__ ),
        [ 'wp-blocks', 'wp-dom-ready', 'wp-edit-post', 'wp-hooks' ],
        filemtime( plugin_dir_path( __FILE__ ) . 'build/index.js' )
    );
}
add_action( 'enqueue_block_editor_assets', 'gbvt_enqueue_block_editor_assets' );

/**
 * Filter block content to control visibility on the front end.
 *
 * @param string $block_content The block content.
 * @param array  $block         The block settings.
 * @return string Modified block content.
 */
function gbvt_filter_block_visibility( $block_content, $block ) {
    if ( isset( $block['attrs']['isVisible'] ) && ! $block['attrs']['isVisible'] ) {
        return ''; // Do not render the block
    }
    return $block_content;
}
add_filter( 'render_block', 'gbvt_filter_block_visibility', 10, 2 );

2.5: Building and Activating the Plugin

We need to build our JavaScript code into a build/index.js file that can be enqueued.

With @wordpress/scripts, we can use the following command to build our JavaScript files:

npm run build

This will compile src/index.js and output the result to build/index.js.

Alternatively, if you want to watch for changes and rebuild automatically during development, you can use:

npm run start

This command runs in watch mode, rebuilding the code whenever you save changes.

2.6: Using the Sidebar

Remember after you have ran npm run build that you need to activate the plugin.

Select any block (in this case I’m selecting the paragraph block) and note that the Display Block toggle is now visible.

Toggle this so that it no longer displays, and save the post.

When you view the post on the front end, that block (the paragraph block) is no longer visible.

3. Post-Level Sidebar: Toggle Post Content Visibility

If you would like to add a control that impacts the entire post, you can add controls to the post sidebar. In this type of sidebar it might make sense for the controls to alter post meta data.

To showcase a post-level sidebar that allows you to toggle the visibility of the post content. If disabled, the content will not display on the front end, and a custom message will be shown instead.

3.1: Setting Up the Plugin

Create a new plugin folder called post-content-visibility in your WordPress wp-content/plugins directory.

Inside this folder, create a src folder for your JavaScript code and a post-content-visibility.php file for the plugin’s PHP code.

As per the last example we are going to use wp-scripts. We will take a bit of a shortcut this time, by setting up the package.json file and then running our setup command.

In the post-content-visibility folder, initialise your package with wp-scripts creating the following package.json file in the root of the plugin.

{
    "name": "post-content-visibility",
    "version": "1.0.0",
    "description": "Toggle the visibility of post content from the editor sidebar.",
    "main": "index.js",
    "scripts": {
        "build": "wp-scripts build",
        "start": "wp-scripts start"
    },
    "keywords": [],
    "author": "Your Name",
    "license": "ISC",
    "dependencies": {
        "@wordpress/scripts": "^25.0.0"
    }
}

Now run npm install from inside the post-content-visibility folder, and wait for the package to initialise. You can now build and run your JavaScript using npm run build or npm start.

3.2: Registering Post Meta

We need to register a post meta field to store the visibility setting. Open the post-content-visibility.php file in the plugin directory and add the following code:

<?php
/**
 * Plugin Name:       Post Content Visibility
 * Description:       Adds a toggle to control the visibility of post content on the front end.
 * Version:           1.0.0
 * Author:            Your Name
 * Text Domain:       post-content-visibility
 */

function pcv_register_post_meta() {
    register_post_meta( '', 'pcv_display_post_content', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'boolean',
        'default'      => true,
    ] );
}
add_action( 'init', 'pcv_register_post_meta' );

By registering the meta for all post types (denoted by the empty string ''), we can use this setting across different content types.

3.3: Enqueuing the Sidebar Toggle Script

Add the following code to your post-content-visibility.php file to enqueue the sidebar toggle script in the block editor:

function pcv_enqueue_editor_assets() {
    wp_enqueue_script(
        'post-content-visibility',
        plugins_url( 'build/index.js', __FILE__ ),
        array( 'wp-plugins', 'wp-edit-post', 'wp-element', 'wp-components', 'wp-data', 'wp-i18n' ),
        '1.0.0',
        true
    );
}
add_action( 'enqueue_block_editor_assets', 'pcv_enqueue_editor_assets' );

This function ensures that the script is loaded in all editors that support the block editor.

3.4: Building the Toggle in the Post Sidebar

We’ll use the PluginDocumentSettingPanel component to add a custom panel in the post sidebar. Open src/index.js and replace its content with the following code.

import { PluginDocumentSettingPanel } from '@wordpress/editor';
import { ToggleControl } from '@wordpress/components';
import { useSelect, useDispatch } from '@wordpress/data';
import { registerPlugin } from '@wordpress/plugins';
import { __ } from '@wordpress/i18n';

const PostContentVisibility = () => {
    const { editPost } = useDispatch( 'core/editor' );
    const displayContent = useSelect(
        ( select ) => select( 'core/editor' )?.getEditedPostAttribute( 'meta' )?.['pcv_display_post_content'],
        []
    );

    return (
        <PluginDocumentSettingPanel
            name="post-content-visibility"
            title={ __( 'Post Content Visibility', 'post-content-visibility' ) }
            className="post-content-visibility-panel"
        >
            <ToggleControl
                label={ __( 'Display Post Content', 'post-content-visibility' ) }
                checked={ displayContent }
                onChange={ ( value ) => editPost( { meta: { pcv_display_post_content: value } } ) }
                help={ __( 'Toggle the visibility of the post content on the front end.', 'post-content-visibility' ) }
            />
        </PluginDocumentSettingPanel>
    );
};

// Check if we're in the Post Editor before registering the plugin.
if ( window.pagenow !== 'site-editor' ) {
    registerPlugin( 'post-content-visibility', {
        render: PostContentVisibility,
        icon: 'visibility',
    } );
}

This component fetches the pcv_display_post_content meta field and updates it when the toggle is changed.

3.5: Modifying the Front-End Display

We need to check the meta value when rendering the post content and conditionally display it. In post-content-visibility.php, add the following code:

function pcv_filter_the_content( $content ) {
    if ( is_singular() ) {
        $display_content = get_post_meta( get_the_ID(), 'pcv_display_post_content', true );
        if ( ! $display_content ) {
            return '<p>' . __( 'This post is hidden from view.', 'post-content-visibility' ) . '</p>';
        }
    }
    return $content;
}
add_filter( 'the_content', 'pcv_filter_the_content' );

This function checks if the pcv_display_post_content meta is false and replaces the content with a custom message if so.

3.6: Building the Plugin

After updating src/index.js, build your JavaScript file using wp-scripts:

npm run build

This will generate a build/index.js file. Your plugin is now ready to use!

Step 7: Using the Sidebar

Remember to activate the plugin.

Note that in the post sidebar we now have the Display Post Content toggle.

Switch the toggle and save the post.

Note that we have now replaced the content of the entire post.

4. Custom Plugin Sidebar: Toggle Entire Post Visibility

Sometimes you might have a plugin that adds many post controls, when this happens it might make sense to put all of these in a custom sidebar so that they are all together, easily identifiable and reduce post sidebar clutter.

In this section, we’ll create a custom plugin sidebar that allows you to toggle the entire post’s visibility. When disabled, the post will not be accessible on the front end, and visitors will see a 404 error.

4.1: Setting Up the Plugin

Create a new plugin folder called post-visibility-toggle in your WordPress wp-content/plugins directory.

Inside this folder, create a src folder for your JavaScript code and a post-visibility-toggle.php file for the plugin’s PHP code.

As per the last couple of examples, we are going to use wp-scripts. In the post-visibility-toggle folder, initialise your package with wp-scripts by creating the following package.json file in the root of the plugin:

{
    "name": "post-visibility-toggle",
    "version": "1.0.0",
    "description": "Toggle the visibility of the entire post from the editor sidebar.",
    "main": "index.js",
    "scripts": {
        "build": "wp-scripts build",
        "start": "wp-scripts start"
    },
    "keywords": [],
    "author": "Your Name",
    "license": "ISC",
    "dependencies": {
        "@wordpress/scripts": "^25.0.0"
    }
}

Now run npm install from inside the post-visibility-toggle folder, and wait for the package to initialise. You can now build and run your JavaScript using npm run build or npm start.

4.2: Registering Post Meta

Open the post-visibility-toggle.php file, make sure the enqueue for the editor and register a post meta field to store the visibility setting:

<?php
/**
 * Plugin Name:       Post Visibility Toggle
 * Description:       Adds a toggle to control the visibility of the entire post on the front end.
 * Version:           1.0.0
 * Author:            Your Name
 * Text Domain:       post-visibility-toggle
 */

function pvt_enqueue_editor_assets() {
    wp_enqueue_script(
        'post-visibility-toggle',
        plugins_url( 'build/index.js', __FILE__ ),
        [ 'wp-plugins', 'wp-edit-post', 'wp-element', 'wp-components', 'wp-data', 'wp-i18n' ],
        '1.0.0',
        true
    );
}
add_action( 'enqueue_block_editor_assets', 'pvt_enqueue_editor_assets' );

function pvt_register_post_meta() {
    register_post_meta( '', 'pvt_display_post', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'boolean',
        'default'      => true,
    ] );
}
add_action( 'init', 'pvt_register_post_meta' );

4.3: Creating the Plugin Sidebar

In src/index.js, create the plugin sidebar with a toggle control:

import { PluginSidebar } from '@wordpress/editor';
import { ToggleControl, PanelBody } from '@wordpress/components';
import { useSelect, useDispatch } from '@wordpress/data';
import { registerPlugin } from '@wordpress/plugins';
import { __ } from '@wordpress/i18n';

const PostVisibilityToggle = () => {
    const { editPost } = useDispatch('core/editor');
    const displayPost = useSelect(
        ( select ) => select( 'core/editor' )?.getEditedPostAttribute( 'meta' )?.['pvt_display_post'],
        []
    );

    return (
        <PluginSidebar
            name="post-visibility-toggle"
            title={ __( 'Post Visibility', 'post-visibility-toggle' ) }
            icon="visibility"
        >
            <PanelBody title={ __('Post Visibility Settings', 'post-visibility-toggle' ) }>
                <ToggleControl
                    label={ __( 'Display Post', 'post-visibility-toggle' ) }
                    checked={ displayPost }
                    onChange={ ( value ) => editPost( { meta: { pvt_display_post: value } } ) }
                    help={ __( 'Toggle the visibility of the entire post on the front end.', 'post-visibility-toggle' ) }
                />
            </PanelBody>
        </PluginSidebar>
    );
};

// Check if we're in the Post Editor before registering the plugin.
if ( window.pagenow !== 'site-editor' ) {
    registerPlugin( 'post-visibility-toggle', {
        render: PostVisibilityToggle,
        icon: 'visibility',
    } );
}

This code creates a sidebar that appears in the editor where you can toggle the entire post’s visibility.

4.4: Redirecting Hidden Posts to 404

In the plugin’s PHP file, we’ll add an action to redirect to a 404 page if the post is hidden:

function pvt_redirect_hidden_posts() {
    if ( is_singular() && !is_admin() ) {
        $display_post = get_post_meta( get_the_ID(), 'pvt_display_post', true );
        if ( ! $display_post ) {
            global $wp_query;
            $wp_query->set_404();
            status_header( 404 );
            nocache_headers();
            include( get_query_template( '404' ) );
            exit;
        }
    }
}
add_action( 'template_redirect', 'pvt_redirect_hidden_posts' );

This function checks if the post should be displayed and, if not, sets a 404 status and loads the 404 template.

4.5: Using the Sidebar

Remember to run npm run build in your block directory and to activate the plugin.

Now you should be able to see your custom Post Visibility sidebar, identified by the “eye” icon. Click the icon and it should open up the sidebar. Once you have done this you should be able to see the controls that you registered for the sidebar.

Be sure to switch the toggle and save the post.

As per the logic we set, this will redirect the post to a 404 page on the front end.

5. Full Site Editor (FSE) Sidebar: Global Settings

We have explored block settings with block sidebars, post settings with post sidebars and custom sidebars. What if we want something that impacts the entire site? Say something that is stored in an option?

To explore this we’ll create a sidebar in the Full Site Editor (FSE) to manage global site-wide settings. This sidebar can control settings that affect the entire website.

In this example, we will prevent the entire site from displaying with a wp_die(). This is absolutely overkill (and you should never do this), but it serves to prove how this kind of sidebar can be used.

5.1: Setting Up the Plugin

Create a new plugin folder called fse-global-settings in your WordPress wp-content/plugins directory.

Inside this folder, create a src folder for your JavaScript code and a fse-global-settings.php file for the plugin’s PHP code.

As per the last few examples, we are going to use wp-scripts. In the fse-global-settings folder, initialise your package with wp-scripts by creating the following package.json file in the root of the plugin:

{
    "name": "fse-global-settings",
    "version": "1.0.0",
    "description": "Adds a custom sidebar to the Full Site Editor for global settings.",
    "main": "index.js",
    "scripts": {
        "build": "wp-scripts build",
        "start": "wp-scripts start"
    },
    "keywords": [],
    "author": "Your Name",
    "license": "ISC",
    "dependencies": {
        "@wordpress/scripts": "^25.0.0"
    }
}

Now run npm install from inside the fse-global-settings folder, and wait for the package to initialise. You can now build and run your JavaScript using npm run build or npm start.

5.2: Enqueueing Scripts and Styles

We need to include our plugin header in the root plugin file.

We’ll also enqueue our JavaScript file that registers the sidebar component. In fse-global-settings.php, add the following code:

<?php
/**
 * Plugin Name: FSE Global Settings
 * Description: Adds a custom sidebar to the Full Site Editor for global settings.
 * Version: 1.0.0
 * Author: Your Name
 * Text Domain: fse-global-settings
 */

function fse_gs_enqueue_assets() {
    wp_enqueue_script(
        'fse-gs-editor-script',
        plugins_url( 'build/index.js', __FILE__ ),
        [ 'wp-edit-site', 'wp-plugins', 'wp-element', 'wp-data', 'wp-components', 'wp-i18n' ],
        filemtime( plugin_dir_path( __FILE__ ) . 'build/index.js' )
    );
}
add_action( 'enqueue_block_editor_assets', 'fse_gs_enqueue_assets' );

5.3: Creating the Sidebar Component

Now, we’ll add the code for the sidebar. In src/index.js, add the following:

import { registerPlugin } from '@wordpress/plugins';
import { PluginSidebar } from '@wordpress/edit-site';
import { PanelBody, ToggleControl } from '@wordpress/components';
import { useSelect, useDispatch } from '@wordpress/data';
import { __ } from '@wordpress/i18n';

const GlobalSettingsSidebar = () => {
    const { editEntityRecord } = useDispatch( 'core' );
    const globalVisibility = useSelect( ( select ) => {
        const settings = select('core').getEntityRecord( 'root', '__experimentalSite' );
        return settings ? settings.global_visibility : true;
    }, []);

    const onChange = (value) => {
        editEntityRecord( 'root', '__experimentalSite', undefined, { global_visibility: value } );
    };

    return (
        <PluginSidebar
            name="fse-global-settings"
            title={ __( 'Global Settings', 'fse-global-settings' ) }
            icon="admin-site"
        >
            <PanelBody title={ __( 'Site-Wide Settings', 'fse-global-settings' ) }>
                <ToggleControl
                    label={ __('Enable Global Content Visibility', 'fse-global-settings' ) }
                    checked={ globalVisibility }
                    onChange={ onChange }
                    help={ __( 'Toggle global visibility settings for the site.', 'fse-global-settings' ) }
                />
            </PanelBody>
        </PluginSidebar>
    );
};

// Check if we're in the Site Editor before registering the plugin.
if ( window.pagenow === 'site-editor' ) {
    registerPlugin( 'fse-global-settings', {
        render: GlobalSettingsSidebar,
    } );
}

5.4: Registering Global Settings

We need to register the global_visibility setting so it can be saved and retrieved. In fse-global-settings.php, add:

function fse_gs_register_settings() {
    register_setting( 'general', 'global_visibility', [
        'type'         => 'boolean',
        'default'      => true,
        'show_in_rest' => true,
    ] );
}
add_action( 'init', 'fse_gs_register_settings' );

5.5: Applying Global Settings on the Front End

Finally, we’ll check the global_visibility setting when rendering the site. In your theme’s functions.php or within the plugin, add:

function fse_gs_check_global_visibility() {
    $global_visibility = get_option( 'global_visibility', true );
    if ( ! $global_visibility ) {
        // Redirect to maintenance page or display a message.
        wp_die( __( 'The site is currently not visible.', 'fse-global-settings' ) );
    }
}
add_action( 'template_redirect', 'fse_gs_check_global_visibility' );

This function checks the global_visibility option and, if set to false, prevents the site from displaying.

5.6: Using the Sidebar

Remember to run npm run build in your block directory and to activate the plugin.

Now, when you edit a template in the Full Site Editor, you will see the “globe” icon. Clicking on this icon will open the sidebar we just created.

Again, the control we added to the sidebar is visible. Toggle this and save the sidebar.

You will likely then be prompted by another confirmation sidebar, save the setting here too.

As per our logic, we get a side wide message, preventing us from loading the site.

Conclusion

You’ve learned how to create four distinct types of sidebars in WordPress: block-level controls, post-specific options, a custom plugin sidebar, and a Full Site Editor sidebar. Each of these sidebars provides specialized content control options, enhancing both the editing experience and the front-end behavior of your site.

We also explored how to use block filters to add features to all blocks, and discussed when @wordpress/create-block is suitable for plugin creation and when manual @wordpress/scripts is more appropriate.

If you have any questions, please drop them below in the comments.

This guide will walk you through setting up Studio for block development and making sure everything works just as it should.

Studio vs. LocalWP: Why Choose Studio?

If you’re after a comprehensive tool with support for local domains, multisite, and more, LocalWP is a popular choice. But if ease-of-use and a streamlined setup sound good, Studio by WordPress.com is highly recommended here. It’s fast, efficient, and doesn’t bog you down with extra setup steps.

Step 1: Download and Install Studio

First things first: head to the Studio by WordPress.com site and download the installer that suits your operating system.

On Mac: Open the downloaded .dmg file, then drag the Studio app into your Applications folder. Easy as pie (mmmm, Apple Pie).

Step 2: Set Up Your First Site

Once installed, open Studio, and you’ll be greeted with the friendly “Add Your First Site” prompt. Click it to start creating your local WordPress site.

Customize Your Site Path: If you’re a stickler for organisation (who isn’t?), hit the “Advanced Settings” dropdown. I like to keep all my sites in a /Sites folder for easy access, so here’s where you can set a custom installation path if you’re the same way.

While we are at it, let’s give our site a name. I’ve chosen “Sandbox”.

Step 3: Finalise Your Site Creation

After you’ve named your site and set any advanced settings, go ahead and click “Add Site.” Studio will now work its magic. You’ll see a progress bar, and in no time, you’ll be met with your site dashboard.

The dashboard provides links to key areas of your site, so you’re always one click away from the WordPress dashboard, file access, or terminal.

But first, let’s make sure everything is working.

Step 4: Open the WordPress Dashboard

Click the “WP Admin” link beneath your site title, and this will bring you right into the WordPress dashboard, where you’ll do most of your WordPress configuration and plugin management. If the WordPress dashboard appears, you’re ready to start developing!

Step 5: Access Your Code Editor

Studio provides a quick “VS Code” button on the dashboard, so if VS Code is your editor of choice, this opens your site project directly in VS Code. Not using VS Code? You might want to give it a try download it directly from the VS Code website. It’s incredibly versatile, with plugins for just about anything.

After you have VS Code installed, clicking “Open in VS Code” pulls up your site files in the editor, ready to start development.

Step 6: Use the Integrated Terminal

For block development, we’ll need the command line for some operations. VS Code has an integrated terminal that makes this easy to access:

Access the Terminal: Go to “View” > “Terminal” in VS Code.

From here, you can run commands directly within your development environment.

Step 7: Install Node.js and Start with create-block

Most block development projects require Node.js, a JavaScript runtime that lets you run development scripts on your computer. Go to the Node.js website and install it. Once installed, you’re ready to start creating custom blocks.

With Node.js installed, navigate to the plugins folder in your terminal:

cd wp-content/plugins/

Tip: cd means “Change Directory”.

Run the create-block command to generate your first block plugin scaffold:

npx @wordpress/create-block@latest

This command guides you through setting up a custom block plugin in interactive mode, with prompts to configure the basics like slug, name, and category.

For my installation I chose the following options:

• The template variant to use for this block: static

• The block slug used for identification (also the output folder name): my-first-block

• The internal namespace for the block name (something unique for your products): my-first-block

• The display title for your block: My First Block

• The short description for your block (optional): This is my first block, there are many like it, but this one is mine

• The dashicon to make it easier to identify your block (optional): smiley

• The category name to help users browse and discover your block: design

• Do you want to customize the WordPress plugin? N

The script will then take a moment to initiate the plugin.

Once done, you’ll see your new block plugin appear in the plugins folder.

Follow the instructions provided, cd into the plugin (cd my-first-block) and run rpm run build to build the assets.

You should now be able to access the block in the Block Editor (after a refresh of course).

Wrapping Up: Your Block Development Setup with Studio

With Studio by WordPress.com and a few additional tools, you’ve now got a fast and efficient setup for block development. You’re now ready to dive into custom WordPress block development with a streamlined local environment.

Time to start building the next great WordPress plugin! If you hit any snags, drop a question in the comments.

(I’ve gathered these trusty code snippets from some of my older blog posts. Some might be a bit old, but they might still come in handy.)

1. Prevent Users from Sharing Login Credentials

It’s one thing to share a Netflix password, but when users start sharing credentials on your WordPress site, it becomes a security issue. You want to ensure that each account is only used by one person at a time to prevent account sharing, data leaks, or worse. This snippet limits users to a single active login session at a time. If someone logs in while another session is active, the previous one is terminated. This stops users from sharing their login credentials with others.

function matt_watson_login_one_instance() {
    global $sessions;
    $sessions = WP_Session_Ttokens::get_instance( get_current_user_id() );
    $sessions->destroy_others( wp_get_session_token() );
}
add_action('setup_theme', 'matt_watson_login_one_instance', 0);

2. Prevent Clickjacking in WordPress

Clickjacking is a malicious technique where attackers trick users into clicking something different from what they think they’re clicking. Attackers often use iframes to load your site invisibly on their own malicious website. By adding the X-FRAME-OPTIONS header to your site, you can instruct the browser not to display your content within an iframe, thereby protecting your site from clickjacking attempts.

function matt_watson_prevent_clickjacking() {
    header( 'X-FRAME-OPTIONS: SAMEORIGIN' );
}
add_action( 'send_headers', 'matt_watson_prevent_clickjacking', 10 );

3. Stop WordPress from Loading in a Frame (Older Browsers Too!)

While the X-FRAME-OPTIONS header works well for most modern browsers, older versions of browsers (such as Internet Explorer 8 and earlier) don’t support it. To protect users who may still be using older browsers, this JavaScript fallback ensures that your site can’t be loaded in a frame on those browsers either. It continuously checks if the site is loaded in a frame and, if it is, wipes out the content.

try { top.document.domain } catch (e) {
    var f = function() {
        document.body.innerHTML = '';
    };

    setInterval( f, 1 );

    if ( document.body ) {
        document.body.onload = f;
    }
}

4. Enforce Version Control in WordPress

WordPress allows users to edit theme files and install plugins directly from the dashboard. While this might seem convenient, it’s not ideal from a security standpoint, especially in environments where multiple users have access to the admin area. By disabling file editing and plugin installations via the WordPress dashboard, you can ensure that all changes go through your version-controlled workflow, avoiding surprise edits and potential vulnerabilities.

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

5. Limit Login Attempts to Prevent Brute Force Attacks

Brute force attacks happen when malicious users or bots repeatedly try to guess login credentials. To mitigate this, you can limit the number of login attempts a user can make before they are temporarily locked out. In this snippet, after three failed login attempts, the user is locked out for a defined period, reducing the likelihood of a brute force attack succeeding.

function matt_watson_limit_login_attempts() {
    $lockout_duration = 1800; // Lockout duration in seconds (30 minutes)
    $data = get_transient( 'mattwatson_attempted_login' ) ?: [ 'tried' => 0 ];

    $data['tried']++;

    if ( $data['tried'] >= 3 ) {
        // Logic for handling lockout after 3 failed attempts
        // Example: temporarily block user login for the duration
    }

    set_transient( 'mattwatson_attempted_login', $data, $lockout_duration );
}

add_action( 'wp_login_failed', 'matt_watson_limit_login_attempts' );

6. Prevent XSS by Escaping Values in Your WordPress Templates

Cross-site scripting (XSS) is one of the most common vulnerabilities on the web. It occurs when an attacker injects malicious code into your site, often via user inputs that are displayed without proper sanitation. By using WordPress functions like esc_attr() and esc_html() when displaying user-generated content, you can prevent XSS attacks. These functions escape any special characters that could be interpreted as code, ensuring that only safe data is output.

Here’s how you should sanitize user input in your WordPress templates:

<input type="text" value="<?php echo esc_attr( $my_value ); ?>">

These six tips provide a solid foundation for securing your WordPress site. From preventing account sharing and brute force attacks to mitigating XSS vulnerabilities, these strategies will help ensure that your WordPress site remains safe from common threats.

(I’ve gathered these trusty code snippets from some of my older blog posts. Some might be a bit old, but they might still come in handy.)

General PHP and Data Management Tips

1. Array Change Key Case

When handling external data, especially data from APIs or third-party services, you’ll often come across array keys that aren’t in a format you’d prefer—sometimes they’re all uppercase or inconsistent with your internal structure. To solve this, you can use PHP's array_change_key_case() function to quickly convert all array keys to either lowercase or uppercase. This makes your data easier to work with and ensures uniformity.

Here’s an example that converts an array’s keys to lowercase:

$array            = [ 'P' => 42, 'POST_STATUS' => 'publish' ];
$lower_case_array = array_change_key_case( $array, CASE_LOWER );

print_r( $lower_case_array );

// Output:
// Array
// (
//     [p] => 42
//     [post_status] => publish
// )

2. Dynamic Variable Names in PHP

There are cases when you need to create variables dynamically within loops or repetitive structures, especially when dealing with user-generated data or flexible input formats. Using dynamic variable names allows you to generate new variables on the fly based on conditions or data, which can be handy in certain situations. However, use this technique cautiously, as it can make your code harder to debug.

Here’s an example that dynamically creates variables based on an array’s values:

$custom_variable_array = ['name_1', 'name_2', 'name_3'];

foreach ( $custom_variable_array as $custom_variable ) {
    $$custom_variable = 'Some Value';
}
echo $name_1;

3. Remove Duplicates from Arrays

Working with arrays often involves cleaning up data and ensuring there are no duplicate values. PHP’s array_unique() function provides a simple way to eliminate duplicate entries from an array, leaving you with clean, unique data. This is particularly useful when you’re aggregating data from multiple sources or handling form input where duplicates might occur.

Here's how you can remove duplicate values from an array:

$array = [ 'apple', 'banana', 'apple', 'orange', 'banana' ];
$unique_array = array_unique( $array );

print_r( $unique_array );

// Output:
// Array
// (
//     [0] => apple
//     [1] => banana
//     [3] => orange
// )

4. Merge Arrays Recursively

Merging arrays in PHP can be tricky when you have nested arrays or need to combine multidimensional arrays. The array_merge_recursive() function comes in handy by merging arrays while preserving their nested structure. This is particularly useful when combining configurations or settings from different sources without losing any nested values.

Here’s an example that merges two multidimensional arrays:

$array1 = [
    'settings' => [
        'color' => 'blue',
        'size'  => 'medium',
    ]
];

$array2 = [
    'settings' => [
        'size'  => 'large',
        'shape' => 'round',
    ]
];

$merged_array = array_merge_recursive( $array1, $array2 );

print_r( $merged_array );

// Output:
// Array
// (
//     [settings] => Array
//         (
//             [color] => blue
//             [size] => Array
//                 (
//                     [0] => medium
//                     [1] => large
//                 )
//             [shape] => round
//         )
// )

Text and Content Management Tips

5. Filter Text Strings in WordPress Using gettext

Customizing text strings in themes or plugins can sometimes involve modifying the original code, which is neither practical nor update-friendly. Instead, WordPress provides the gettext filter, allowing you to dynamically change text strings without touching the source files. This is particularly useful for making quick adjustments to text used by third-party themes or plugins.

Here’s how to modify a string using the gettext filter:

function matt_watson_filter_text( $translated_text, $untranslated_text, $domain ) {
    if ( 'String to translate' === $untranslated_text && 'mattwatson' === $domain ) {
        return esc_html__( 'Translated Text', 'mattwatson' );
    }
    return $translated_text;
}
add_filter( 'gettext', 'matt_watson_filter_text', 10, 3 );

6. Sanitize Titles with sanitize_title()

When generating URLs or slugs from user inputs, it’s important to sanitize the title to ensure it's URL-friendly. WordPress offers the sanitize_title() function, which removes unwanted characters and spaces, turning your input into a clean slug. This is useful for creating SEO-friendly URLs or unique identifiers for content.

Here’s an example of how to sanitize a title in WordPress:

$title = "This is My Awesome Post!";
$slug = sanitize_title( $title );

echo $slug; // Output: this-is-my-awesome-post

7. Programmatically Create WordPress Pages

If you’re setting up a WordPress site and need to automatically generate pages upon theme activation or plugin installation, you can programmatically create new pages using wp_insert_post(). This allows you to set up default content or landing pages, saving time and ensuring consistency across installations.

Here’s an example of how to create a page programmatically:

function matt_watson_create_default_page() {
    $page_data = [
        'post_title'    => 'Contact Us',
        'post_content'  => 'This is the contact page.',
        'post_status'   => 'publish',
        'post_type'     => 'page',
    ];

    wp_insert_post( $page_data );
}
add_action( 'after_setup_theme', 'matt_watson_create_default_page' );

8. Automatically Shorten Excerpts in WordPress

By default, WordPress excerpts can be too long or inconsistent for certain themes. You can programmatically set the length of excerpts to ensure they’re a consistent size across your site. This is especially useful for improving the look and feel of archive pages, blog listings, or search results.

Here’s a simple function to control excerpt length:

function matt_watson_set_excerpt_length( $length ) {
    return 20; // Limit excerpt to 20 words
}

add_filter( 'excerpt_length', 'matt_watson_set_excerpt_length', 999 );

9. Replace WordPress Shortcodes Programmatically

If you need to replace shortcodes dynamically in your content, WordPress provides a filter called do_shortcode_tag that allows you to replace shortcodes with custom logic. This is especially useful if you want to swap out certain shortcodes or modify their output without changing the underlying content structure.

Here’s how you can replace a shortcode with a custom output:

function matt_watson_replace_shortcode_output( $output, $tag, $attr ) {
    if ( 'old_shortcode' === $tag ) {
        return 'This is the new output!';
    }
    return $output;
}

add_filter( 'do_shortcode_tag', 'matt_watson_replace_shortcode_output', 10, 3 );

These nine tips and tricks will help streamline your WordPress development process, whether you're working with PHP arrays or fine-tuning your WordPress content. By mastering these techniques, you’ll be able to work faster, more efficiently, and create better-performing websites with less effort.

(I’ve gathered these trusty code snippets from some of my older blog posts. Some might be a bit old, but they might still come in handy.)

1. Array Chunking for Large Data Sets

Handling large datasets in WordPress can quickly become problematic if you try to process everything at once. A massive array of data can overwhelm your server, leading to slow page loads or even server crashes. By chunking arrays into smaller pieces, you can improve the way your server handles large datasets, optimizing performance and memory usage.

The following snippet demonstrates how to split a large array into smaller, more manageable chunks. This helps the server process data more efficiently, making your site faster and more responsive.

$array = [ 'Post 0', 'Post 1', 'Post 2', 'Post 3', 'Post 4', 'Post 5' ];
$chunked_array = array_chunk( $array, 2 );

print_r( $chunked_array );

// Output:
// Array
// (
//     [0] => Array
//         (
//             [0] => Post 0
//             [1] => Post 1
//         )
//     [1] => Array
//         (
//             [0] => Post 2
//             [1] => Post 3
//         )
//     [2] => Array
//         (
//             [0] => Post 4
//             [1] => Post 5
//         )
// )

2. Disable Emoji Scripts

Emojis, while fun, aren’t essential for every website. Yet, WordPress loads emoji scripts by default, even on sites where they aren’t needed. These scripts add unnecessary weight to your pages, slightly slowing down your site’s load time. By disabling these emoji scripts, you can streamline your site and speed up page loads.

Here’s how you can remove those extra emoji scripts from your site’s header and styles, which will result in fewer HTTP requests and quicker page rendering.

function matt_watson_disable_emojis() {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
}

add_action( 'init', 'matt_watson_disable_emojis' );

3. Query Optimization

Inefficient database queries can significantly slow down your WordPress site, especially when generated by plugins or themes. By analyzing these queries, you can refine them to make your database interactions faster and more efficient. This is particularly useful for large, content-heavy sites where unnecessary queries can impact performance.

The following snippet optimizes the SQL queries generated by WPML (WordPress Multilingual Plugin) by removing unnecessary post-type lookups, reducing query load, and improving page speed.

function matt_watson_remove_post_type_sql_search( $query ) : string {
    global $wpdb;

    $id_sql        = "{$wpdb->posts}.ID = wpml_translations.element_id";
    $post_type_sql = "AND wpml_translations.element_type = CONCAT('post_', {$wpdb->posts}.post_type)";

    if ( ! str_contains( $query, $id_sql ) || ! str_contains( $query, $post_type_sql ) ) {
        return $query;
    }

    $query = str_replace( $post_type_sql, '', $query );

    return $query;
}

add_filter( 'query', 'matt_watson_remove_post_type_sql_search' );

4. XDebug Profiling for Slow Plugins

Plugins are a key feature of WordPress, but they can also be a source of performance bottlenecks. Some plugins load unnecessary resources or execute inefficient PHP processes, significantly slowing down your site’s response time. Using tools like XDebug allows you to profile your PHP processes, identifying which plugins or theme components are hogging resources.

Once you know which plugins are the main offenders, you can either disable them, find more efficient alternatives, or work on optimizing them directly. This process can greatly improve your Time to First Byte (TTFB) and overall site speed.

5. Leveraging Object Caching

WordPress allows you to cache objects, reducing the need for repeated database queries, but excessive autoloaded options can overwhelm your cache. When too many options are autoloaded, performance can degrade, especially if your hosting provider disables object caching altogether. By controlling which options are autoloaded, you can keep your cache lean and efficient, improving your site’s performance.

Here’s a snippet that prevents specific options from being autoloaded, reducing unnecessary load on the cache and improving database efficiency:

function matt_watson_set_autoload_to_no( $option ) {
    global $wpdb;

    $autoloaded_options = ['permalink-manager-uris', /* other options */];

    if ( ! in_array( $option, $autoloaded_options ) ) {
        return;
    }

    $wpdb->update(
        $wpdb->prefix . "options", 
        ['autoload' => 'no'], 
        ['option_name' => $option]
    );
}

add_action( 'updated_option', 'matt_watson_set_autoload_to_no' );
add_action( 'added_option', 'matt_watson_set_autoload_to_no' );

6. Advanced Conditional Plugin Loading for Elementor

Some plugins, like Elementor, can dramatically increase page load times if loaded on every page, even those that don’t require their functionality. By conditionally loading these plugins only when necessary, you can significantly reduce the load on your server and improve page speed for non-Elementor pages.

Here’s a detailed example of how to conditionally disable Elementor and its dependencies unless needed, such as for specific post types or Elementor edit modes:

function matt_watson_restrict_elementor_loading( $plugins ) : array {
    if ( is_admin() || wp_doing_ajax() ) {
        return $plugins;
    }

    if ( isset( $_GET['elementor-preview'] ) ) {
        return $plugins;
    }

    $path      = $_SERVER['REQUEST_URI'];
    $path_base = basename( $path );

    $rest_prefix         = trailingslashit( rest_get_url_prefix() );
    $is_rest_api_request = strpos( $path, $rest_prefix ) !== false;

    if ( $is_rest_api_request ) {
        return $plugins;
    }

    $post = get_page_by_path( $path_base, OBJECT, [ 'page', 'getting_started_hub' ] );
    $is_elementor_page = is_object( $post ) && ! empty( get_post_meta( $post->ID, '_elementor_edit_mode', true ) );

    if ( $is_elementor_page ) {
        return $plugins;
    }

    $remove_plugins = [
        'elementor/elementor.php',
        'elementor-pro/elementor-pro.php',
        'elemental-menu/elemental-menu.php',
        'unlimited-elements-for-elementor-premium/unlimited-elements-pro.php',
    ];

    foreach ( $remove_plugins as $remove_plugin ) {
        $key = array_search( $remove_plugin , $plugins );
        unset( $plugins[ $key ] );
    }

    return $plugins;
}

add_filter( 'option_active_plugins', 'matt_watson_restrict_elementor_loading' );

7. Remove WPML Distinct Strings in English

On a multilingual site powered by WPML, WordPress often loads distinct language strings, even when browsing the site in English. Since your default language is likely English, loading these strings is unnecessary and adds extra load to your database. By removing the query for distinct strings when viewing the English version, you can improve database performance and speed up page load times.

This code snippet stops WPML from loading distinct language strings on English pages, reducing the number of queries executed and optimizing site performance for English-speaking users:

function matt_watson_remove_wpml_distinct_strings_in_english( $query ) {
    global $wpdb;

    if ( is_admin() ) {
        return $query;
    }

    $path = $_SERVER['REQUEST_URI'];
    $path = explode( '/', $path );
    $path = array_filter( $path );
    $lang = reset( $path );

    if ( isset( $lang ) && in_array( $lang, [ 'es', 'fr', 'it', 'de', 'br' ] ) ) {
        return $query;
    }

    $id_sql = "FROM {$wpdb->prefix}icl_strings";

    if ( false === strpos( $query, $id_sql ) && false === strpos( $query, 'DISTINCT' ) ) {
        return $query;
    }

    return '';
}

add_filter( 'query', 'matt_watson_remove_wpml_distinct_strings_in_english' );

These seven tips may seem small individually, but combined, they can lead to significant performance improvements for your WordPress site. From chunking arrays and optimizing database queries to conditionally loading plugins and disabling unnecessary features, each tweak helps ensure your site runs as fast and efficiently as possible.

(I’ve gathered these trusty code snippets from some of my older blog posts. Some might be a bit old, but they might still come in handy.)

SEO and Search Engine Optimisation Tips

Optimising your site for search engines is crucial. These tips focus on controlling what search engines can access, helping you maintain a clean SEO profile.

1. Add Custom Rules to robots.txt in WordPress

When search engines like Google crawl your site, they can index everything by default, including files and sections you might not want to appear in search results. For instance, you might not want certain file types, such as PDFs, to be indexed by Google.

This snippet allows you to add custom rules to the robots.txt file in WordPress, preventing search engines from indexing specific files. By controlling what is indexed, you maintain a cleaner and more relevant SEO profile.

function matt_watson_disallow_pdf_index($output, $public) {
    if ('1' !== $public || ! is_string( $output )) {
        return $output;
    }
    $output .= "Disallow: *.pdf
";
    return $output;
}
add_filter('robots_txt', 'matt_watson_disallow_pdf_index', 0, 2);

2. Add /blog to Post Slug

For larger websites, organising content effectively can significantly improve SEO and user experience. One way to do this is by adding /blog to your post slugs, which helps structure your URLs more clearly, particularly on content-heavy sites.

This snippet allows you to customise the post slug in WordPress by adding /blog, improving the overall content hierarchy and making it easier for search engines to understand the structure of your site.

function matt_watson_add_blog_to_post_slug() {
    if ( post_type_exists( 'post' ) ) {
        return;
    }
    register_post_type(
        'post',
        [
            'rewrite'  => [ 'slug' => 'blog' ],
            'supports' => [ 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ]
        ]
    );
}
add_action( 'init', 'matt_watson_add_blog_to_post_slug', 1 );

3. Add Custom Rewrite Tags and Customise Author URLs with a Dynamic Prefix

Customising your URLs can significantly improve SEO by making them more descriptive. This snippet adds a custom rewrite tag, %faculty%, allowing you to modify URLs for posts (in this case, journal posts) to include both an author’s name and another dynamic value, like a category or department. This makes URLs more informative, which helps search engines better understand the context of the page.

In the example, %faculty% is replaced by a static value ('my-test-faculty'), but it could be dynamically set from post metadata. The %author% tag is automatically replaced with the author’s nicename, creating a URL structure like:

/my-test-faculty/john/journal/

This improves readability for users and search engines, benefiting your SEO.

// Add a custom rewrite tag for 'faculty'
function matt_watson_register_rewrite_tags() {
    add_rewrite_tag( '%faculty%', '([^&]+)' ); // We add the faculty tag for URL rewrites
}
add_action( 'init', 'matt_watson_register_rewrite_tags' );

// Modify the permalink structure for the 'journal' post type
function matt_watson_post_type_link( $post_link, $post, $leavename, $sample ) {

    // Check that the post is of type 'journal' and return early if not
    if ( 'journal' !== get_post_type( $post ) ) {
        return $post_link;
    }

    // Get the author's nicename to insert into the URL
    $authordata = get_userdata( $post->post_author );
    if ( ! $authordata ) {
        return $post_link;
    }
    $author = $authordata->user_nicename;

    // Replace the %author% tag in the URL with the actual author's nicename
    $post_link = str_replace( '%author%', $author, $post_link );

    // Replace the %faculty% tag with a static value or a dynamic value (this can be replaced with post meta or other logic)
    // For now, using a static test value 'my-test-faculty'
    $post_link = str_replace( '%faculty%', 'my-test-faculty', $post_link );

    // Example of the resulting URL structure:
    // /my-test-faculty/john/journal/

    return $post_link;
}
add_filter( 'post_type_link', 'matt_watson_post_type_link', 10, 4 );

Customisation Tips for the WordPress Interface

Customising the WordPress interface can improve usability for site admins and users alike. These tips will help you add custom styles, controls, and settings to WordPress with ease.

4. Disable the Admin Bar for Non-Admins

The WordPress admin bar can be distracting for non-admin users, especially if it’s not necessary for their experience. Disabling the admin bar for these users can simplify the frontend interface and reduce clutter.

This snippet provides a solution for hiding the admin bar for non-admin users, with a guard to ensure administrators and backend users still see it.

function matt_watson_remove_admin_bar() {
    if ( current_user_can( 'administrator' ) || is_admin() ) {
        return;
    }
    show_admin_bar( false );
}
add_action( 'after_setup_theme', 'matt_watson_remove_admin_bar' );

5. Custom Conditional Statements for WordPress Stylesheets

Sometimes, you need to load specific stylesheets based on certain conditions, such as the browser version. This is particularly useful for older browsers like Internet Explorer.

This snippet enables conditional loading of stylesheets using the style_loader_tag filter. A guard ensures the custom logic only applies to the desired stylesheet.

function matt_watson_custom_style_loader_tag( $tag, $handle ) {
    if ( 'ie-8-plus' !== $handle ) {
        return $tag;
    }
    return "<!--[if gt IE 8]><!-->$tag<![endif]-->";
}
add_filter( 'style_loader_tag', 'matt_watson_custom_style_loader_tag', 10, 2 );

6. Extend the WordPress Customiser Using JavaScript

The WordPress Customiser is a powerful tool for making theme adjustments, but you may need to extend its functionality to create custom sections or panels.

This snippet demonstrates how to extend the Customiser using JavaScript, providing more flexibility in tailoring it to fit your theme or plugin’s needs.

const { customize } = wp;

customize.bind( 'ready', function () {
    if (!customize.panel) {
        return;
    }

    const panelKey = 'mattwatson-customizer-panel';
    const sectionKey = 'mattwatson-customizer-section';

    customize.panel.add( new customize.Panel( panelKey, {
        title: __( 'Matt Watson Panel', 'mattwatson' ),
        priority: 1000,
     } ) );

    customize.section.add( new customize.Section( sectionKey, {
        title: __('Matt Watson Section', 'mattwatson'),
        panel: panelKey,
    } ) );
});

7. Add a Custom Settings Link to Your WordPress Plugin

Adding a settings link to your plugin’s listing in the WordPress admin interface can make it easier for users to find and adjust the plugin’s settings.

This snippet shows how to add a custom settings link directly in the plugin list, improving the user experience by reducing the number of steps needed to access settings.

function matt_watson_plugin_settings_link( $links ) {
    if ( ! is_array( $links ) ) {
        return $links;
    }
    $label = esc_html__( 'Settings', 'mattwatson' );
    $slug  = 'mattwatson_plugin_settings';

    array_unshift( $links, "<a href='$slug'>$label</a>" );

    return $links;
}
add_action( 'plugin_action_links_' . plugin_basename(__FILE__), 'matt_watson_plugin_settings_link', 10 );

By applying these SEO and interface customisation tips, you can enhance your WordPress site’s performance, user experience, and overall flexibility. Whether you're managing large amounts of content or improving the backend interface, these snippets provide efficient solutions for common WordPress challenges.

(I’ve gathered these trusty code snippets from some of my older blog posts. Some might be a bit old, but they might still come in handy.)

1. Busting Cache in getEntityRecords

When working with dynamic blocks that rely on fetching posts or data, you may encounter issues where outdated data is cached, making your content appear stale. This can be particularly problematic when you’re fetching frequently updated content. The getEntityRecords cache in the Block Editor can sometimes keep old data around longer than you’d like.

This snippet shows you how to bust the cache for getEntityRecords, ensuring that the content on your site is always up-to-date, especially after creating or editing posts.

wp.data.dispatch('core').receiveEntityRecords('postType', 'post', [], {}, true);

2. Hooking into the Save Action

In some situations, you may want to trigger additional actions whenever a post is saved, such as updating external services, sending notifications, or performing some custom processing. Unfortunately, the Block Editor doesn’t provide a simple hook to intercept the save action by default.

This snippet listens for the post-saving process and allows you to hook into that event, enabling you to run custom code every time a post is saved, ensuring you can automate processes as needed without manual intervention.

import { select, subscribe } from '@wordpress/data';

subscribe(() => {
    const isSavingPost = select('core/editor').isSavingPost();
    const isAutosavingPost = select('core/editor').isAutosavingPost();

    if (isAutosavingPost && !isSavingPost) {
        return;
    }

    // Your custom action here
});

3. Creating Custom Block Categories

With a growing number of blocks in the Block Editor, it can become increasingly difficult to locate specific blocks, especially custom ones you’ve developed. By default, all blocks are placed into general categories, making it harder to organise them.

This snippet demonstrates how to create a custom block category, allowing you to organise your blocks better. It not only improves the workflow for developers but also helps users find and use your blocks more efficiently.

function matt_watson_block_categories($categories) {
    return array_merge($categories, [
        [
            'slug'  => 'matt-watson-blocks',
            'title' => __('Matt Watson Blocks', 'mattwatson'),
        ],
    ]);
}
add_filter('block_categories_all', 'matt_watson_block_categories', 10, 2);

4. Fetching Posts with getEntityRecord

Fetching individual posts by their ID in the Block Editor can be tricky for developers accustomed to using the get_post() function in classic WordPress. The Block Editor uses getEntityRecord() instead, which offers a more modern approach for fetching data.

This snippet shows how to use getEntityRecord() to retrieve a specific post by its ID in the Block Editor, making the transition from classic WordPress development smoother.

const post = wp.data.select('core').getEntityRecord('postType', 'post', 42);

5. Querying Posts with getEntityRecords

If you’ve ever missed the flexibility of WP_Query when working in the Block Editor, getEntityRecords() can provide a similar experience. This function allows you to query posts and custom post types using parameters such as post status or pagination.

This snippet demonstrates how to retrieve posts based on a specific status and limit the number of posts returned, offering an efficient way to handle content querying in the Block Editor.

const posts = wp.data.select('core').getEntityRecords('postType', 'post', {
    status: 'draft',
    per_page: 2,
});

6. Updating Post Meta with editPost

In the past, updating post meta in WordPress typically involved using PHP’s update_post_meta() function. With the Block Editor, you can now update post meta directly using the editPost function from JavaScript.

This snippet shows how to update the metadata of a post within the Block Editor interface, keeping your workflow modern and efficient without needing to switch back to server-side PHP.

wp.data.dispatch('core/editor').editPost({
    meta: {
        matt_watson_meta_key_example: 'Example Value',
    },
});

7. Find Posts with Specific Blocks in WordPress

If you need to identify posts containing a specific block, this snippet can help. It runs a WP_Query to search for posts that include a block by its namespace and block name. This can be useful when you want to apply changes or track down posts that contain a certain block across your site.

$posts = new WP_Query([
    'post_type'   => 'any',
    'post_status' => 'any',
    's'           => 'wp:some-block-namespace/block-name',
]);

8. Add Font Family Support to the Core Heading Block

Extending core blocks can improve design flexibility without needing to create new custom blocks. By using the block_type_metadata_settings filter, this snippet enables font family support for the core Heading block. It modifies the block settings to allow users to select custom font families, making your Heading blocks more versatile in terms of typography options.

function add_font_family_support(array $settings, array $metadata) {
    if ($metadata['name'] !== 'core/heading') {
        return $settings;
    }

    $settings['supports']['typography']['__experimentalFontFamily'] = true;
    $settings['supports']['typography']['__experimentalDefaultControls']['fontFamily'] = true;

    return $settings;
}

add_filter('block_type_metadata_settings', 'add_font_family_support', 10, 2);

Whether you're fixing outdated data in blocks or customising your Block Editor environment, these snippets will make your work easier and more efficient. A well-optimised Block Editor can significantly improve your workflow, saving you time and frustration in the process.

(I’ve gathered these trusty code snippets from some of my older blog posts. Some might be a bit old, but they might still come in handy.)

1. Ensure Bing Knows Your Languages

Bing doesn’t always automatically recognise the different languages used on your multilingual website. This can affect how well your pages perform in search results, particularly in non-English languages.

This code snippet solves this by adding the appropriate language meta tags to your site’s header, allowing Bing to understand the various languages your site uses and serve the right content to users.

function matt_watson_bing_compatible_wpml_header() {
    if ( ! function_exists( 'icl_get_languages' ) ) {
        return;
    }

    $langs = icl_get_languages();
    if ( empty( $langs ) ) {
        return;
    }

    foreach ( $langs as $lang ) {
        echo '<meta http-equiv="content-language" content="' . esc_attr( $lang['code'] ) . '"/>' . "
";
    }
}
add_action( 'wp_head', 'matt_watson_bing_compatible_wpml_header', 0 );

2. WPML + Bing = A Match Made in Headers

When your WordPress site supports multiple languages, it’s important to tell search engines the language of each individual page to prevent them from misinterpreting your content. This code snippet helps by adding Content-Language meta tags to your posts.

The snippet checks the current post and outputs the language code only if it matches the current language context. This ensures that Bing correctly identifies the language of each page it crawls.

function matt_watson_wpml_bing_compatible_header() {
    if ( ! function_exists( 'icl_get_languages' ) || ! is_singular() ) {
        return;
    }

    $langs = icl_get_languages();
    if ( empty( $langs ) ) {
        return;
    }

    $current_post_id = get_the_ID();

    foreach ( $langs as $lang ) {
        $id = icl_object_id( $current_post_id, get_post_type(), false, $lang['code'] );
        if ( ! $id || $id !== $current_post_id ) {
            continue;
        }
        echo '<meta http-equiv="content-language" content="' . esc_attr( $lang['code'] ) . '">' . PHP_EOL;
    }
}
add_action( 'wp_head', 'matt_watson_wpml_bing_compatible_header', 0 );

3. Set the Right Content Language for Browsers

Browsers and crawlers rely on server responses to determine the correct language of your content, but WPML doesn’t automatically send this information in the HTTP headers. This can lead to browsers and crawlers incorrectly interpreting the language of your pages, especially when serving non-default languages.

The provided code snippet adds the correct Content-Language header to your server responses, ensuring that both browsers and search engines accurately detect the language of the page.

function matt_watson_wpml_set_content_langauge( $headers ) {
    if ( is_admin() || ! defined( 'ICL_LANGUAGE_CODE' ) ) {
        return $headers;
    }

    $headers['Content-Language'] = ICL_LANGUAGE_CODE;
    return $headers;
}
add_filter( 'wp_headers', 'matt_watson_wpml_set_content_langauge', 0 );

4. Add Alternate Language Links to Yoast Sitemaps

When using Yoast SEO to manage sitemaps on a multilingual site, it’s crucial to inform search engines about the alternative language versions of each page. However, Yoast doesn’t automatically include these alternate links in the sitemap when WPML is involved.

The following code snippet enhances Yoast’s sitemaps by adding alternate language links. This tells search engines that each page has a corresponding version in other languages, helping them to index the right content for each region.

function matt_watson_yoast_wpml_alternate_links_to_sitemap( $url, $type, $post ) {
    if ( ! function_exists( 'icl_get_languages' ) || empty( $post ) ) {
        return $url;
    }

    $langs = icl_get_languages();
    if ( empty( $langs ) ) {
        return $url;
    }

    $id          = ( 'post' === $type ) ? $post->ID : $post->term_id;
    $object_type = ( 'post' === $type ) ? $post->post_type : $post->taxonomy;

    foreach ( $langs as $lang ) {
        $translated_id = icl_object_id( $id, $object_type, false, $lang['code'] );
        if ( ! $translated_id || $translated_id === $id ) {
            continue;
        }
        $link = ( 'post' === $type ) ? get_the_permalink( $translated_id ) : get_term_link( $translated_id );
        $url['wpml']['xhtml:link'][] = '<xhtml:link rel="alternate" hreflang="' . esc_attr( $lang['code'] ) . '" href="' . esc_url( $link ) . '"/>';
    }

    return $url;
}
add_filter( 'wpseo_sitemap_entry', 'matt_watson_yoast_wpml_alternate_links_to_sitemap', 100, 3 );

5. Sitemaps per Translation with WPML and Yoast SEO

When managing a multilingual site, generating a single sitemap might not be enough, as each language version of your site should have its own sitemap. This ensures search engines fully crawl all translations and index the correct language versions.

The following code snippet modifies the Yoast SEO sitemap query to generate separate sitemaps for each language, based on the current language context of WPML. This allows search engines to accurately map out each language version of your content.

function matt_watson_yoast_wpml_sitemap_per_translation( $join, $type ) {
    global $wpdb, $sitepress;

    if ( ! isset( $sitepress ) ) {
        return $join;
    }

    $lang = $sitepress->get_current_language();
    return $wpdb->prepare(
        "JOIN {$wpdb->prefix}icl_translations ON element_id = ID AND element_type = %s AND language_code = %s",
        'post_' . $type,
        $lang
    );
}
add_filter( 'wpseo_posts_join', 'matt_watson_yoast_wpml_sitemap_per_translation', 10, 2 );

6. Create a Virtual File in WordPress Multisite

In a WordPress Multisite setup, you may need to generate virtual files that change based on the specific site being accessed. This could be useful for things like dynamic sitemaps or XML feeds.

The code snippet below adds a query variable and creates a custom rewrite rule to serve a virtual file dynamically. It ensures that each individual site in the Multisite network can have its own version of the virtual file.

The rewrites:

function matt_watson_sitemap_rewrites() {
    global $wp;
    $wp->add_query_var('map');

    if ( get_current_blog_id() == 1 ) {
        add_rewrite_rule( 'sitemap.xml$', 'index.php?map=sitemap', 'top' );
    }

    if ( get_current_blog_id() === get_id_from_blogname('fr') ) {
        add_rewrite_rule( '^sitemap-fr.xml$', 'index.php?map=sitemap-fr', 'top' );
    }
}
add_action( 'init', 'matt_watson_sitemap_rewrites', 99 );

An example of a virtual file creation:

function matt_watson_generate_sitemap() {
    $map = get_query_var( 'map' );

    if ( ! $map ) {
        return;
    }

    header( 'Content-Type: application/xml; charset=utf-8' );

    echo '<?xml version="1.0" encoding="UTF-8"?>';
    echo '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">';

    $posts = get_posts( [
        'post_type'      => 'post',
        'posts_per_page' => -1,
        'post_status'    => 'publish',
    ] );

    foreach ( $posts as $post ) {
        echo '<url>';
        echo '<loc>' . get_permalink( $post ) . '</loc>';
        echo '<lastmod>' . get_the_modified_date( 'Y-m-d', $post ) . '</lastmod>';
        echo '</url>';
    }

    echo '</urlset>';

    exit;
}
add_action( 'template_redirect', 'matt_watson_generate_sitemap' );

7. Disable the WordPress Multisite Activation Step

In a WordPress Multisite environment, the default process requires users to activate their accounts via an email confirmation link. This can be unnecessary if you're managing internal users or trusted accounts.

The following code disables the activation step, allowing users to be added and activated instantly without requiring an additional email verification.

function matt_watson_remove_wpmu_activation( $user_login, $user_email, $key ) {
    wpmu_activate_signup( $key );
    return false;
}
add_filter( 'wpmu_signup_user_notification', 'matt_watson_remove_wpmu_activation', 10, 3 );

With these seven code tweaks, your WordPress Multisite and multilingual setup will be much easier to manage. From improving Bing’s understanding of your language setup to simplifying user registration, these snippets will help you streamline your operations and ensure your site runs smoothly across languages and networks.

5 More WordPress Myths Busted

I continued debunking more WordPress myths, tackling topics like scalability, e-commerce, multilingual support, and plugin quality. Whether it’s a small blog or a complex enterprise site, WordPress can handle it all.

5 WordPress Myths Busted

Common myths about WordPress include being insecure, bad for SEO, or only good for blogging. I dive into why these are just misconceptions and how proper hosting and management make WordPress secure, scalable, and highly versatile.

Wholesome Publishing Plugin Featured on WP Tavern

My Wholesome Publishing plugin, designed to streamline editorial workflows in the WordPress block editor, was featured on WP Tavern. It highlights key features like per-block notes and draft blocks.

Creating a Custom Block for WP Owls

I walk through creating a custom “Owl-Link” block for WordPress using the Block Editor (Gutenberg). This post covers the difference between block patterns and custom blocks, and provides step-by-step instructions on building, styling, and implementing the block.

Developing with WordPress Gutenberg: Part 2

In this follow-up post, I explore advanced block creation using JavaScript and React. I cover the best practices for structuring and styling blocks while handling attributes and dynamic content in the Gutenberg editor.

Developing with WordPress Gutenberg: Part 1

In this introductory post, I focus on the basics of WordPress Gutenberg block creation, from setting up the development environment to understanding block structure. I guide developers on creating dynamic blocks using JavaScript and React.

Build a Plugin: WordPress Technical Agency Guide

This guide takes a deep dive into building WordPress plugins from a technical agency’s perspective. I cover the essentials, including planning, code quality, and long-term maintenance.

Theme Translation: WordPress Agency Guide

I discuss how WordPress agencies can efficiently translate themes to support multilingual websites. This includes using translation-ready functions, Poedit, and ensuring compatibility with multilingual plugins like WPML.

Creating a Task-Driven Public Sector Website

This post explores how to build task-driven public sector websites focused on user-centered design to improve accessibility and efficiency for users.

How Gutenberg Changes the WordPress Experience

I discuss how the Gutenberg editor revolutionised WordPress by introducing a block-based system, simplifying content creation, and how to prepare for its release.

Extending CMB2 Controls in WordPress

I explore how to extend CMB2 controls within WordPress to create more customisable and flexible meta boxes. I walk through how to add new field types and enhance the user experience for custom fields, offering practical examples and insights into CMB2’s versatility.

Those old posts you know and love me for? Don’t worry, they’re making their way over here, getting a fresh coat of paint with up-to-date examples (I mean, we’ve moved on from jQuery, right? Right?!).

Now, in case you’re wondering, “Is this the Matt Watson I know from the glory days of WordCamp Sheffield and those web engineering escapades?” Yes, indeed. I’ve been working in WordPress for nearly two decades, and with web technology for even longer — remember Webmasters? Back when one person was expected to design, code, optimise, and maybe even bring you a cup of tea while the server rebooted. Ah, simpler times… and by simpler, I mean impossibly stressful.

But this blog isn’t just a nostalgia trip. I’ve got some shiny new WordPress plugins in the works, and trust me, they’re not just going to sit there collecting dust (this time). I’ll be linking to them from here, along with a few side projects that might just make you giggle (or at least groan in amusement). Buckle up, because it’s going to be a quirky, clever, and code-filled ride!