WordPress custom plugin

This is a decommissioned project, presented with permission.

My role: I originated the codebase and led a team of engineers to develop and maintain it. I mentored the team on using WordPress features to customize.

Overview

Coupled with a GatsbyJS frontend, this custom WordPress plugin provided SEO-focused features not otherwise available, and facilitated Yoast-managed features so they could be delivered via GraphQL (using WPGraphQL plugin).

For instance, we added an Update Date field. WordPress maintains a creation date, and modification date. However, that mod date changes whenever even the smallest change is made. The Update Date is manually entered when significant content updates are made, so we can make that information available to search engines.

Development approach

All features are custom, using core- or vendor-provided hooks. We do not use Advanced Custom Fields*.

At first, we attempted to make all custom editor features WYSIWYG, closely resembling the published product. As time progressed, and business demanded tighter turnarounds, we relaxed that requirement and introduced a hosted preview feature.

The number of end users was small, so we felt it was acceptable to forego automated tests for editor features (other than units). We did write automations for custom GraphQL features.

WordPress core

• We introduced custom blocks using the Block Editor API.
• We used Block Patterns for reusable page section layouts.
• For inputs on non-editorial pages (e.g. taxonomies & author bios), we used old-school PHP / TinyMCE techniques.
• We made use of WordPress core hooks to provide things like custom post types and admin-panel enhancements.

Yoast (a.k.a WordPress SEO)

• We used Surfaces API where possible.
• For other features, it was necessary to scour the Yoast codebase to find applicable hooks.

WPGraphQL

• Made use of a robust PHP hook architecture, to provide new objects and fields.
• All custom fields were grouped within a cdmFields locator.

Subsequent advancements

In later projects, we borrowed some from this project structure, with advancements:

• I introduced a monorepo structure, combining this with the Frontend and other workspaces.
• I took advantage of the newer wp-env Docker-based local environment toolkit.

*Why not use ACF?

• I don't feel ACF's APIs offer enough convenience to lock us into a significant third-party dependency.
• I'm especially cautious in light of the current feud between Automattic and WPEngine
• It's important to maintain distinct structure using code, and content using database (though not always strictly possible). ACF obliterates that line.