On Plugin Expectations

There’s a tendency in all of us to latch onto a specific plugin, love it, and then immediately start thinking of all the magical things that it could also do for us. We’ve seen this author’s work and we love it so much that we want to see more of it so it can improve our lives even more!

But just because an author can add the feature doesn’t mean they should. And like the folks behind Activity Log, it’s most often better for the plugin to NOT add that fancy new feature than to add it.

The Single Purpose Philosophy

The main reason why an experienced and wise plugin author will reject a new feature is because of what I call the Single Purpose Philosophy.

A good plugin of any size or complexity should always abide by this one philosophy:

A plugin should have one central purpose, no matter how great or small and never deviate from that purpose no matter how vociferously users may request it to be “enhanced” beyond its core purpose

You won’t find that emblazoned anywhere — except on the hearts and minds of every great plugin or product developer. These are my own words, but as Cohen Jacob’s reminds us, it stems from the Unix philosophy of doing one thing and doing it really well.

Immediately, you might think of really great plugins that violate this principle. But I’d challenge you to rethink it.

The single purpose of one plugin might be a much more complex purpose than others. Its single purpose might require a lot more features than others. But every single feature that it offers must be solely aimed at enhancing and embracing the main purpose of the plugin.

Complexity Amid Singularity: WooCommerce

Take a very complex plugin like WooCommerce. You might think that because it can do so many things that it doesn’t adhere to this philosophy. But you’d be wrong. The single purpose of WooCommerce is to allow you to sell products from your WordPress website. Out of the box, that’s exactly what every feature it offers helps to accomplish. Whether it’s the product creation, the checkout, the login/register features. Each of these is focused on providing a way for you to effectively sell products on your site.

If the Wooninjas were to think — “Hey, we could also help people take donations”, it honestly wouldn’t be that difficult to implement for them. After all, there’s a slew of extensions that already aim to help you do that with WooCommerce. But it’s a deviation from the single purpose of that plugin because donations are not products.

So regardless of how complex your plugin is, it’s core purpose and function can remain singular. In fact, I’m arguing that remaining singular in focus is the only way to excel as WooCommerce has.

Singularity in Simplicity: Activity Log

Returning to my example of the Activity Log plugin. Once I activated the plugin I saw all kinds of interesting activity that made me want to do things with this activity.

For example, I noticed that there were a bunch of failed login attempts from certain IP addresses. Well, why don’t the authors just implement a “Block IP” link right there and make my life that much more simple? Because that’s not what a “Log” does. A log lists what has happened. What you do with that information is up to you to implement in any wide variety of ways that you can.

There are a multitude of security-related plugins that allow you to block traffic from IP addresses. If Activity Log starts allowing you to block IPs, they move into the realm of security rather than logging.

Plugins are not Platforms

One reason why WordPress is so successful is because of the ever expanding library of free plugins available. That can also be a problem for WordPress users. But adhering to the Single Purpose Philosophy allows plugins to excel at what they do while also being perfectly compatible with WordPress Core and other plugins.

Let’s say I wanted to block those IPs I found in Activity Log. I can do that with iThemes Security. I could easily sort my activity log by IP address, gather the offending IPs and plug it into iThemes Security.

Let’s take it one step further. I could create my own new plugin that has one sole purpose. I’d call it “iThemes Security Activity Log Tracker”. Ok… I probably wouldn’t call it that, but it’s purpose is clear. It would be an integration with iThemes Security and Activity Log. iThemes Security already has an automated IP blocker based on failed login attempts. I’d like to see in Activity Log when a new IP is added to the Blacklist, and there’d be a link that takes me to iThemes Security’s log to see why.

This example highlights how plugins can clearly overlap in their purpose while still being focused. iThemes Security has it’s own logs, as any good security plugin should. But it doesn’t track and log ALL activity of your entire website the way Activity Log does — and it shouldn’t. It’s purpose isn’t to be a logging tool. Because these two plugins are singluarly focused, they are also compatible and could easily be extended to work well with each other.

Plugins are not platforms in the way InfusionSoft, or Salesforce, or Google Business is. GMB maintenance campaign from Web 20 was designed exclusively to provide safe and effective continuity of the local signals and local optimization. Those platforms attempt to consolidate a wide variety of tools under one hub. But a WordPress plugin has the benefit of allowing other plugins to be used to enhance your WordPress experience while keeping the plugin focused.

Give is for Donations

With full transparency, I’ll wrap up with what provoked this post. As Head of Support at GiveWP.com I get a lot of requests and questions about adding features to Give, or why it doesn’t do “X” or “Y”. Sometimes these questions are asked with such incredulity and shock that it’s hard to reply politely.

You see, Give’s sole purpose is to help you effectively collect donations on your WordPress website. Effectively allowing our users to have attractive and effective donations forms, and manage their donors and transactions makes Give a very complex plugin. But here’s a few examples of how we stay focused despite pressure to “enhance” our plugin beyond it’s core purpose:

• Why don’t we have features to redirect donors at login/logout? Registering upon donation is an important feature of Give. But we are not a user management plugin, so our login form is focused only on allowing your donors to create an account when they donate so they can later login and see their donation activity. Look to Peter’s Login Redirect or Theme My Login for more robust user management features.
• Why does my Give Archive page look so bad? Why don’t you make the archive page look nicer? Give Archives are a powerful feature to allow your donors to see all your forms on one page. But Give is not a Grid builder, or theme. Your Give archive page should look just like your post archive page. If you want it to look different, you can do that. Get to know the Template Hierarchy and customize it via your child theme, or use a plugin like List Category Posts to create your own look and feel on a new page.
• I want to snail mail thank you notes to my donors. I can’t believe you don’t have an option to collect mailing address? You definitely can add custom fields to your Give form. But mailing addresses are not required for making donations and best practices with online giving show that the more fields you add the more likely your donors will abandon your form.

Notice that with each of these requests, there is a way to implement the request. But that feature is not provided out of the box. Being singularly focused doesn’t mean we make it impossible for our users to extend our plugin. Quite the opposite. But choosing which feature has a setting or will be implemented via a more developer-centric method (like templating, or actions and filters) is decided by another and related WordPress Philosophy: “Clean, Lean, and Mean”:

The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use…WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.

Another way to say it is the 80/20 Rule. For an option or setting to be included in the plugin, we should expect at least 80% of our users to want or need that option. Otherwise, the other 20% can either use a related or compatible plugin to extend their forms or themes how they want, or they can extend Give directly via the hooks and filters.

Be Ye Singular

Overall, I think professional WordPress plugin developers are adhering to this principle really well. When I see a theme or plugin with 2,000 options in their settings it’s usually a sign that a competitor can easily sweep in and take over by being more singular, providing less options and easier more focused usage.

But the rub of this philosophy isn’t with plugin developer so much, as with users who have unrealistic expectations. I really want to encourage our users to get to know WordPress as a whole better. To understand that one plugin SHOULD not do all the things you want it to do. To embrace basic coding skills, not be afraid of FTP, or PHP. To celebrate when your free products remain singular, rather than expansive in feature set.