Plugin development is key for anyone developing for WordPress. While themes are often created by agencies and web designers, plugins are definitely a programmer’s task.

The structure for put up a new plugin in WordPress, and many other CMS platforms, is stupidly simple. All you need is a main file that brings, on top, the plugin info as a comments section.

Having that said, by browsing Github it is possible to find uncountable boilerplates and starters for those thinking of developing their first plugins.

Although many come with sophisticated structures and tools, after sometime making your own plugins and extensions you shall get to the same conclusion that I got. The simpler is always better.

Why so many boilerplates?

Every programmer has his own recipes. Usually, in the spirit of community, we share our recipes in places like Github.

So, for each boilerplate you can find, there’s a programmer behind it. With different views and approaches, and armed with his own toolbelt to create new scripts and plugins.

Some of them, like me, make use of dependency managers, so you will find files like composer.json or package.json within the code.

Some use an OOP approach, then you should find a number of classes, interfaces and abstracts around. Others may opt for a functional approach, and then the boilerplates will be focused on hooks and functions.

Some already bring sample coding and hooks for very common tasks in plugins. Adding new post types, admin menus, metaboxes and so on.

And then there are a few boilerplates that just serve those in very specific environments. Stuff using the latest frontend tool like Webpack, React, Svelte and many more can be easily found nowadays.

Looking through their code is a very interesting way of learning new competencies. However, as a way of building your own plugins, I’d honestly avoid starting from any of those boilerplates.

Searching for a signature

In 2022, coding is perhaps the most searched competency in any part of the world. While it sounds promising, we need to remember another aspect of the modern times: there are tens or maybe hundreds of millions who can code.

The most successful and efficient are those who create their own strategies, approaches and techniques. And of course, those whose boilerplates we just mentioned above.

My own “boilerplate”, for instance, definitely comes with a composer.json. I prefer to use for autoloading. Also, any plugin or theme of mine will see namespaces instead of terrible file and class names.

As my plugins usually start with a single instance that executes all other classes and processes, I rarely make use of register_activation_hook or register_deactivation_hook – once it is deactivated all processes cease. The exception would be something that creates database tables, for example.

Sometimes I need views, so most plugins and themes that I work at will bring Webpack or Laravel Mix configuration,

A test tool and files like .gitignore and the plugin readme complete the package. And that’s all. No need of ready-to-copy recipes for custom post types, menus, taxonomies or so. Especially because I prefer an OOP approach, and most boilerplates don’t follow the same thinking.

Saving some time

Ok, some may argue that boilerplates save time. They do, but just if you don’t need to rewrite code for matching your needs.

But if you want a starting point, again I’d look for the simple. And after trying a lot of boilerplates, I am still convinced that WP-CLI’s scaffolding tool has the best plugin starter.

Just open the command line and use the following command, with “prompt” as option. Like this:

wp scaffold plugin --prompt

Then, you will be asked for some info that will be in the plugin header: slug, name, description, author and so on. Also, the generator will ask you whether you want test tools included, CI and if you want to activate the plugin on generation. The boilerplate generated will include the following files:

  • plugin-slug.php is the main PHP plugin file.
  • readme.txt is the readme file for the plugin.
  • package.json needed by NPM holds various metadata relevant to the project. Packages: grunt, grunt-wp-i18n and grunt-wp-readme-to-markdown. Scripts: start, readme, i18n.
  • Gruntfile.js is the JS file containing Grunt tasks. Tasks: i18n containing addtextdomain and makepot, readme containing wp_readme_to_markdown.
  • .editorconfig is the configuration file for Editor.
  • .gitignore tells which files (or patterns) git should ignore.
  • .distignore tells which files and folders should be ignored in distribution.

Some other files may be included, if you opt for adding test tools to the plugin. In other words: this scaffold primarily focus on the plugin structure, and offers some basic tools for dealing with tests, version control, internationalization and the plugin info and description. It doesn’t influence or force your PHP code to go anywhere.