13 Ways to Annoy a WordPress Developer
13 Ways to Annoy a WordPress Developer
Having worked for more than 10 years as a web developer, and many of those years specifically with WordPress, I’ve seen (and written) a lot of terrible code… and have accumulated a number of pet peeves along the way.
So today, I thought it would be interesting to share and perhaps get a discussion going about the things we, as a WordPress community, don’t like.
So let’s count down the 13 things that annoy me the most, in no particular order…
I lied, there is a particular order, sort of. I’m starting with what annoys me most, the rest really is in random order, honest!
Inconsistency is the worst enemy you can have as a programmer, when you work with systems and data structures.
Did you mess up all your function prefixes? Did you save a meta value 1,000 times with an incorrect key? Absolutely no problem, just search and replace. Do you sometimes mess up the prefix, but sometimes remember the correct one? You may need to go through the whole code, line by line.
Something done incorrectly but consistently incorrectly is far better than something done right most of the time.
Don’t forget to apply this rule when you’re extending someone else’s work. If they’ve used camel case – which you hate – it may be worth sucking it up and conforming because that’s what other developers will expect.
2. Bloated Products
I really dislike the fact that some “multipurpose” themes come as a 100MB+ download, even though the actual files that run the theme are under a couple of megabytes. There is no way a Jack of all trades theme will be better than a well-made niche theme.
I understand that the driving force behind this is demand, which is why it is so difficult to change things. It’s all well and good to stand against bloated themes, but they have a much higher earning potential so naturally businesses will make them.
I’m hoping that just like Jason Schuller’s Pickle Theme many authors will come along with focussed themes that add more to a website than just a barrage of eye candy that turns out to be useless when you look at the stats.
The counter-argument is usually that this makes it easier for developers to make changes. There is, of course, a solution to everything: use Sass/Less and build tools like Gulp. Create a developer directory which contains all the raw Sass and JS files and use a Gulp or Grunt to put everything together into a couple of files. Since the information about the build process is contained within the project, anyone can take over any time.
4. Unprepared Parent Themes
If you’re releasing your theme to the world, chances are someone somewhere will want to modify your work. Whenever this happens we scream bloody murder if a child theme isn’t used, so we should make some effort toward supporting them in our work, especially in the functions.php file.
If you’re creating a function that acts like a template tag, wrap in a
function_exists() call to make sure child themes can override it properly. Child theme functions are loaded first so if they try to redefine our work PHP will spit out a “can’t define a function twice” error.
5. Incomplete Documentation
To be honest, I’m more ticked off when I read incomplete documentation than I am when it is missing completely. I mean, why do 80% of the work and not push through the remaining 20%?
If you decide to share your project with others, do document it! Especially if it’s code that is meant to be reused, overridden or otherwise changed – this happens all the time with themes and plugins.
If you want to go all the way, I recommend separate documentation for developers and end users. End users just need to work with the UI, while developers need to find things in the code, know versions of various components and all sorts of other information.
6. Going Overboard With Prefixing
I know that you have to prefix your functions, but please don’t use
23duasn123uehd_ as the prefix. I understand that this has 0 chance of colliding, but surely if you’re developing a mailing list plugin you could prefix your functions with
If you really want to set your functions apart then forget about prefixing altogether and use classes and objects to encapsulate them – problem solved.
7. Not Enqueueing Properly
Also, try and use HTTPS where possible, or better yet, use
//sourceoffile.com/file.js. Just leave off the protocol and your browser will figure it out for you. Awesome!
1.6 million WordPress Superheroes read and trust our blog. Join them and get daily posts delivered to your inbox - free!
8. Misdefining Web Development
This might come across as a bit crass, but if you buy a theme, tweak and tune the settings, teach a client how to use it and wrap up a project, don’t call yourself a web developer.
Before you start throwing rocks at me, there is absolutely nothing wrong with doing this for clients, it’s how many developers, myself included, started out. However, calling it web development is stretching it a bit far.
9. Hardcoding Things That Should Not Be Hardcoded
A great many things fall into this category. One prominent example is the use of the
wp_ database prefix in queries. The database prefix can be changed in an installation, so you should use the
$wpdb->tablename property instead.
You should never hard code plugin and theme locations since these can also be changed. Whenever you want to hard code a path, just search for “WordPress X path” and substitute X for whatever path you’re looking for. If the location is variable you’ll find a function to get to it without hardcoding.
10. Non-Translation Ready Themes
I’ve been lucky enough to grow up with English since I was two-years-old, so in a large part of the world I am understood easily enough, and software is written in a language I understand very well.
Have you ever travelled abroad and wished you were able to read something? Imagine that feeling all the time on the web, the place you go for information, and feeling confusion and uncertainty.
Translations are becoming a huge part of the WordPress community and since it takes almost no effort to make this happen in your products, you really don’t have an excuse not to implement it. You’ll be using all of two functions and wrapping
_e() around your text is not that hard. Really.
11. Narrow Mindedness
This is actually my biggest annoyance of all in general, not just in the development world. With developers, you see this often when talking about Joomla/Drupal/WordPress, or even more so if you talk to Java developers about WordPress.
Many of them look down on WordPress developers since WordPress is not a perfect system; it isn’t the epitome of modern code, for sure. These developers are simply missing the point. WordPress is a tool that fits a certain task very well. It doesn’t fit all tasks, nor is it intended to.
People very often fail to take into account that there are other considerations than their own point of view and there may be more important ones at that. A good example is the developer who wants to rewrite WordPress to make it all nice and object oriented. Sure, as a developer I’d be extremely happy with that, but we would be breaking backwards compatibility. We would cause issues for literally millions of people for the benefit of a couple of thousand stubborn developers.
As a rule of thumb, if someone has extremely strong and aggressive opinions about something, I dismiss them right away as not being able to see all points of view. There are, of course, exceptions, but it has been a good indicator for me.
Really? Don’t we have better things to do? To be honest, I have never read through more than two comments in any given #wpdrama situation because I just don’t care. Obviously, I care about the issue behind the drama, but by comment number three it devolves into a free-for-all that’s not really about the issue at hand but about who is biassed, who isn’t, who has more experience, who is a more professional developer… blah, blah, blah. Yawn, I have better things to do.
That said, I love intense debates. Different opinions are healthy and provide different points of view, particularly as this often drives many great WordPress features. Drama, on the other hand, decreases productivity across the board. Gross.
Bonus: Rude/Weird Emails
This isn’t development-related, but I have three specific type of emails I really dislike or at least find funny. Way at the top of the list is the type of person who has read that mentioning someone’s name in a conversation multiple times shows interest, increased connection and sympathy. Nope, it makes it all super-weird.
This same type of person usually also calls me “Dan.” Apart from that one sentence just now I have never-ever written my name like that. If you see someone’s name on a website, do use their full name; if they tend to use a shorter version I bet they’ll sign their initial response with it. Also, just use a name once, maybe twice, otherwise it’s creepy. Or is that just me?
Type number two is the super short email that literally goes: “I want to learn WordPress and need your help in this regards. Thanking you..” (that was an actual email I received).
There is also number three, the super-long variant of asking for help, which actually doesn’t have a question at the end. The sender goes on and on about what he’s doing and what problems he’s having and then just signs his name.
So What’s Your Pet Peeve?
Have any of my annoyances hit a nerve with you? Surely you have one (or a few) of your own pet peeves.
Let us know about the things that annoy you most about working as a WordPress developer, and if you’ve ever received any rude/weird emails, share those too!