I’m discovering that I love writing plugins. I wrote my first public WordPress plugin, Display All Image Sizes, around two months ago, and just updated it with some UI improvements based on user feedback.
Writing and maintaining it has really brought home the power of open source in a new way. When hundreds of people are using your plugin, telling you where it’s broken, offering feature improvements, and reviewing it positively, it’s a really cool feeling—much cooler than staying strictly on the user end yourself.
This article is some general advice for WordPress developers who’d like to dip their toes into public plugin writing. I’ll cover how to find good problems, and how to approach both writing and supporting the plugin.
Know When You’re Ready
I’d say you’re ready to start writing public plugins when you can solve almost any novel client problem with custom code.
Don’t start writing plugins for the WordPress.org repository before you’re technically ready.
What’s the test for that? I’d say it’s as follows: “When you can solve almost any novel client problem with custom code.”
This means that you should have a good amount of experience writing working plugins for clients. For example, if your client’s theme needs a new widget area, your impulse should be to code it yourself, not to reach for some sort of “all-in-one widget builder” plugin.
Cheerful plug: If you want help getting proficient as a WordPress coder, check out Up and Running, our multimedia guide to theme and plugin development. The Deluxe package has a truly excellent plugin-writing walkthrough.
Pick the Right Problem to Solve
Whether your first plugin-writing experience is a pleasant one depends mostly on the problem you choose to tackle. Here’s what I think a good first plugin project looks like:
Has a Defined Success Point
Your plugin should attempt to do one well-defined thing.
Your plugin should attempt to do one well-defined thing. Display All Image Sizes has its goal right in the title: the plugin’s a success when the user can easily see all sizes of each image on the site. David’s plugins, Require Featured Image and Only One Category, are the same story.
Thinking this way will point you toward problems that have a single solution that is technical in nature—meaning you’ll get to experience the enjoyment of solving them. “Require all posts to have a featured image” passes this test; “create a better drag-and-drop page builder” does not.
Is Novel in Some Way
Look for little annoyances that cost you a few seconds each time, and are unsolved.
Bringing something new into the world may seem daunting, but it doesn’t have to be. Just try to keep track of the way you yourself use WordPress—look for little annoyances that cost you a few seconds each time. If, in trying to fix one of these annoyances, you spend a half hour searching through “almost-right” plugins and don’t find something that scratches the itch, there’s your thing.
Remember, a lot of plugins exist but don’t quite solve your problem, or haven’t been updated in a couple of years, or are a bit buggy. You can use those as a jumping-off point, and write something that very precisely solves your problem.
Bonus Points if It Solves an Existing Client Need
Client needs are often the best source of plugin ideas.
The needs that come up in client projects are often the best sources of plugin ideas, because they reflect what actual people with actual websites want and need.
Display All Image Sizes started out as a plugin for a client project: I was using lots of custom image sizes on the client’s site, and got really frustrated hunting for the sizes I needed.
The “post editor keyboard shortcuts” plugin I’m working on came about the same way: the client was entering a lot of data into custom fields, and I wanted to make it easy for him to save his progress without scrolling back up to hit “Save Draft.”
As you’re writing code for clients, try to note whether your solution might be more broadly applicable.
Writing the Plugin: Google Like Mad
Plugin writing should be largely a process of combining existing knowledge in new and helpful ways.
I approach plugin writing as asking a series of technical questions, whose answers I research intensively. Google does as good a job enabling this research as a hundred-billion-dollar search engine should.
For Display All Image Sizes, for example, I needed to know, “How can I get an array containing all the sizes of each image in WordPress?” So I started Googling things like “get all image sizes wordpress.”
The best answer I found, from Justin Tadlock in 2011, forms a big part of the plugin’s beating technical heart. However, it outputs size information to media pages only; I needed it to output to each image’s listing in the media library. Learning how to do that was another big round of Googling, which resulted in me learning a lot about the attachment_fields_to_edit filter.
After I’d done these two big pieces of learning, the creativity I needed to add was how to stitch them together. This was most of the trial-and-error that went into Display All Image Sizes, and it also involved a lot of very heavy Google searching.
I’d suggest you approach plugin writing similarly. You should be constantly referring to both the WordPress Codex and Stack Overflow, as well as any other sources that turn out to be helpful, based on intelligently written Google queries. This makes plugin writing a process of combining existing knowledge in new and helpful ways, rather than thrashing around in the dark.
Pay Attention to Feedback
I’ve found people’s feedback to be surprisingly thoughtful and helpful.
Once your plugin’s launched, pay attention to your ratings and reviews, as well as any other sources of feedback. Display All Image Sizes’ two support threads to date have both been thoughtful, carefully crafted, and exposed significant bugs. I was also lucky that WP Tavern wrote an article about the plugin, which gave really helpful UI improvements that I just implemented.
So if your experience is like mine, people’s feedback on your plugin will be surprisingly thoughtful and helpful. The experience for me has really brought home the power and fun of open source.
Go For It!
If you’re satisfying clients’ technical needs at a high level, I’d strongly recommend you get into public plugin development. If you stick to the right kinds of problems, and use Google as the everything-textbook that it is, the process doesn’t have to be scary or frustrating, and can in fact be one of the great thrills of working in open source. Thanks for reading!
[…] How to Write Your First Public WordPress Plugin – This article is some general advice for WordPress developers who’d like to dip their toes into public plugin writing. I’ll cover how to find good problems, and how to approach both writing and supporting the plugin. […]
This doesn’t seem in very active development. Last update this July which was organisational in nature (and wrongly date tagged) and the one before that was September last year, more than 3 WP versions ago.
Is it safe to use this as a starting point? Are there any tutorials on how to use it?
“The WordPress Plugin Boilerplate was started in 2011 by Tom McFarlin and has since included a number of great contributions. In March of 2015 the project was handed over by Tom to Devin Vinson.”
There’s also some activity in the GH Issues.
Dev’ing is probably a function of contributors, etc.
Also, keep in mind, it’s a boilerplate. The fact that it hasn’t changed much might not be too much of a surprise. Right? 🙂
p.s. There might be other such boilerplates. I guess the point is, this is probably better than starting from scratch. If nothing else, it’s a template for your own boilerplate.
Congrats on your first plugin!
The next step is getting version tagging done right in SVN, if only to enable your users to roll back to a previous version if an update breaks something unexpected. It’s not that much more complicated than getting your regular commits on SVN, which you already have managed at least 2 times now 🙂