If WordPress hadn’t been such an approachable way into web development, back when I started editing functions.php in WordPress 2.7 via ftp, I wouldn’t have the career, life and friends I have today. That’s huge for me. I love the folks I’ve met through this community and I love sitting at home, listening to my music and playing with my computer.
WordPress development has evolved a lot since I started making WordPress plugins. For the last four to five years WordPress development has been “modernizing” — using a complex React client and plugin developers often want to embrace modern PHP practices without straying too far from “The WordPress way.”
I believe that’s largely good. But this increases the learning curve for new WordPress developers. It also leaves a lot of new and veteran developers feeling left behind. As my friend Chris, wrote recently:
Most of the response on Twitter to Chris’ post was strongly agreeing. Many others questioned if they could have gotten into WordPress, if there had been so much extra stuff to do before doing their job. I know the answer for me is likely “no”.
Look, I like messing with all the infrastructure around coding, setting up CI, webpack, Docker, etc. — that’s fun for me. But, when I want to build a plugin, I don’t want to mess with all of that, I just want to get the work done.
This problem has bothered me for years. I think, when appropriate, WordPress developers can benefit from all of this extra tooling. At the same time, it’s burdensome, and hard to set up and maintain. So I started working on what I now call Plugin Machine.
I called it Plugin Machine because it builds plugins. Also, I’ve grown to like names that describe what’s in the tin. This machine helps you create the start point for new plugins, add new features to existing plugins, as well as packaging plugins for release. There is a web app you can use to create and modify plugins, as well as a CLI and API.
The Rabbit Hole
Earlier this year I wanted to build a quick prototype of an idea I had for a WordPress plugin. I even had a boilerplate to start from, but it was a little out of date and I needed some different features. My first prototype was a bash script. As I started adding more options, I realized an API and/ or web app made more sense.
I made a quick prototype in the spring. I had to stop working totally for a few months due to a really bad flare up of tendonitis. I went down to working part time at my job and stopped working on this project.
I spent several months doing twice-weekly hand therapy and rearranging my life and work to put less strain on my wrists and hands. In addition to physical changes, for example a split keyboard, I focused on optimizing vsCode. When I was able to start working on a side project again, I couldn’t stop myself from working on Plugin Machine, so I did.
For the last few months I’ve been testing Plugin Machine on my own projects and letting a few people try it out. It will be ready to launch soon, but I wanted to be able to share more about how I built this thing and what I’ve learned about WordPress development. More importantly, I’d like to know what others think about how this could be valuable to them.
My goal is to improve the developer experience for WordPress developers. That’s the problem space I’m working in. Plugin Machine is one attempt to help solve these issues.
What I Want for WordPress Developers
One of the things I love about being a WordPress developer is its gotten me into other frameworks, like React and Laravel. Many of the WordPress developers I’ve shown prototypes of Plugin Machine to have said something like “this is artisan for WordPress.” Artisan is the CLI for Laravel, and its one of the things that makes working with Laravel such a joy.
Given the scale of WordPress, and the commonality of these problems, better solutions should exist. I think I’m the perfect person to work on these problems. I’ve worked for and even co-owned plugin companies, worked at a large agency, contributed to open source, and written a bajillion articles about WordPress development. Also, I’m totally a nerd for this stuff.
I am very interested in helping WordPress developers build more stable plug-ins and helping to solve ecosystem-level problems, for example performance issues caused by commercial plugin updates. Developer tooling like I’m interested in building — aimed at engineers, not site builders — is under invested in. It’s a smaller market. I believe the downstream effects are huge for those who serve site builders and spend too much time on bugs, conflicts and word that eats up valuable time and resources that could be spent inviting.
We expect our developer tooling to be fully featured, have lots of flexibility and not be tied to one host, then it can’t be free. This is a project that requires a lot of time, and some of my money to run. There isn’t a feasible path to fund that besides charging for it. There are not any entities in our industry that invest in solving these problems, in a way that is flexible and not strongly tied to their platform.
The honest reason I built this, besides not being able to stop myself on a nerd level, is I want to make it easier for the next person who wanders randomly into the WordPress space and gets super excited about plugin development, to be able to build with all of the latest and greatest.
I left my most recent job a few months ago and have been doing freelance work and working on Plugin Machine. It can create plugins with blocks, editor sidebars, custom admin pages, remote updaters, common actions and filters, custom content types, local development, tests, Github actions, and many other things.
The UI for creating plugins, managing features, modifying generated files and downloading development versions of the plugin is nearly done. I am also making good progress on the CLI. I am almost ready to start early access. If you’d like to be the first to know when early access is available and receive other updates, sign up for the mailing list here. ?