A Workflow for Modern WordPress Plugin Development
☘ Clover is a new project we’ve been working on since last summer.
It is a goal of Roots to empower developers; this goal is infused into everything that we do and the Clover project is no different. When looking for ways to contribute to the WordPress development community, we found a need for a modern WordPress plugin development workflow which empowers developers throughout the process. Clover is our answer to that need.
Many of us have experienced the benefits of the features that Sage provides. Furthermore, many of us have also experienced the benefits of a workflow like Laravel or Ruby on Rails. Clover takes a lot of inspiration from these workflows and provides developers with everything they need to create WordPress plugins. The current feature set is as follows:
- A flexible frontend asset workflow (most likely Laravel Mix)
- Many Laravel Components like Blade templating for views and Eloquent as an ORM
- A PHP testing workflow
- A JS testing workflow
The structure of a Clover-based WordPress plugin reflects the structure of a package for Laravel. If you are familiar with Sage, this structure is almost the same:
plugin-name # → Root of your Clover-based plugin (should be renamed accordingly) ├── config # → Acorn config files ├── resources # → Plugin resources (not scaffolded for frontend-less plugins) │ ├── assets # → Plugin assets │ │ ├── fonts │ │ ├── images │ │ ├── scripts │ │ │ └── tests # → JS tests │ │ └── styles │ └── views # → Plugin views │ ├── admin # → Views for the WordPress dashboard │ └── public # → Views for the public frontend ├── src │ ├── Providers │ │ └── PluginServiceProvider.php # → Plugin service provider │ └── Plugin.php # → Main plugin class ├── tests # → PHP tests └── plugin-name.php # → Plugin entrypoint (should be renamed accordingly)
It would be wishful thinking for us to believe we could copy and paste Sage, make a few changes, and ship it as our new plugin boilerplate. As we began work on Clover, it quickly became clear that building a boilerplate for plugins would be different from building a theme boilerplate. Plugins and themes are built to fill different roles and therefore face different challenges.
Not all plugins are the same
Themes, and hence Sage, the Roots starter theme, have the same general goals and specific needs, which meant we were able to craft a specific workflow. Plugins, on the other hand, have wildly divergent needs and goals, so Clover must be more flexible. Many plugins won’t need a frontend workflow; others will need a robust front- and backend experience.
This means including a frontend boilerplate by default would be bloat for a smaller plugin and an obstacle for the development experience. Each component of Clover needs to be flexible enough to be easily included or excluded from a project, just like a plugin can be easily included or excluded from a WordPress site or application.
When you choose to create a WordPress plugin, you typically have a need for site functionality — a need that a boilerplate cannot predict. The shape of the boilerplate must be influenced by the goal of the plugin.
Not all plugins start with a solid goal in mind
In many cases, a plugin isn’t created with a solid goal in mind. With Clover, we hope to provide a workflow which adapts along with goals of the plugin you’re creating. You can start small and if the plugin needs to scale, Clover will make it easy to do so.
Or perhaps your plugin is outgrowing WordPress? Since Clover uses Acorn to borrow so much from Laravel, developers can be confident that if they need to scale into a full Laravel application much of the codebase will carry over with minimal changes.
Acorn, the foundation of Clover
Boilerplates should be lean as possible. Any time code is reused with no change it might as well be loaded as a dependency instead. This is especially true with more complex code which can become an obstacle for users of the boilerplate. Over the years, Sage has abstracted some of its reusable, unchanging code away from the boilerplate to its own library dependency called sage-lib.
Sage 9 depends on sage-lib to provide its Blade templating and asset manifest functionality. With the advent of Clover and with the upcoming Sage 10, sage-lib has been extended and reorganized into Acorn, a framework for plugins.
Acorn provides so much more than just Blade and asset manifest functionality. At its core, it is based on the same service container which powers Laravel itself, so you can seamlessly use many of the components and packages which already exist in the Laravel ecosystem. This empowers WordPress developers to take advantage of a lot of high quality code and avoid reinventing the wheel.
An Artisan-like interface
Artisan is a CLI helper used throughout the development of a Laravel app. Artisan lets you interact with the Laravel application and easily scaffold new features for it. Since a goal of Clover is to address the ambiguity of what a plugin looks like, a CLI like Artisan will be essential for this task.
The Clover CLI helper will provide similar function to Artisan and will allow you to create new plugins with the appropriate boilerplate to get started. For example, if you want to make a new plugin that does not include a frontend workflow, it could be as straightforward as running:
clover new name-of-plugin --without-frontend. Of course, we want to empower the developer throughout the process, so it would also allow you to scaffold that frontend later in the development of your plugin.
Perhaps your plugin needs to provide a new block to the Gutenberg editor? A Clover CLI would make it easy to scaffold that with a command like:
Right now the primary goal of our development is to realize the fullness of this new workflow. Once we have an adequate grasp of the workflow, we will begin work on the CLI helper.
For now, keep an eye out for the initial release of Clover. The best way to do that is to sign up for our newsletter or become a sponsor.