A powerful membership solution for WordPress

So earlier tonight I was doing some work for a client and fired off a Tweet in frustration. I’ve embedded it below for easy of use:

The ‘#ragequit’ was me just stopping work for a while, in frustration, and no, I don’t think anyone should quit writing plugins, and no I won’t list the plugin and in fact, I deleted the response in which I listed the name. I’m doing this out of respect for the developers as I was so graciously reminded that we are all human.

One of the major responses I got was, “Why not just contribute and fix it?!” and I’m going to see if I can help out with that however, it did bring up a valid point…at what point are developers sometimes complacent with the code they release? I know we’re all supposed to be ‘Embarrassed by 1.0’, but that doesn’t mean ‘Careless with 1.0’.

Developers who write code without display errors (or at least error reporting) turned on are only pulling the shades down to hide the crummy view. Notices and warnings are reminders that we’re not quite doing it correctly, and should probably fix it. If your tooth hurts, you go to the dentist. If you have a cough, you go to the doctor. These are symptoms of underlying issues. Same goes with Warnings and Notices. They are symptoms that something isn’t quite right and needs a fix. You can live with a sore tooth, or a cough, but life is so much better without them.

As pointed out in a fairly lengthy StackOverflow response about “Why should I fix E_NOTICE Errors?”:


If you don’t fix all the E_NOTICE errors that you think aren’t errors, you will probably grow complacent, and start ignoring the messages, and then one day you when a real error happens, you won’t notice it.

In all the noise, it’s hard to determine the real cause of any future errors. So developers of WordPress plugins, please use WP_DEBUG or at least do your users the favor of tailing the wpdebug log file as Sheldon McGee mentions.

For one of the most straight forward and best resources for debugging information and tools specific to WordPress, check out the Debugging In WordPress Codex Page.

Now let’s all go write some clean code!

Featured Image via Flick, Creative Commons, and Robert Couse-Baker

Post Promoter Pro

Posted by Chris Klosowski

Hi, I'm Chris Klosowski. Currently I am a Lead Developer of Easy Digital Downloads, where we build the easiest way to sell digital products with WordPress.

I am also the person behind Post Promoter Pro, the most effective way to promote your WordPress Content.


  1. I 100% agree with ‘developing with WP_DEBUG on’. Because we are all human, we’re going to make mistakes and those mistakes would not be apparent unless we have something telling us ‘you’re doing it wrong’.

    My comment to your tweet was part confusion and I have to admit, frustration – it as all about perspective of the issue. Frustration came from telling someone they should not develop plugins because they are not using best practices (by using WP_DEBUG). That’s obviously terrible advice – the better being making this an opportunity to teach them the correct way to do things. If they’ve got some real talent brewing (or just a general interest), putting them down isn’t the right way to go. WordPress is about working together, so let’s always bask in those values.

    The confusion aspect was culminated from a few things: you mentioned you were trying to fix the issue on a client’s site. Does that mean you installed the plugin before vetting it in an environment to test these types of things out? Did it pop-up out of the blue months later? I’m not going to admit that I vigorously test every single plugin I install, partly because of time and the other because I too have this notion that distributed plugins should be sorta, kinda perfect. But the fact is, if there was an avenue to find fault in something, that’s part of the reason people distribute things. When I release a plugin, I have a secret double-reasoning behind so – to see if anyone else finds an error or issue. Security issues most certainly won’t always to be noted by the person making the plugin, as I’ve been guilty of the ‘ole “hey, it works for me, must be perfect!” state of mind. Developers don’t intentionally release bug-filled plugins, but it happens and that’s why there are support forms.

    So – can’t agree more with the lessons learned from your experience with this plugin that caused the issue and a great tip for development, but anything written on the web (or Tweeted for that matter), can’t convey tone or really provide further meaning, so others (me) may take it the wrong way.


    1. Hey Zach,

      I 100% agree, sarcasm and the internet are not best friends. As I noted above, I don’t mean that someone should stop developing plugins, that part was a bit over-reactionary and was the culmination of about 30 minutes of trying to setup the plugin, only to be stopped because the Notices and Warnings were prohibiting me from completing the ‘Install’ process. I would also agree with you that “if they’ve got some real talent brewing” we should be more helpful to these users and coach them along. To bring up a little info, this plugin has been around since 2006 and been through 4 major versions and is currently in a 5.x phase. At this point WordPress development isn’t “new” to the people involved, so debugging practices should probably be part of daily development.

      The part about it being an issue for a client is that, I do development and support for the WordPress plugin of a client. From time to time I get support questions that deal with conflicts between plugins. In this case, someone had installed my client’s plugin with this other plugin and were having issues. My job is to determine if it’s an issue on our end or the other plugin, and then also formulate a resolution to the conflict and sometimes integrate the plugins. So in this case, it’s not that I hadn’t tested something prior to releasing for a client, it’s a one-to-many notion that comes with developing a plugin for the WordPress Eco-system that you are going to, at some point, have to figure out where a conflict lies between your plugin and another.

      I appreciate the conversation that was struck up on Twitter between us and, especially appreciate the comment and discussion.


Leave a reply

Your email address will not be published. Required fields are marked *