Why You Shouldn’t Use Plugins

These are words I never like hearing: “I want to change WordPress functionality, without a plugin.”

At first, when I started using WordPress, I would say that myself sometimes. WordPress should have everything! Why do I have to use a plugin to use footnotes? Why do I need a plugin for fighting spam!? Why can’t I have everything I want and need all in one!

Flash forward many years and my answer is “Because the world’s largest Swiss Army Knife is unusable.”

85 options and when I look at it, I can’t fathom how I’d use it to do the things I need a Swiss Army Knife for. I do own one (two actually) and they’re both the perfect, simple, classic models. Heck, the one I pulled a picture of here has more gizmos! Mine has two knife blades, two screwdrivers, a toothpick and tweezers. That’s it. No extra bells and whistles, and I don’t need them. That little tool is 100% what I need for the moments I need a Swiss Army Knife, and has gotten me into locked buildings, fixed a car, pulled a thorn from my dog’s paw, and a hundred other little things.

So when I hear people say “I want to do XYZ without a plugin…” I can’t help but think they’re looking at the whole process wrong, and I ask them “Why?” People have some pretty amazing excuses for why they can’t use a plugin, but I stick with my beliefs that no tool is all-in-one, and the more I hard code customizations, the harder it will be for me to upgrade them later.


A plugin isn’t ‘core’ so it’s less reliable.

People have this odd idea that ‘core’ makes something better. It’s actually not true. A good part of the design in WordPress was done so people could hook and action into it, making changes and tweaking things. So if you trust that core is ‘reliable’ then you trust those hooks are as well. And if you’re trusting the hook, you’re trusting the plugin. I think what the real fear is, is this:

A plugin author might vanish.

There are a lot of WordPress devs who vanish. Some even work on core. But yes, a plugin author could take a walk and you’d never see them again. This is ‘dangerous’ if you think of WordPress plugins like you think of, say, software vendors. You shouldn’t. Let’s look at HP’s tablets. No one has any idea what’s going to happen with them, if there will be more software, hardware or any support at all in the future. But HP is a proven, reliable company! And what about the Zune? Every vendor makes mistakes with products, and a freelance plugin dev is no better or worse than a major company at the end of the day. A real company might close it’s doors without warning, too! Maybe what people are saying is this:

There’s no one to sue.

Why this is a sticking point… The non corporate version of this is actually “For my protection!” But much like the point above, having someone to sue isn’t a magic solution. It’s not a promise that your vendor won’t wander off into Chapter 11, and leave you hanging. Go ask around, everyone’s had that problem with a pay-for program, and worse, one that left you with no one to sue. People are too sue-happy in my opinion, but I can’t fight that one. I do ask why they think they’d need to sue, and I get told this:

A plugin is less secure.

I’d like to know when the last time was you did a security audit on WordPress. Look, I’m not saying plugins don’t have the potential to be insecure, but if you’re performing your own due-diligence, and security is your bugaboo, then you should be testing WordPress core, your theme and all plugins with equal scrutiny! We perform audits on all vended software. Every year we have ‘hack it day!’ where we actively try to break into our products (in a non-live environment) to verify it’s as secure as we can make it.

So if you have a plugin you really want, you should be reviewing the source code. And that’s where open-source code takes the prize. I can open up a plugin, and if I see base64(), or get() calls to things I don’t recognize, I know the plugin’s possibly insecure. I may even email plugins@wordpress.org and let them know about the bad behavior (base64() isn’t allowed at all). But none of that gives me a feeling, like so many other people, of this:

A plugin is less reliable.

Than… what? Seriously, I’ve heard this a hundred times. You’re saying “Someone else’s code isn’t as reliable!” but I’ve never had anyone explain how the code total strangers wrote in core is more or less reliable than the code in a plugin. And what about the plugins written by core devs? Are they incapable of problems? Tell that to the bugs that slipped into Jetpack. Nothing is perfect.

