You got the contract! You now have the privilege and responsibility of working on this brand new site that you’ve never seen before! Time to jump right in and start making changes… right?
Not yet! If you want to avoid a possible disaster, there are some steps that you should follow to diagnose the website before you start working on it.
Step 1: Make a Backup (Files + Database)
The worst thing you can do is make any changes without having a backup of the website. If one of your changes breaks the website or changes something that you didn’t expect to change, you can restore a backup and the site will be exactly like it was before. At WP Buffs, the very first thing we do whenever anyone signs up for one of our care plans is to connect the website to our ManageWP account and create a backup.
ManageWP’s backups are stored off the website so you can access them even if there’s a site/server problem and they can be scheduled hourly, every 6 hours, every 12 hours, daily, weekly, or monthly so you don’t have to remember to create a backup manually at all.
Step 2: Use a Staging/Development Site
One way to protect yourself when making changes to a website is to use hosting that provides staging sites. By using a staging or development site, you can try updates and fixes without it affecting what people see on the production (publicly visible) website. Our Hosting Friends that we recommend at WP Buffs all provide staging sites with one click syncing.
Step 3: Use the Health Check Plugin
The Health Check plugin provides highly valuable information when assessing a website, especially if it’s not a site that you built.
The Health Check tab of the plugin will provide you with information such as your server’s PHP version (if your PHP version is below 5.6, that could explain why themes/plugins aren’t working, PHP 7.2 is ideal), database version (if MySQL, your version should be 5.6 or above; if MariaDB, your version should be 10.0 or above). It will also tell you if your server supports JSON and HTTPS and whether it can communicate with WordPress.org, which is very important for receiving software updates.
The Debug Information tab of the plugin will provide you with all of the information on your server settings, website settings, plugins, themes, and other information that’s very useful when trying to diagnose problems and you can copy this information and provide it to plugin/theme support if you need to contact them about problems that you’re experiencing with their product.
The Troubleshooting tab (this is a gamechanger) is where this plugin really shines. Through this, you can put the site in “Troubleshooting Mode”. The way that this mode works is that it deactivates all plugins and switches to the default WordPress theme only for your user account, so this doesn’t actually disable any plugins or change the theme for any other users or the general public who may be viewing the site.
This way, you can enable plugins individually to determine which combination may be causing a conflict and you can determine if a problem is being caused by the theme if the site works with all of the plugins disabled but starts having problems once the theme is activated.
Step 4: Use the Query Monitor Plugin
Query Monitor, as its name would suggest, monitors the database queries on the website, lets you see how long they take and even lets you specifically check for slow queries. This can help you determine what is causing the site or some of the processes of the site to go slow and you can pinpoint which plugin is the source of the slow queries.
Query Monitor also lets you see which hooks and theme templates are being used for any given page so that you can get an idea of how the site is put together so you know which files to look at if there’s a template problem that needs to be fixed.
You can also see all PHP Errors and where they’re coming from so you can get to the root of the problem.
There are many other things that this plugin can do, so I recommend that you learn to use it and it could save you a lot of time and frustration.
Step 5: Plugin Audit
Look at all of the plugins installed on the site. If there are any that are currently deactivated, find out if they are needed. If not, delete them. Once you’ve removed deactivated plugins, look at the active ones and determine if any duplicate the functionality of other plugins or provide functionality that isn’t needed or used on the website. Then remove the ones you don’t need.
Once you’ve reduced the number of plugins, do some investigating. Click on the Plugin homepage to find out where the plugin comes from. If the plugin is from WordPress.org, check the Tested up to version and Last Updated date to find out if the plugin is being actively developed and kept up to date with the current version of WordPress.
If the plugin isn’t being kept updated, this is a big red flag and you should start looking for other plugins to replace it that are being supported and updated regularly. If the plugin comes from somewhere other than WordPress.org, check to see if they have the latest version number or changelog available so you can find out if the version installed on your website is the latest version and if it’s still being actively developed and supported.
Step 6: Theme Audit
If the theme was custom-developed for this website, this is another red flag. I’ve found that a lot of custom themes are problematic because they often haven’t been updated since they were created. This means they often contain outdated code and templates that may not work with the current versions of WordPress and other major plugins such as WooCommerce. I always recommend commercial themes, such as Genesis, GeneratePress, Astra, and others, which are updated whenever security issues and bugs are identified.
The exception here is if the custom theme is a child theme of a commercial theme that is still being updated. Child themes are the correct way to customize a theme. If you don’t have a child theme, or changes are made in the parent theme, these edits may be lost as soon as you update. If a theme is not being updated because updating it breaks the design of the site, that can leave the site vulnerable to attack and malware.
If the theme doesn’t have a child theme, you should create one and identify where edits have been made in the parent theme and move those edits to the child theme. Then update the parent theme.
Step 7: Monitor the Website
The site should be monitored for vulnerabilities, malware, and user activity. At WP Buffs, we use iThemes Security Pro to set good security policy, monitor for brute force attacks and excessive 404 errors as well as track user activity. ManageWP’s Security Checks will check for known vulnerabilities in the WordPress version, plugins, and themes currently on the website and will also scan the site for malware and check that it isn’t blacklisted. ManageWP Security Checks can be scheduled to run daily or weekly and notify you if it finds any issues.
If you aren’t using iThemes Security Pro, you can still use many of the features listed above, but you won’t have access to the User Activity log, so you will want to look at an alternative plugin such as Stream or the WP Security Audit Log. These plugins will keep a history of all changes made on your website and also log the username and IP address of the person making the changes. This way, you can track down how a change happened if you’re ever unsure.
This comes in very handy for us at WP Buffs when we’re working on a site with one of our White Label Partners where we may be working on a site at the same time that our partner is. Sometimes changes get made and it’s helpful for us to know whether it was made by our partner, someone on our team, or someone else who may have an administrator account on the website.
Wrapping up: Be safe!
The 7 steps listed above have been compiled from years of experience diagnosing, fixing, and managing WordPress websites. We all learn in different ways, and many of us learn from experience. Many WordPress developers and website owners have at least one story of when things went very badly. Hopefully, these steps here can help you learn from other’s mistakes so you can avoid having one of these cautionary tales of your own.
The moral of the story here is as follows:
- Be safe.
- Give any website a full backup before doing anything with it
- Do a thorough assessment of the website so you can identify the root of problems without the need for time-consuming trial and error.
Stick to that and you should be well on your way to diagnosing (and fixing) your broken website.