Last month I shared my suggestions and war stories with WP Philly users about selecting plugins, and even as I was standing there talking I realized I could easily put together a companion presentation offering advice to the WordPress developers whose plugins we were considering.
I’m not sure there would be any takers if I did. The developers I see regularly are people who, I trust (or at least hope) already know these things. The ones who might benefit aren’t necessarily in Philly, don’t know me from Adam and have no reason to believe I know what I’m talking about.
And for everyone else there’s, you know, the threat of scary code stuff. “Technical Advice for Plugin Developers” is a topic guaranteed to send all the power users, writers, site administrators, designers and occasional coders scampering for cover.
So instead, I’ll drop some thoughts here. Maybe I’ll post a few “and one more thing…” tidbits as they come to me.
Don’t Try to Make Your Plugin All Things to All Users
This is an easy trap for developers to fall into. You want to create a great plugin that everyone uses and raves about, so when requests for new features come in you rush to accommodate them.
Over time you find you’ve added so much to your plugin that it’s become unwieldy with options and conditional cases. It’s now taking up so much of your time with support, documentation and emergency fixes that you’re overwhelmed, and users are less, not more, satisfied with your work.
A better way to approach feature requests is to think about which features really do have broad application and which are special-use situations. To address the latter, add action and/or filter hooks to your code instead of building in new settings. You can write documentation and code snippets showing how to put these hooks to good use. Promote your plugin as extensible.
This will annoy a share of users who want you to do all the work for them so that all they have to do is install, activate and save settings. On the other hand, developers who specialize in setting up and customizing WordPress sites will recognize your plugin’s flexibility and will have an incentive to turn to it repeatedly.
Sometimes OO Stands for Obvious Overkill
As part of my job I regularly download and poke around in plugins. Some four years and 250+ plugins ago, I came across one that I still shake my head over.
It’s purpose? Removing a filter. But instead of simply sticking remove_filter() in the plugin, or writing a function calling remove_filter() and attaching it to an appropriate action hook (do it this way to make sure the filter has been added before you try removing it), the developer decided it had to be written as object-oriented code.
So they wrote a plugin which, minus the metadata, ran to 400 lines of creating a class, adding empty methods and sticking the remove_filter() somewhere in all that mess.
Four. Hundred. Lines. The developer could have done it in one. Five lines if it was in a function, maybe 10 with comments.
Object-oriented programming is powerful. If you’re creating custom entities with properties and methods you want to make accessible to other developers, I strongly recommend it as the way to go.
Using it to call a single function already built into WordPress? No. You’ve added nothing to your plugin but bloat — and you’ve made the code harder to read, too.
Unobtrusiveness Is a Sign of Greatness
Let’s talk about the admin interface. From time to time I help out another campus at the university, a friend in the arts or a stranger at a WordCamp Happiness Bar, and each time I’m grateful that I can log into this unfamiliar site and understand about 90 percent of its setup straight off.
One of WP’s many strengths is this consistent presentation. If you think achieving this is easy, you’ve never seen what happens when a university awards a contract to a new Drupal development firm. The content providers have to be retrained and all the documentation rewritten because nothing is where the last set of developers put it.
A characteristic of the ideal plugin is that it blends so well with the core interface that users aren’t aware the feature is a separate component. Will your plugin stand out this way? No, but it’s more professional and user friendly.
So before you start dressing up the admin interface with a promo banner on the dashboard, a safety orange custom admin menu icon and a stylish neon green and lavender theme for your menu pages, ask yourself: who, exactly, are you serving with this?
When developers do this, a lot of them think they’re promoting their products. (A handful simply have no sense of aesthetics. I sigh for them and hope someone else picks out their clothes.) The trouble is, they’re pitching to the wrong people, especially on multisite where the super admins call the shots. If you’re going to light up the admin interface like Times Square, at least keep it to the network admin menu.
One of my worst days at work is when a particular plugin is due for an update, because after every update it starts all over again with its message in the admin interface: “Do you want to rate my plugin?” and I have to manually dismiss it. I used to have to dismiss it about 250 times, once for each site on our multisites. Now I have a script, tell_the_plugin_one_more_time_to_stfu.php, do it for me. Even with the automation, this is a waste of my time.
Marie Q. Administrative Assistant doesn’t want to rate your plugin any more than I do. She doesn’t want to follow you on Twitter, read your latest news or buy you coffee. She doesn’t want to work on the web at all, but somebody decided that web pages involve typing and typing is clerical work, and so the job was dropped in her lap.
Make her day better by staying out of her way. Keep the interface clean and simple. Follow the advice of the movie producer Arthur Freed: “Don’t try to be different. Just be good. To be good is different enough.”