Now, there are checks and balances on core that don’t exist on a plugin. Core changes are tested by hundreds of people (you’re testing it right now, visiting this site, which runs on the latest bleeding edge).  With all those testers, it’s still possible for major bugs to slip through (like json conflicts, sorry, Nacin). Which is probably why people say things like this:

If I edit my site myself, the code will be there forever.

Don't Edit CoreThat one amuses me a lot, actually. A friend of mine blogged about this recently and pointed out that life ‘without a plugin’ is dangerous. If you edit your site yourself, you have two places to do this.

  1. You edit core
  2. You edit your functions.php

If you edit core, after you’ve killed a kitten, you’ve locked yourself into manually updating WordPress forever and ever. You can’t use the auto-upgrade, you have to read and re-read every code change to make sure it’s not on your file, and you have to pray nothing else was changed to make your hack invalid. How is that different from a plugin? Even a deprecated function used in a plugin will still work.

As for your functions.php … maybe you don’t know this, but the difference between a functions.php change and a plugin is where you put it. Put it in functions.php and now you’re locked into that theme. Which is actually a problem I have with Custom Post-Types right now. If I want to switch themes, there are things I have to remember to bring with me. Hassle. There are plugins, thankfully, that can cover that for me, and I’m glad for them.


Just use the damn plugin!

Well okay, then. Are there reasons when a plugin’s a bad idea? Sure! Brian nailed it in one:

If the plugin is making it snow on your site, I’d consider it unneeded. But I don’t advocate the use of fewer plugins just to use fewer. I do it because I think everything should have a purpose. If there’s no good reason to use a plugin, don’t use it. If it’s redundant, don’t use it.

What else? Oh, Joey says:

And that’s another excellent reason. If you want to learn to code, you don’t use a plugin. Or if you’re like me, you ‘fix’ it.


Excuses, excuses

What are the best ‘worst’ reasons you’ve heard for why a plugin shouldn’t be used? Here’s what my tweeple said (and my slightly sarcastic replies):

Clearly they’re unclear on the concept. Functions are great for small, quick changes, but they’re tied to your theme! A plugin is forever.

So will adding the code manually.

I couldn’t even dignify that with an answer.

If everything was ‘in core’ it would be 600megs and no one would use it.

Let’s hear your best ones!

StudioPress Theme of the Month

