WordPress development has evolved greatly nowadays, thanks to Gutenberg project we have now available node packages like @wordpress/scripts that includes tools for building assets, lint code and run automated tests. Also we have the @wordpress/env package that allow us include a WordPress development environment right in the root of our plugin project.

PHP ecosystem has evolved as well, while PHP in WordPress core is old and doesn’t seem that is going to change in the short term, nothing stops us to write modern PHP code in our plugins, following better practices like using Composer autoloader or Object-Oriented programming.

Modern JavaScript is not an exception, the days when jQuery was used for everything are gone, nowadays we are replacing its usage with vanilla Javascript and getting all the benefits that comes with the language.

In this article I’ll show you some of the tools and techniques used in Modern WordPress plugin development.

@wordpress/scripts

This node package allows us build our JavaScript and CSS assets, by default if expects a src folder with a block.js file but we can configure it based on our plugin needs, in the following example we are creating a webpack.config.js file, getting the default configuration from the package and then add our files, all of them are going to be complied and added to the build folder in the root of the plugin:

const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
const path = require( 'path' );

module.exports = {
	...defaultConfig,
	...{
		entry: {
			...defaultConfig.entry(),
			admin: path.resolve( process.cwd(), 'admin', 'admin.js' ),
			admin_style: path.resolve( process.cwd(), 'admin', 'style.scss' ),
			frontend: path.resolve( process.cwd(), 'client/frontend', 'index.js' ),
		},
	},
};

The package also includes tools for linting code and run tests, in the following article you’ll find an example showing how to write Playwright tests.

@wordpress/env

This package creates a local WordPress environment, it works great in combination with @wordpress/scripts as you can run tests against this environment easily.

I’ve found it easier to use than ddev, while it doesn’t include all the features out of the box, new ones are included over time like the latest addition of phpMyAdmin in version 10.14.0.

As it’s docker based you can add more containers to the network manually, for example if you want to include the mailhog service for checking emails you can first grab the network id created by @wordpress/env (docker network ls) and then use it while running the container:

docker run -p 8025:8025 -p 1025:1025 --network <your-network-id> mailhog/mailhog

Composer autoloader

One of the benefits of using Composer autoloader in your plugin is that you can get rid of all the PHP requires (require, include, …) that are spread all over the code base, once you have the autoloader in place you can get classes by name under its namespace.

Also you can remove prefixes in your class names, prefixes in class names were added before namespaces were included in PHP to avoid naming conflicts with other classes with the same name, here is an example how a prefixed class looks like:

if ( class_exists( 'My_Prefix_Settings', false ) ) {
	return;
}

class My_Prefix_Settings { ...

Using PHP namespaces you can get rid of the check for class existence and also remove the prefix:

namespace MyPrefix;

class Settings { ...

Here you have a video showing how to install, configure and use the Composer autoloader:

WordPress Coding Standards for PHP_CodeSniffer

This package is a collection of PHP_CodeSniffer rules to work with WordPress, we can use it in our plugin as a base and then add or exclude rules based on our needs.

It not only helps with code style and formatting but also promotes best coding practices and detecting bugs.

Rules can be configured in a phpcs.xml.dist file, in this example we are using the WordPress standard excluding a couple of rules:

<?xml version="1.0"?>
<ruleset name="WordPress Coding Standards">
    <rule ref="WordPress">
        <exclude name="WordPress.Files.FileName.NotHyphenatedLowercase" />
        <exclude name="WordPress.Files.FileName.InvalidClassFileName" />
    </rule>
</ruleset>

Here you have video showing how to install and configure WordPress Coding Standards for PHP_CodeSniffer:

That’s all for this article, we’ve walked through some modern development tools that we have available nowadays to include in our plugins, I hope that you’ve enjoyed it, see you in the next one!