Coding in a vacuum is inexcusable and can cause you or someone else a lot of trouble down the road. Here are some of the major things to look out for:
1. Loading your own copy of jQuery
C’mon man…Seriously? Loading your own copy of jQuery is a great way to just ruin everything.
Novice plugin and theme developers sometimes make the mistake of loading their own copy of jQuery for whatever reason. In many cases they de-register the one that comes with WordPress, which looks something like this:
1 |
<?php if( !is_admin()){ wp_deregister_script('jquery'); wp_register_script('jquery', ("http://cdn.jquerytools.org/1.1.2/jquery.tools.min.js"), false, '1.3.2'); //wp_register_script('jquery', ("http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"), false, '1.7.2'); wp_enqueue_script('jquery'); } ?>
|
De-registering WordPress’ copy of jQuery and loading another has the potential to break all kinds of javascript in other themes and plugins.
The Solution? Don’t be THAT guy. Just use the copy included with WordPress.
2. Not loading JS/CSS files properly
This deadly sin includes two smaller sins. The first is adding inline script and stylesheet tags via your header file. Pasting them right into the header can cause them not to load at the right time and will also have them loading on every single page.
What’s the remedy? Use wp_register_script/wp_enqueue_script.
Adding scripts the right way will load them on the right pages at the right time with the proper dependencies.
A second related deadly sin is loading custom Javascript and/or styles on every page, instead of conditionally loading it when necessary. Loading your script on every page is often not necessary. This can cause your site to slow down significantly.
The solution: Load your scripts only when necessary to keep your site lean and fast.
Here’s a very common example of how to do this, courtesy of Phil Banks’s tutorial on conditionally loading plugin scripts in WordPress.
1 2 3 4 5 6 7 8 9 10 11 12 |
add_action( 'wp_print_scripts', 'deregister_cf7_javascript', 15 );
function deregister_cf7_javascript() {
if ( !is_page(15) ) {
wp_deregister_script( 'contact-form-7' );
}
}
add_action( 'wp_print_styles', 'deregister_cf7_styles', 15 );
function deregister_cf7_styles() {
if ( !is_page(15) ) {
wp_deregister_style( 'contact-form-7' );
}
}
|
Essentially, this script stops the contact form script from loading on all pages and load only on the contact form page, using the page ID. It takes a bit of time, but you can use this same method to fine tune your WordPress site so that it’s not always loading unnecessary scripts.
3. Not escaping user input in SQL and not encoding user input on output
SQL injection attacks are one of the most common ways to exploit web application vulnerabilities. Not escaping user input in SQL can leave you vulnerable to these kinds of attacks. This mostly pertains to plugin development but should also be a concern for regular WordPress users who may be installing a plugin from an untrustworthy source.
The solution: Make sure to sanitize user input in order to protect against SQL injection and then encode it on output for display to prevent XSS vulnerabilities. The WordPress codex has a section on Data Validation and WP Tuts has an excellent reference that goes into more detail:
Data Sanitization and Validation With WordPress.
4. Incorporating too many 3rd Party Services
The only place where a third party registration or login plugin makes sense is if a significant number of your user base, or potential user base, is active on that social network. The connection is then a convenience for your users and helps to get more people in the door. However, if you are offering the ability to register and log in via Twitter, FB, G+, and more just to cover your bases, then something is wrong. It’s simply not necessary and can actually bring your site to a crawl while loading all of those third party services.
The Answer: Include third party services sparingly and only if they are absolutely necessary.
5. Expecting too much from shared hosting
Shared hosting sucks. End of discussion. Don’t ever fall prey to the all-you-can-eat shared hosting buffets. You can actually waste a lot of your own time by expecting too much from shared hosting. When your server gets oversold and your site slows down, you can spend hours trying to sort this out with your host. It’s a mistake to think that you can add all kinds of media, plugins and social aspects to your WordPress site on a shared host and have it all running smoothly.
Recommendation: Purchase better hosting than you need, especially if you are expecting your site to grow. Cyber Monday is a great time to find excellent deals on VPS and dedicated servers. Take the time to do some research and you’ll be able to find an affordable host that can accommodate anything you want to do with WordPress.
6. Using “admin” for a username with an insecure password
Using “admin” for your administrator username and “password” for your password is a hacker’s dream come true. There are actually evil bots that go around looking for installations that have done this in order to exploit them.
The Solution: Give your site’s a unique admin user name and use a strong password. You can even add a plugin to force users to select strong passwords.
7. Adding tons of plugin-type functionality to a theme’s functions.php
Why is this bad? There are a number of reasons that you want to avoid this as much as possible. For the sake or organization it’s best to keep your presentation separate from your functionality, especially if you have other developers working on the same site.
Also, it can be a nightmare to troubleshoot conflicts and problems after upgrades. For example, let’s say you’ve added a ton of functionality to your theme’s functions.php file but there’s no easy way to turn each part off one by one for determining the culprit when your site is having problems. If all of this functionality existed in separate plugins, you’d be able to more easily troubleshoot them and find the part that needs to be updated or removed.
Solution: Create a “functionality plugin” every time you are wanting to paste something into your functions.php file. It takes just a little more time but you’ll be grateful for it later.
Are these the deadliest WordPress development sins you know? What would you add to the list?