Comments

  1. In the section where you refute the idea that “A plugin isn’t ‘core’ so it’s less reliable,” I think there’s one aspect of this that you may of overlooked. Code that makes it into core (not always, but usually) goes through a lot of revisions and has the eyes of a lot of people on it during its evolutionary journey. The leads and committers all have different strengths and keep an eye out (some are security eagle-eyes, others are more focused on performance, still others on just making it feel smooth to use), and the community of contributing developers also help improve the code.

    Many plugins are produced by one person, or one company, so there are fewer brains actively working to make it better by default. If WordPress was coded even by just the core team, it would be less good. More eyes = better code. So in that sense, I do tend to think that often core is more reliable than plugins, because at least you know it went through a 5-6 month dev cycle and had a lot of people testing things and improving them. For many a single plugin author, the ‘works for me method’ reigns supreme, coding standards are not followed, etc. That kind of stuff isn’t required to get a plugin into the directory.

    And for a regular WordPress user (read regular as non-developer), checking the code is not a reasonable suggestion. They just want to know that plugins are developed with the same rigor as core (yeah, yeah, sometimes the rigor isn’t all it could be), so that the system of core + plugins that they assemble is made up of similar quality pieces. Kind of like when you have a nicer car you spend a little more on better parts. Unfortunately we don’t have a vetting system in place, but we did talk about ways to make the plugin directory less sucky and more informative at the core meetup, so hopefully there will be some positive adjustments in this direction in the coming months.

    All that said, I think people should use plugins. :) I even think some core functionality could be removed to plugins. It’s just important that they be really well-developed, and have committed maintainers, preferably whole teams of them.

    • I came back around to that in the ‘less reliable’ section.

      Thing is, as much as I want to agree that “More eyes = better code.” I think it really depends on how big the code is. If it’s the size of WP, yes, more = better. But look at the myriad of smaller plugins that just don’t need a whole dev team to make simple, minor, changes to WP. Would they benefit from a peer-review and a hundred people checking the code before commit? Sure. But it stops being effective.

      There’s a balance, a fine line, to it all. And just to say, in a blanket statement, that you can’t use any plugin because it’s not reliable for not being in-core is … Well. It’s a weak argument when your alternative is hacking core, isn’t it? And just because something’s in core doesn’t mean it’s infinitely more reliable. If it was, no one would ever ship bugs, WP’d never need the hotfix plugin, and unicorns would dance in the street :evil:

      Which is why I think that if WP (or anything) is your life, then plugin or not, you ought to be performing an audit review.

    • That’s the thing, though… most people are completely unqualified to perform that audit. Hell, I manage the whole project and I’m not capable of it. There are a number of very popular plugins that I had installed on wordcamp.org that had to be removed from that multisite install because when Ryan Boren took a look at them, he said they weren’t good enough (not quite safe or performance hits). Not doing anything wrong enough enough to get booted from the directory, but not good enough that he’d let me use it. Hell, one time I completely crashed wordcamp.org by using a Twitter plugin by a respected author that was highly rated (that was a special day).

      Hundreds of developers? No, not necessary? At least 4 or 5 with different areas of expertise/interest? Would probably improve almost all of the plugins, and all of the developers at the same time.

    • Fairly pointed, this is also not JUST a WordPress issue. Vendor ‘plugins’ are just as vulnerable, but I firmly feel it’s not because of who’s looking at it, but because of the rarely executed code problem.

      Read http://www.sohar.com/proj_pub/download/COMPAS93.pdf (it’s long, sorry) – The gist is the less often we use a bit of code, the more likely it is to blow up in ugly ways because we’re less familiar with it.

      At least 4 or 5 with different areas of expertise/interest? Would probably improve almost all of the plugins, and all of the developers at the same time.

      Wasn’t DevPress or someone offering up a plugin review? That cycles back to a very valid point I chose not to touch on, though: Why doesn’t WP have a plugin review team, like they do themes? (I know the practical answer, which is why I didn’t bring it up in my post.)

    • @ipstenu: Re plugin review team, hold on to your horses. A make.wordpress.org/plugins blog has been created (but can’t be accessed yet until we fix some namespace stuff), and once we are able to launch it, the notes form the mega plugins session at core team meetup will get posted at wpdevel. Exciting times ahead!

    • :!: Now I’m totally making popcorn and getting excited!

      I love change.

  2. While I agree with your conclusion – yes, plugins are the best solution most of the time – I think it’s more important to ask why people search for lame excuses.
    Usually, they had bad experiences with plugins from the WP repository:

    • There is no review.
    • Collaboration is still not easy – no pull requests possible, sometimes you have to send an email with your patch, and SVN generally just sucks.
    • No usable bug tracking – you cannot convert a forum thread into a ticket, and Trac is hard to use for average people.
    • Even basic I18n for readme.txt isn’t possible.
    • The rating stars are just a gimmick, they don’t say anything about usability, code quality or compatibility with other plugins.

    I’ve written and fixed more than hundred plugins – 3 are on wp.org. All I got from it was more work, not even a link. And I know many good developers who feel the same. They put their plugins on GitHub and that’s it.

    Regular users, non-coders, are forced to test many plugins just to find the one that seems to work. Sometimes that is not the best choice, and they learn it when their website gets hacked or slower and slower over time.
    I absolutely understand when they don’t trust the repo. They cannot.

    • It’s like you were a fly on the wall at the core team meetup! Those things and more are all on the hit list for this year to make putting plugins in the .org directory a better experience.

    • The one thing I learned from StackOverflow: Reputation is a tool for better quality. Whatever you do on the repo – use this tool.
      Someone helps in the review team? Put a big badge on her/his profile and all plugins and themes. Make two prominent lists for both review teams, add the most active members to wp-admin/credits.php. Finding volunteers will be much easier then.

    • Public recognition breeds inspiration and a desire to do more.

    • Amen to that. That was also one of my suggestions in the latest WP.org survey.

      And seeing Jane’s reply, I am happy (but not surprised) to see that the core team is also thinking on that. Not surprising, seeing the small changes we have seen appearing in the profiles section and plugin repo in the past few weeks.

      I can’t wait to see what 2012 will bring! :)

    • If you asked me ‘fix the plugin or hack core’ though, I’d still fix the plugin. Fork it and have a day. But I’m interested to see where the better plugin experience is going :grin:

      Building a better Repo is going to cause a lot of screaming. I’ll make popcorn.

    • Fix plugin is ALWAYS the right answer.

    • Unfortunately, right now it is often easier just to write the code I need for myself. And I hesitate to fix a plugin whose code style makes me cringe. I’ve hit that wall on 95% of all plugins I’ve seen. :D

    • I’ve fixed plugins in the past and emailed the plugin author to make the changes but nothing gets updated. It would be interesting to see the same sort of commit and SVN system created for plugins as there is for Core. Whereby people could post their plugin changes outside of the original plugin developer and potentially get it added without having to fork the plugin and get a million different versions of the same thing. But I understand the complications of that and the beauty of open source is the ability to fork projects so maybe I’m just venting for no reason. Looking forward to seeing the Repo changes…

    • Michael Bastos – The reality of core is also that your change may never go anywhere :)

      While I agree, it would be nice if people sent me a diff file to fix a plugin, at the end of the day, I’m the one supporting my plugin, and if I don’t want to support the change you want, I shouldn’t have to. Which is really why I support forking. Not to fix code, but to take it down a path the author didn’t intend and doesn’t care to support.

  3. Sure, we all have our problems with helping other people (for free). They’re lazy, often arrogant and simply often want us to do their job (again: for free). But what’s even more annoying me, than this sort of behavior, is when people, who are respected highly inside the community – like you – come down from the mountain and fight back with sentences that could be summed up with: “I’m leading the blind. See the light!”. I’d really appreciate if even one of us (in case I may count myself inside the inner circle even a little), would take the same time and effort and write this up for the rubber duck. That would make posts like this a source that I can link those people without pissing them off and maybe would make all those support sources better places. No, I’m not bashing you for this post. It’s just a suggestion, I hope you consider as maybe worth to think about. (And another “no”: I often haven’t got the patience anymore myself).

    About the actual content of your post:
    In a lot of cases people are searching for something pretty specific and plugins solve either much more tasks than the user needs, or deliver functionality that’s only close to what the user needs. So satisfying the (non paying) customer is simply impossible.
    When I’m searching for plugins to read code and get an idea of how other devs solve a specific task, I have to use the search. And comparing the results the repo gives me with what I was searching for, then I understand why people give up pretty fast: They simply don’t find what they were looking for and stop searching, go to some support route and ask how to get their task done fast, which is in case of WP a valid argument (take the 5min. installer for example – the system promises that).
    For the rest of what I’d have to say, please just re-read the Thomas Scholz wrote in his last paragraph.

    • That’s an interesting take.

      I wasn’t writing this for the newbies. I certainly wasn’t thinking ‘This will be a great way to just link people to my arguments ad nasuem about why they should shut up and love the bomb.’ (That’s a Dr. Stangelove joke.) I wrote this because I was frustrated, yes, but also because I’ve been seeing a lot of experienced WordPressians advocating to edit core and I thought an imperfect, higher level, argument would bring ME more education than not.

      Looking at Jane and Thomas’ answers, I got what I wanted out of this :)

      However maybe I’ll write a ‘how to find the plugin you NEED’ post later on. It’s officially on my list of topics.

      (Yes, I’m arrogant. I’ve always been this way, since I was a baby, according to my parents.)

  4. Great article Ipstenu!

    Recently I had to fix the website that got broke for no apparent reason (or so the owner said). It was using WP 3.0.0, it had over 20 files in the core hacked, and it had a functions.php file that was 2.1MB (yes, that it was huge) and had about 18.000 lines of code in it and it had only 2 plugins (Akismet and All In One SEO). I talked with the owner about his reasoning to make such a mess and here are the reasons:

    1. I wanted to control every line of code added (yeah, right that will do it with 18.000 lines)
    2. WordPress will use less memory and resources with no plugins (my dev4press website with 21 plugins working uses about 48MB, his website was using 54MB).
    3. Plugins are bloated and can be hard to use (this was kind a valid point, but what he did defeats this reason).
    4. Plugins I wanted to use were no longer developed (find other plugins, there are plenty available).
    5. I can get what I need only from some plugins, it will be better that way (until you forget piece of code or run into conflict).

    The thing that broke the camel’s back with functions.php was partial copy-paste from 4 plugins (over 2000 lines of code at once added), put together from various files and I still can’t believe how can anyone do something like that. One of the plugins was mine, so the owner decided to contact me for help. Long story short, I took the job and rebuilt the website using 16 plugins in total, website is at least 20% faster, uses about 40MB of memory and it is updated to WP 3.2.1 (at the time I did that). And I earned quite a bit from a week work.

    Regardless of what anyone can think, functions.php is the worst thing about WordPress. Whenever I start working on new website, I always create a new plugin for that website only. All the code I need specific to it, goes into that plugin. When the theme is added, it remains independent from my plugin, I add templates to the theme I need, and if later theme needs to be changes, only templates are modified to new theme.

    It would be great to have plugins reviews available, but any website that tried doing that gave up after few plugins and no review was actually very useful to beginners. Right now best solution is to try plugins on a sandbox website or pay for the support to plugin authors (good developers are always busy to provide a lot of free support). As with any other product, work needs to be payed, and that is still something most users refuse to acknowledge, demanding (and even threatening) free support because ‘WordPress is free’ (I heard that exact reason to give free support for my plugins).

    All that leads to users being badly informed and they end up doing things wrong trying to avoid plugins. Better information about plugins goes a long way.

  5. HP are not a good example of reliability

    • Oh, I know. Which is why they were my example. We understand that size and manpower aren’t the only deciding factors in what makes a good company. Corporate America, however… :roll:

  6. Dear ipstenu,

    thank you for sharing your interesting thoughts about plugins.

    I started using WordPress when my daughter went to primary school and the parents wanted to have a new web site to announce all kind of activities of the kindergarten. For the ease of use I choose WordPress as CMS … and fell deeply in love with the wonderful, flexible and yet really easy to use software.

    After some severe discussions about the layout (…) the web site was actually finished within a short time and everybody enjoyed how easy it got to add new content or edit existing. But as things go, the parents wanted more. A contact form here, a Google Map there, a slider, a slide show for the latest kindergarten fest, some jQuery animation and, and, and ….

    As I didn’t have the skills at that time to program anything myself I installed Plugins whenever I wanted to have additional functionality not provided by the core. After a while I was unsatisfied with the results. Some plugins didn’t work (or at least didn’t work as expected), some weren’t as easy to use as WordPress itself, some did work but the results were not quite as expected.

    For me, code snippets did the job, which I found at e.g. css-tricks.com, wprecipes.com and many other places in the web. Adding stuff into functions.php as directed was by far more fun: I started to understand what the snippets did and how things come together. Even better: after editing a little here and there, the results were exactly how I wanted it to be.

    This was when I started to look at plugins as a source for inspiration. How did others use hooks and what were filters and actions good for? Not too long and I began to write some plugins for our web site myself and it really was fun. Additionally many tutorials made writing your own stuff look so simple, a caveman could do it.

    A couple of days ago, Christian Heilmann published an interesting article in Smashing Magazine (http://bit.ly/uX8lkW) He claims, that many tutorials scratch the surface but don’t digg deep enough to cover security aspects. He writes “All they wanted was a quick, simple to understand example after all and beginner tutorials have those, right?” I felt caught. “I think,” he continues, “it is time to stop chasing the hollow success of creating a “quick tutorial” that is actually a “bad implementation with quick, sloppy code” in disguise and start curating what is already on the Web. We can then concentrate on the next level tutorials.”

    I still love WordPress’ plugin repository as a source of inspiration and admire the efforts put into the Codex. Yet Christian Heilmann’s article left a sour taste and the question, who will write such “next level tutorials”. (Although Codex certainly does cover some … if you now where and what to search for.) Let’s also hope, that plugins aren’t the “bad implementation with quick, sloppy code” themselfes.

  7. Hi,

    Great article! I’ve been working with wordpress actively now for about 6-7 months (after blowing up my drupal website without usefull backup). I have no advanced (or mediocre for that matter) coding experience and I could never create my own plugin. I love plugins free or paid for.

    So I use plugins, and lots of them! But what I do have learned from my experience thusfar is that although wordpress is free, it’s best to pay for plugins which affect your everyday business. With the lesser important plugins you can get them for free (almost always) and test them. If you don’t like them, get rid of them. It isn’t all that difficult right?

    The only, in my opinion, valid argument not to use plugins would be that it slows down your site. But like you said, so will core code. That’s why one should use only plugins which are useful to help meet ones (business)goals. No fancy stuff no one needs.

    • Payment has little to do with it. I think I’ve got three paid plugins, total, on all my sites. And those ones, while very much worth the money, are actually the ‘least important’ plugins of the lot.

      When you pay for a plugin, IMO, you’re paying for the support you get with the plugin. Actually, that’s the only reason I buy a plugin: support. The code between a paid and a free plugin has, thus far, not varied in quality that I can tell.

    • That is actually the reason why I pay for some, support. And, if enough pay for the plugin development of it is often more certain.

  8. We’ve started adding non-core functionality by programming it ourselves instead of using plugins. Yes, the code goes in functions.php, but we control it and create it. As the volume of traffic the sites we are developing increases, we’ve had serious performance issues. In too many cases, plugins were causing issues due to inefficient code etc. Coding ourselves solves that.

    • But why wouldn’t you code it yourselves as a plugin rather than hacking core? Then it wouldn’t be an issue when it’s time to update to a new version of core.

    • I thought she was talking about a theme’s function.php.

      I’m starting to drift over to functionality plugins (i.e. one I toss in mu-plugins) so I don’t lose things between themes. Totally depends on if I’m making a theme-specific ‘tweak’ or not, though.

    • I agree with Jane that one shouldn’t touch Core code but rather create your own plugins to solve your problems. There should be the same performance hit whether you put the code in functions.php or a plugin because you’re adding more code for the interpreter to process right? At least with plugins you can turn off your functionality but I can understand forgoing plugins if you are trying to optimize and instead adding some one line constants to wp-config if you know what you’re doing…

  9. Interesting perspective on the matter, I usually use Constants for a lot of what I do but use plugins when I have actual code changes to make. It would be nice to see something like a “Verified” plugin section in the directory that has either been vetted by the team or for commercial plugins to have paid an approved auditing team to “Verify” their plugin but you’re right it’s few and far between the people that are really qualified to do that kind of verification. Looking forward to the upcoming changes…

  10. Great article! Couldn’t have said it better! :)

Half-Elf? Try Half OFF WordPress ebooks!