The Top 5 Bad Habits of WordPress Developers
After many years of being hired to modify and fix WordPress websites that I did not build I’ve become very familiar with a number of problems caused by the developer or developers who had built or previously worked on these sites. And the impact of these oversights and bad habits is far from trivial.
Some of these choices made during setup or during a modification to a site result in slow load times. Others can make the site unstable or vulnerable to hacking. And often these problems make it harder for the client to manage their site.
Frankly, every site I’ve ever worked on that I didn’t build has had at least one of these problems. It’s critical that developers learn how to avoid them.
Over-using Plugins
While WordPress plugins offer many valuable out-of-the-box features and benefits, some majority trade ease of use for site performance. Most small plugins are intended to make it easy for people without coding experience to implement functionality they wouldn’t know how to add to the code of their template. While this is useful to many, often the cost does not outweigh the benefit.
Many plugins, such as plugins that allow you to add the Google Analytics tracking code to your site, are more or less useless and add hundreds of lines of code to a site where only a few lines of code are necessary. In this case, the Analytics tracking code is 10 lines which simply needs to be dropped into your header.php file, something a novice could accomplish from with the WordPress dashboard.
My bottom line here, to get a bit preachy, is that anyone calling themselves a ‘WordPress developer’ should at the very least have FTP access to the sites they work on and should be familiar enough with the structure of a WordPress theme that they can add code to the header, footer, script, or function files.
Solutions to feature requests should be researched and the plugin repository should not be the first place you look. Do a search for the feature name and the word ‘code.’ See if maybe you can find a basic solution that might not be too challenging to implement before you turn to a plugin.
Duplicating Functionality
I recently worked on a site that had, I kid you not, 5 plugins and 2 scripts to deal with sliders. Each slider on the site literally had it’s own script. Rather than utilizing the scripts or plugins in place, each new developer working on the site had installed new code.
While that’s a worst case scenario, it’s a common problem. Very often when new developers are hired to work on an existing site they don’t take the time to look at the functionality of the theme or the plugins that are in place. It’s not uncommon for me to find that a theme provides a method for including share buttons on a blog post but some previous developer has included them statically right next to the dynamic code that would have had the exact same result.
Even more common is finding that a developer is less than familiar with core WordPress functionality and has used a sql query instead of a WordPress function, or installed a menu plugin rather than using the WordPress menu system. While it’s hard to say why developers do this in each case, the result is the same; too much code.
Not Doing Custodial Work
When it comes to bloat my biggest pet peeve is finding that developers have simply been lazy as they built or made changes to a website and left unused code in place. While time is money to someone on the clock, and at times it can seem like pointless busy work to delete unused CSS or remove scripts you have replaced, it’s also very important for a couple reasons.
First, is speed. Extra code can cause longer load times and a part of a developers job is certainly not to leave a site working less efficiently than they found it. Second, is development time. As mentioned above, working on a site with a lot of unused or redundant code makes it harder for developers to navigate files while looking for specific features, scripts or styling elements.
At the very least the idea here should be that you leave the code no more bloated that you found it. In contrast, I generally tend to do a bit of cleanup as I work on sites I didn’t build.
Crowding the Dashboard
One of the benefits of WordPress can be that it is easy for a client to use. When properly set up the WordPress dashboard should be rationally organized. Unfortunately, many developers are only thinking of information architecture on the front end and not on the back. For the benefit of the client it’s critical that the WordPress dashboard be easy to navigate and that the data a client wants to enter be logically organized.
It can be challenging for novice developers to ensure a clean dashboard. However, developers more comfortable with coding should be spending time making sure that navigating the back end of a site is easy for the client. This would include making sure that similar kinds of information are entered in similar ways. Don’t have some posts organized by custom post type and others organized by category. Don’t use meta boxes for one kind of setting and then the theme customizer for a similar one.
In addition, it’s possible to add functions that eliminate unused portions of the dashboard. If the client isn’t using comments or tags you can remove those menu options. In this way you can make the dashboard more streamlined than it comes out of the box. The bottom line here is that it’s important to be thinking about the ease of use for your client. Again, don’t make a site more complex than you found it.
Bad Security
The final bad habit that is all too common is a poor understanding of WordPress security best practices. You do not want a user named ‘Admin.’ You want to ensure that any users you create for yourself or the client have strong passwords. There are many more ways to secure a WordPress installation that require tinkering with code, but that’s no longer necessary with the option to use what I consider the best security plugin for small to medium sites.
iThemes Security is a plugin I use often that helps you patch a wide array of security vulnerabilities. Once installed the plugin lists off dozens of things that the plugin can do, settings to change in WordPress, and small changes to code you can make that essentially nullify the likelihood that the site will get hacked.
Many developers with less experience don’t think it’s likely that sites will get hacked. But do this long enough and you will see it happen. This site was hacked last year and malicious code was injected. Now that I’ve installed iThemes Security I have full confidence that my site is secure. And clients really appreciate having that piece of mind.
Last Words
So, don’t be lazy. Get used to concerning yourself with these issues and they will become a part of your professional toolbox. And as you do these things they become something that takes you less time, something that is just a part of the service you offer. In addition, they will become something you can tell clients about that will help you distinguish yourself from other developers as we compete for work.