WordPress plugin development

WordPress supply chain security: auditing plugins and themes Every plugin and theme is code from someone else running with full access to your site. The supply chain risk is real: a plugin author’s account is compromised and a malicious update goes out, an abandoned plugin is bought and “updated” with a backdoor, or a premium…

Pest for WordPress plugin tests Pest is a testing framework on top of PHPUnit with a shorter syntax: tests are closures with a description instead of methods in classes, and expectations read like sentences. For WordPress plugins, it runs on the same WordPress test suite and bootstrap as PHPUnit, so an existing setup can switch…

WordPress 6.9 for developers: the Abilities API, notes and on-demand styles WordPress 6.9 (December 2025) brought visible editor features, notes on blocks for editorial feedback and new blocks such as Accordion, and two developer-facing changes worth planning for: the Abilities API, a registry where plugins describe what they can do in a machine-readable way, and…

Toolbar buttons and sidebar settings for blocks: BlockControls and InspectorControls A custom block puts its settings in two places: quick, frequent actions in the block toolbar above the block, everything else in the settings sidebar. The @wordpress/block-editor package provides slots for both, BlockControls and InspectorControls, and the same slots can be used to add a…

A security review of a WordPress plugin with PHPCS and Semgrep Most vulnerabilities in WordPress plugins belong to a few patterns: output without escaping, input without sanitizing, a missing nonce or capability check, SQL built from variables, a file path from a request. Static analysis tools find many of them in minutes, before a human…

PHP 8.4 for WordPress plugin developers PHP 8.4 (November 2024) has two features that change how classes are written, property hooks and asymmetric visibility, a set of small helpers like array_find(), and one deprecation that affects a lot of existing plugin code: implicitly nullable parameter types. A plugin that should run without notices on hosts…

WordPress HTTP API: wp_remote_get() and wp_remote_post() best practices The WordPress HTTP API (wp_remote_get(), wp_remote_post(), wp_remote_request()) wraps the transport (cURL or PHP streams) in one interface with the same arguments and the same response format everywhere. Used carelessly it gives silent failures, hung pages and API rate limits; used well it needs four habits: check errors,…

GitHub CLI (gh) for plugin release automation A plugin release on GitHub is a series of clicks: check that CI is green on the release commit, create the tag, write the release notes, upload the ZIP, maybe update a draft into a final release. The GitHub CLI gh does each of these in one command,…

REST API controllers with WP_REST_Controller A plugin’s first REST route is usually a register_rest_route() call with a closure. By the fifth route, permission checks, argument definitions and response formatting are copied around, and ?_fields= or context=edit do not work like in core routes. Core’s own endpoints are built on WP_REST_Controller, and a plugin can extend…