WordPress.org Plugins
WordPress.org Plugins
WordPress.org Plugins

As suggested by the comments this is probably better titled as:

Why I Prefer Not to Use Plugins in WordPress

WordPress is a great open source CMS. Out of the box it has a ton of functionality and the huge community that exists around it contributes plugins and patches which are often very high quality.

Despite the typical quality of plugins for WordPress I don’t like using them and here is why.

Clean up Please

One of the biggest issues with plugins is the fact that many just leave their tables in the database after they have been removed. A well thought out plugin that adds data to your DB should also:

  1. Remove the data from your database
  2. Offer to let you download a .zipped copy of the data before deletion

The only plugins I’ve seen clean up after themselves are premium plugins like Gravity Forms. Yes there may be other plugins of a non-commercial nature that do clean up after themselves I just haven’t seen them.

Way more than I need

Many plugins for WordPress provide way more functionality than I need. In an attempt to serve the wide community that is WordPress plugins seem to bloat. Users request more features and the developer adds them to keep their users happy. Sure this sounds like a good plan but so many plugins offer a million different options for what was once a simple function.

Trivial Functionality

While I’ll agree that WordPress is used by many people with differing degrees of comfort in code, I personally am happy to code. There are a ton of plugins that add trivial functionality (Feedburner RSS link) for which I think its silly to use a plugin. Producing a quick theme level option that uses the default WordPress feed or can substitute for any feed you choose is a trivial thing so I just use it in every theme I produce.

Increased Likelihood of Issues

Anytime you add code to anything you’re increasing the likelihood of errors in the system. Each line of code can potentially include a security hole in your software. Code can break on upgrades of the system. With the recent release of WordPress 3.0 many people reported issues during upgrade because of plugins. I personally experience issues with the TSG Podcasting plugin. It gave me a mysterious white screen of death. Yeah it was upgraded pretty quickly but the fact is that WordPress 3 betas were around for a long time and the plugin author waited to update till after issues were out.

I’m not trying to call TSG out, it’s just an example that happened recently. I still use the plugin and don’t plan on switching.

Long Term Support

This issue has raised it’s head before and the WordPress community is trying to deal with it by introducing the notion of Canonical Plugins. There are many cases of plugins just stopping development. With the wide user base of WordPress it’s almost guaranteed that there will be hundreds of people using any given plugin. That’s hundreds of people who aren’t happy when the unsupported plugin breaks. If there is a plugin I’m relying on I’d rather also be in control of its development. At the very least I want to see a commitment to the continued development of the plugin.

There are few plugins that truly have any type of long-term development commitment so I’m just hoping development will continue.

Making the WordPress Plugin Ecosystem more Robust

I’ve alluded to many of these but, here are the items I’d like to see WordPress work on with Plugins:

  1. Uninstall Mechanism

    The WordPress Plugin API should include an easy call which would allow plugins to remove all of the data they’ve introduced into the database as well as offer a .zipped copy of that data. This isn’t something each plugin developer should have to build themselves.

  2. Version Compatibility Checks

    When upgrading WordPress it should check if all of the current plugins are marked as version compatible with the version you’re upgrading to. If not it should give you the opportunity to upgrade or to stop the upgrade. Yes this means plugin authors will have to tag their plugin as compatible with the proper version of WordPress and no it doesn’t really stop them from tagging without testing but it’s better than nothing.

  3. Easily Transfer Ownership of Undeveloped Plugins

    There are also lots of plugins in the repository that are dead in the water. Currently there is no real mechanism to pass on ownership of a plugin. Not only should this be easy for a plugin author to do, it should also be possible to transfer the ownership of a plugin given a stop in development, a compatibility issue, and no response from the original developer. Yes there needs to be some process to make sure that plugins aren’t being removed inappropriately but there needs to be a process to give dead plugins to developers that want to maintain them.

  4. Development Commitment

    There should be some sort of development agreement provided by WordPress that developers can optionally agree to. Something that says this will be in development for the next 6 months or maybe that it will be updated for the next release of WordPress. Developers would need to tag the version appropriately at the release of each WordPress version. Yeah this idea needs more development so leave your thoughts in the comments.

  5. Easily Remove Outdated Plugins

    This idea came to light from discussions on the WordPress Hackers Mailing list. It seems that plugins whose functionality is no longer needed (because it’s in WordPress core) are still sitting on the WordPress Plugin Repository. There is no clear way to remove a plugin from the repository.

I don’t

Now despite my dislike of plugins I don’t disable them or their updates on any sites I produce.

Firstly clients aren’t coders so they may need functionality that is supplied by a plugin. Sure I might code it directly into the themes functions file but clients don’t want to always have to come to me for everything.

Secondly entirely disabling the plugin updates and plugin system is more work than I want to do. Even on a site that I manage regularly sometimes I just need something to work and work quickly. In that case I’ll resort to a plugin until I have time to add the functions myself.

Thirdly WordPress uses its own plugin architecture to modify itself so stripping out the plugin functionality entirely would break a site.

Forth removing plugin function would be like forking WordPress. I’m not working on any sites that are so mission critical that the time I’d spend stripping out plugin functionality and making WordPress still work is worth it in any fashion. For some government organizations this would make sense because of the sensitivity of their data but I’m not working with anything like that.

2 responses to “The Case Against WordPress Plugins”

  1. Mike Schinkel Avatar

    This isn’t a case against plugins, it’s an advocacy for best practices (which I applaud.) But your post title will likely be consumed by many who won’t read your post and it will give them “ammo” to argue against using good plugins, or having custom plugins developed or even using WordPress at all. Your post title is doing a disservice to the community; is that what you intended?

    1. Curtis McHale Avatar

      Of course I don’t intend doing a disservice to the community. I like using WordPress and think it’s a good idea. I don’t think throwing a plugin at everything that needs to get done on a site is the best way to do it. My intent was to express that and define cases under which I feel plugins start becoming better options, so yes defining best practices.

      I suppose a better title would be ‘Why I Prefer Not to Use Plugins in WordPress’ but it’s already up and indexed so…