WordPress Plugin Boilerplate Powered: a generator for PSR-4 plugins

What the generator produces and what you remove

WordPress Plugin Boilerplate Powered is described as a complete foundation for building WordPress plugins following the PSR-4 standard. The reasoning in the README is a candid observation about how the ecosystem works: every experienced WordPress developer reaches for the same libraries or the same snippets, and follows good practice while doing it, so the boilerplate and the generator assemble the whole thing instead of leaving each developer to search for it.

The decisive feature is the pruning step. The generator downloads the boilerplate and extracts it into a new folder, removing the parts you do not want. The list of what can be removed is the wpbp.json file, and the libraries and snippets below are grouped so that the same categories appear in both the generator and the documentation.

What remains after pruning is still substantial. The result carries Composer with PSR-4 support, extended beyond the usual so that classes load based on request type and folder structure, WebPack and Sass for the front end, GrumpPHP wired to run automatically on commit, and PHPStan for static analysis. There is a GitHub Actions workflow and a GitLab CI configuration.

That means the output is not a bare plugin folder. It is a project with a build step, a linting gate and a static analyser, and that is the trade the whole package makes.

The eight commands that produce a plugin

The README walks through the generator workflow as a numbered list, and it is worth following literally because the order matters.

wpbp-generator --json

That first command generates a new wpbp.json in the current folder. You then edit that file to your liking by removing what you do not want, and run the generator again.

wpbp-generator
composer install
npm install
npm run plugin-zip

The second generator call downloads WPBP, extracts it to a new folder, removes the unwanted parts, and creates the new plugin folder as a subfolder of the current working directory. You change into that folder, edit composer.json to set the versions and packages you want, then install the PHP dependencies with `composer install`, which pulls in the dev files too. For production the README says to run the other two commands instead.

composer --no-dev update
composer dumpautoload -o

The first updates Composer without the dev files, and the second optimises the autoloader, which the README links to the Composer documentation on autoloader optimisation. The Node side follows with `npm install` for the packages and `npm run plugin-zip` to build the distributable archive. A dry run of the packaging step is available through `npm pack --dry-run`, which is how you check exactly which files will be zipped.

One instruction matters more than the rest. The README reminds you not to edit the vendor or node_modules folders, because they are overwritten on updates.

The bundled libraries and what each one is for

The library table is the reason to look at this project, because it is a curated set of WordPress components that the maintainers have already chosen.

On the WPBP side there is PointerPlus for a wizard-like system in the WordPress admin, CronPlus for adding and removing cron jobs, Widgets-Helper for creating powered widgets, Page-Madness-Detector to detect whether a site is running a page builder, Template for loading template files with autosearch and a multilanguage folder for email templates, Debug as a Query Monitor wrapper, CPT_Columns to improve the custom post type list in the backend, and i18n-notice for handling internationalisation based on the Yoast i18n module.

The other column is drawn from the wider ecosystem: CMB2 for metaboxes, custom fields and forms, micropackage/requirements as a requirements checker, inpsyde/assets for scripts and styles, origgami/CMB2-grid for grid columns, johnbillion/extended-cpts for extended custom post type and taxonomy functionality, Freemius' WordPress SDK for subscription-based business models, wpdesk/wp-notice for admin notices, julien731/WP-Review-Me for asking users to leave a review, stevegrunwell/wp-cache-remember for the object cache and transients, Seravo/wp-custom-bulk-actions for bulk actions on any post type, yahnis-elsts/plugin-update-checker for update checking across GitHub and GitLab, AyeCode/wp-super-duper for widgets, shortcodes and Gutenberg blocks, and decodelabs/tagged for markup generation in PHP.

Each entry is a starting point with starter code, and each is also something you can delete. The question for an adopter is which of these you will actually use, because each one kept is a dependency to maintain.

Snippets that arrive already integrated

Beyond the libraries there is a set of code snippets described as already integrated and removable through the generator.

On the backend side the README lists a bubble notification on pending custom post types, a donate link added into the plugin description inside the WordPress admin, block support, and import and export of settings. On the frontend side it lists a body class helper.

These are small, opinionated behaviours that would otherwise be rewritten in every plugin. That is the whole thesis of the project stated in miniature: the same small pieces get written again and again, so a project that ships them, and lets you delete the ones you do not want, saves the rewriting.

The cost of that convenience shows up in the generated code. A plugin that starts from this template carries a donate link in its admin listing and a notification bubble on pending posts unless the developer remembers to remove them, and those are exactly the kinds of things that reach production by accident. The generator's pruning step is the mechanism for avoiding this, so it is worth reading the diff between generated and pruned output before the first commit.

