Common WordPress Pitfalls and How to Avoid Them

Overview

I can say I have a lot of experience breaking websites. I think WordPress is probably my number one victim, because that’s the CMS I’ve worked on the most over the past decade or so. In my defense, some sites came half broken or “on the edge”, and I just gave them a helping hand. Sometimes I got assistance from a coworker, and we did some massive damage.

So, after hitting a lot of these pitfalls accidentally, which isn’t ideal for obvious reasons, I wanted to come up with some strategy with the following goals listed in order of preference:

1. prevent or minimize the chance my site will hit the pitfalls in the first place
2. have a remedial plan in place

Identifying Pitfalls

Identify potential pitfalls that can happen and proactively prepare for them, either by implementing preventive or remedial measures. The latter of which could be simply to lessen the damage and/or more quickly restore things to normal. Here are some potential ones that I’ve run into:

1. You have an active plugin that hasn’t been updated for 3 years
2. Your server has 1.5% disk space left
3. Your server is not properly firewalled
4. You have old users in WordPress or others that have simple passwords
5. You haven’t been updating your core, plugins, and theme

Defusing the Bomb

Once the pitfalls are identified, the first objective should be to make them inert, if possible, by employing preventive measure. This really depends on the type of pitfall we have, but let me provide some possible remedies for the example pitfalls I mentioned in the previous section:

1. Update your plugin, and if no update has been available for a while (i.e. 3 months or more), maybe try to find an alternate plugin that is more actively maintained
2. Your hosting provider might provide a web panel to monitor your server resources, so check that periodically to ensure you not only have enough disk space left but also memory and cpu aren’t being overly taxed consistently. If they are, you may need to upgrade your server.
3. You want to be able to connect to your server when needed, such as through FTP or SSH, but your hosting panel should allow you to only allow those connections to certain IPs. If you have a static IP on your network, then only open the services you need to that IP. As far as the HTTP and HTTPS ports, you generally want to leave those open to the public, but if you are using some service like Cloudflare, you only need to open those up to that service. Cloudflare and others list their IP ranges on their sites, so you can open up your server to those and lock it down to others. You can also block your whole site and server to whole countries that don’t need to access your site. This can be a great safeguard against infiltrators which often come from non-US IPs.
4. Only keep the users that are still needed and make sure to keep the passwords secure. Occasionally changing the passwords is not a bad idea.
5. You want to do regular updates on everything you can update in WordPress but also your server, depending on what your hosting provider lets you manage, such as PHP version. Check out When and How to Upgrade Your CMS and Server article for more details.

Dealing with the Inevitable Ambush

So, we know some plugin is a pitfall, but our site depends on its functionality, and we don’t have a replacement ready yet. What can we do to prepare for the worst and deal with it quickly if/when it happens? Below are some steps that can be taken for this scenario as well as others, as it’s a general set of guidelines:

1. Implement some test to check if the pitfall was hit
2. Setup a process to run the test as often as possible
3. Have an optimized remedial process setup that can be run without delay once the pitfall has been hit
4. Automate 1-3 if possible

Sabotaging Your Site For Its Own Good

Now, site destruction is sometimes fun and exciting, but it can also be very helpful. For instance, it can be useful to test out a new feature, update, or simulate some potential real life scenario (e.g. spike in traffic) on a site in a sandbox or development environment where we can monitor the site’s behavior before, during, and after the experiment without breaking a sweat if it blows up. Taking backups is a good precaution before trying anything risky, whether it’s in a live environment or even development, so you can rollback conveniently. We’ve provided details in the ()[Easy and Automated Backups article], if you want to read more about it and see some examples.