The WordPress plugin boilerplate in 2026: should you still use it?

The WordPress Plugin Boilerplate from 2014 taught a generation of developers how to structure a plugin. In 2026, with AI scaffolding a plugin in seconds, is it still worth starting from? The honest answer is more interesting than yes or no.

What the boilerplate gave us

Back when WordPress plugins were a mess of functions.php dumps, the boilerplate enforced a few things that were genuinely missing: a clear separation between admin and public functionality, a loader class for hooks, an uninstall file, an internationalization setup, and a consistent naming convention based on your plugin slug.

Two of those things are still valuable. The separation of admin and public code prevents a whole class of bugs where admin-only logic accidentally runs on the front end. The uninstall file keeps your database clean. The other three are arguably obsolete: the loader class is a solution to a PHP 5.2 problem that does not exist anymore, internationalization in 2026 is better handled through the block editor's JSON files, and naming conventions are enforced by any modern linter.

What AI generation gives you instead

When you describe a plugin to an AI agent, you skip the scaffolding entirely. You get only the classes and files the plugin actually needs. For a plugin with three public shortcodes and no admin, you do not inherit six empty class stubs you will never fill. You get what you asked for.

This is not a small thing. I have seen boilerplate plugins with 40% of their files empty because the original author never wrote that part. Those empty files become code smell: readers assume they are important, they show up in searches, they confuse future maintainers.

Where the boilerplate still wins

If you are building something complex with a team of developers who are not all senior, the boilerplate gives them a consistent map. Everyone knows where the admin code goes. Everyone knows where to add a new hook. The uniformity has value that is hard to replicate with AI output, which is fine at producing a good structure but will not remember what structure you used last time without being told.

The boilerplate also makes onboarding easier. A new dev can read a single boilerplate readme and know the architecture of any plugin built on it. AI-generated plugins, even by the same person using the same prompts, tend to vary slightly in structure.

The hybrid approach I recommend

Have a team convention document. Not a full boilerplate, but a page or two describing how you want plugins structured: where admin code goes, how to handle options, how to wire cron, how to handle i18n. Pass that convention as context to your AI agent.

The AI will then produce code that matches your team's conventions without you maintaining 40 empty files in a template repo. This is the best of both worlds: AI speed plus team consistency.

A concrete example

My team's convention document is 600 words. It says things like "put all WordPress options behind a YourPluginName_Options::get(key) facade so we can migrate storage later," and "all REST endpoints live in includes/rest/ with one class per endpoint family." The AI follows these every time because they are part of the prompt context.

I have not used the classic boilerplate in over a year. I have also never had an inconsistency complaint from a teammate on one of my generated plugins, which was the thing the boilerplate was solving for.

What about the block editor?

This is where the boilerplate shows its age most. The WP Plugin Boilerplate was designed when blocks did not exist. Trying to bolt blocks onto it feels like a retrofit. AI-generated plugins that include blocks tend to follow the patterns from @wordpress/create-block, which is now the closer-to-official standard for that part of the codebase.

If your plugin is primarily block editor extensions, skip the boilerplate entirely. The block editor has its own conventions and they do not mesh well with the 2014 scaffold.

Uninstall and deactivation are still non-negotiable

Whether you use a boilerplate or generate with AI, make sure your plugin actually cleans up after itself. Options, custom tables, cron events, transients. The number of plugins I have audited that leave database cruft behind after deactivation is depressing. The boilerplate had an uninstall.php stub. Whatever you do, fill it in.

So: should you still use it?

If you are new to plugin development and have never shipped one, read the boilerplate source. Understand why it is structured the way it is. Then throw it away and generate your first plugin with AI, using the boilerplate's architectural lessons as context. You will end up with something cleaner and more specific than either would have produced alone.

If you have a team, the real work is in documenting your own conventions, not in cloning someone else's. The boilerplate cannot know your team's preferences. An AI agent, given your conventions as context, can apply them perfectly on every new plugin.

The boilerplate was a good answer to a real problem in 2014. The problem has moved. The answer should move too.