The README also notes that the documented steps may be incomplete and need expansion and testing, and mentions that you may want to run tests and Codeception, neither of which is set up for you.

Where the boilerplate is the wrong choice

The first limitation is the weight of the default output. A plugin built with the full library set brings in Composer, WebPack, Sass, GrumpPHP, PHPStan, a CI workflow and a Node toolchain to do something that might be a single admin page. For a small plugin the build and dependency surface will exceed the plugin itself.

The second is that the project is opinionated about structure, and it is opinionated about tooling you may not want. GrumpPHP running on commit and PHPStan in the pipeline are sensible defaults for a team, and a problem for a solo developer who just wants to ship a fix. The README does say the generator can remove the Sass and WebPack parts, but the other tools are part of what the boilerplate provides.

The third is the maturity of the documentation. The README carries an explicit warning that the steps may be incomplete and need expansion and testing, which is an unusual thing to state in your own project documentation and an honest signal that the workflow is not fully polished.

The fourth is release cadence. The recent releases are 3.3.3 from 2024-02-06, 3.3.2 from 2023-05-16 and 3.3.1 from 2023-01-18. The last push was on 2026-10-12, so the source is being worked on, but the tagged releases are two and a half years behind the tip, which means the documentation and the generated output may have drifted apart.

The fifth is the split of the project across repositories. The generator lives in WPBP/generator, the assets in WPBP/boilerplate-assets, and the project history and workflow are described in a wiki rather than in the repository, so the knowledge about how the pieces fit together is not versioned with the code.

How it compares with the original Boilerplate and with wp-cli scaffolding

The original WordPress Plugin Boilerplate is the direct ancestor and the comparison is instructive. The classic Boilerplate gives you a file tree with a main plugin file, an includes folder, an uninstall routine and a set of commented example files, and it deliberately keeps the dependency list empty. You get structure and no opinion, which is easy to reason about and easy to throw away.

This project inverts that. Instead of an empty tree with examples, you get a working dependency stack that is assembled from a curated table. The difference in approach is that the classic boilerplate asks you to copy, while this asks you to configure and prune, and the generator does the assembling.

The second comparison is with a scaffolding tool such as wp-cli scaffolding or a project generator like Cookiecutter, which produce a minimal skeleton without a dependency policy. Those are lighter and faster, and they leave the choice of libraries entirely to you. The trade is that you lose the curated table, which is the part of this project that is genuinely hard to reproduce, since it encodes which WordPress libraries work together and which are maintained.

A third angle is a plugin framework such as Bedrock or Roots, which go further in the other direction: they impose a full stack, configuration via environment files, and a deployment model. This project stays closer to a starter kit, and the difference is that you can strip it back to a small plugin while a framework assumes you want the whole stack.

Licence, maintenance and what to verify after generating

The licence is GPL-3.0, with the terms in the LICENSE file at the root of the repository. That matters more than it does for a typical library, because a WordPress plugin distributed to the public directory is usually expected to carry a GPL-compatible licence, so the choice here lines up with how plugins are normally released.

The repository is not archived and the last push was on 2026-10-12, so the project is being maintained, with a wiki holding the project history and the workflow, a ChangeLog.md at the root, and a CONTRIBUTING.md.

After generating, there are four things worth checking before the first commit. Read the diff between the generated tree and the pruned tree to confirm the removal worked as intended, since the snippets listed in the README include visible admin behaviours. Run the lint and static analysis pipeline once to see whether GrumpPHP and PHPStan pass on the starting code or only on code you have edited. Check the Composer scripts and the GitHub Actions workflow, since the CI definition is part of what you inherit. And confirm the Node build produces a plugin zip that contains what you expect, using the `npm pack --dry-run` check the README suggests.

The last point is the one most likely to cause a quiet problem. The generated project is a starting point with real code in it, not a template that has been reviewed line by line, and the first review of a plugin is much cheaper than the second.

Editorial conclusion

WordPress Plugin Boilerplate Powered fits a developer or team that keeps writing plugins with the same libraries and wants them assembled and wired into CI rather than copied by hand, and who is prepared to read the generated code before shipping it. It is a poor fit for a one-off plugin, where the generator and the dependency tree cost more than the boilerplate saves, and for a project that wants no build step at all, since the Sass and WebPack pieces are optional but present by default. Before generating, decide which of the bundled libraries you actually want, since every one you keep is a dependency you will maintain, and check the generator's own warning that the documented steps are incomplete and untested.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. WPBP/WordPress-Plugin-Boilerplate-Powered on GitHub