WordPress Plugin Suite | Five Plugins and a Shared Dev Workspace

The workspace

Building one WordPress plugin is easy. Building five and keeping them all to a consistent standard is a tooling problem, and it is the one most plugin work never solves.

The workspace is a parent directory holding shared dev tooling, with each plugin in it as an independent git repository. Composer and npm at the root provide the linting and test harness. A local WordPress runs under wp-env. PHPCS enforces coding standards across every plugin from one config. PHPUnit runs per plugin, or across all of them in sequence with a single command.

A scaffolder generates new plugins with the header, slug, namespace, constant prefix, PHPCS config, and initial commit already correct. That last part matters more than it sounds: the naming conventions in a WordPress plugin are load-bearing and tedious, and deriving them by hand is how you end up with a constant prefix that does not match the text domain.

Independent repositories per plugin with shared tooling at the root is the right shape here. Each plugin can be released, versioned, and installed on its own, while none of them carry their own copy of the dev dependencies.

Directory Core

The largest architectural piece. Directory Core is an entity-agnostic directory engine: custom post types and taxonomies, geocoding, location handling, slug management, a REST API, reviews and ratings, proximity search, and roles and moderation.

Entity-agnostic is the whole point. It was extracted from the restaurant-specific plugin behind MenuFindr after it became obvious that nothing in the hard parts of a directory is actually about restaurants. Geocoding an address, freezing a slug, moderating a review, and answering “what is near me” are the same problems whether the entity is a restaurant, a contractor, a venue, or a clinic.

Pulling that engine out of the restaurant code means the next directory is a configuration exercise rather than a rewrite. It also means the hard-won details, like the save-pipeline ordering and the frozen-slug behavior, get carried forward instead of reimplemented slightly wrong.

FSM REST Extensions

The most interesting plugin of the five, and the one that points where WordPress is going.

It exposes a set of site management capabilities, reading and writing Customizer CSS, flushing the block CSS cache, managing pattern collections, and full CRUD on theme elements. That part is ordinary. What is not ordinary is how it exposes them.

The plugin registers those capabilities as WordPress Abilities and serves them as named, typed MCP tools from a server running inside WordPress itself, over Streamable HTTP with application-password auth. An AI agent gets eight properly typed tools rather than a generic REST client and a prayer.

Destructive writes require confirmation

Every destructive operation in that plugin requires an explicit confirm: true in the call. Deleting an element, overwriting Customizer CSS in replace mode: none of them happen because a model produced a plausible-looking request.

This is a small thing that changes the risk profile entirely. An agent that hallucinates a delete call fails a schema check instead of removing a site element. The confirmation flag is not there to slow down a human operator, who will pass it once and move on. It is there so that the accidental version of the call is structurally different from the intentional one.

Writing CSS goes through WordPress’s own update function rather than touching the option directly, which means sanitization, revisions, and cache invalidation all keep working. Bypassing the core function would have been fewer lines and would have quietly broken the revision history that makes a bad CSS write recoverable.

The other three

MK Library REST Extensions is the narrower predecessor to FSM REST Extensions, exposing Customizer CSS and theme element display rules over REST for a single site’s automation toolchain. It is the smallest plugin in the set and it is the one that proved the pattern was worth generalizing.

Author Authority adds a responsive author box with social icons. Unglamorous, and it is the largest codebase of the five, which is a fair illustration of how much of plugin work is presentation, settings UI, and compatibility rather than core logic.

RSS Image Controls gives full control over featured images in RSS feeds: size, alignment, padding, click-through links, and enclosure tags. This one is a fork rather than an original build. It descends from “Featured Images in RSS for Mailchimp & More” v1.7.1 by 5 Star Plugins, rebranded with every formerly premium feature included free, with the provenance, the option-key migration map, and the compatibility shims all documented in the repository.

Why this is on a portfolio

The individual plugins vary in ambition. The workspace behind them does not, and that is the transferable part: a standard toolchain, a scaffolder that makes the boring conventions correct by default, a local WordPress that matches production, and linting and tests that run the same way for every plugin in the set.

The direction FSM REST Extensions points is the part worth paying attention to. WordPress sites are about to be operated by agents as well as by people, and the plugins that handle that well will be the ones that expose typed, permission-gated capabilities instead of leaving an agent to drive the admin screens. That is work I do.