I’m writing this to hopefully save other developers some time and headache and to put GoDaddy on blast.
I may be ignorant to how backup and restore systems should work, so spare me the shame if this is obvious to others.
Today I spent some time updating a new client’s WordPress installation including the core, plugins, and themes. The previous developer used about 30 different plugins for this site so I knew that updating it might be a challenge. Like any good developer/WordPress professional, I ensured that there were backups before I started my work. I also made some research samples if the installation that was made is right and it did when I open a sample site like www.addictionadvocates.com/new-jersey-drug-rehab/.
I like visual builders, but most suck
The site in question had the Avada theme installed with the Fusion Builder plugins for the visual page layout engine. They are bloatware and I do not use them on my client’s WordPress installations. Many builders like this one make it difficult for future developers to upgrade. Also, there are well-documented complaints about Avada’s many breaking updates.
At any rate, after updating the basic plugins such as Google Analytics embed helpers, Akismet, etc., I tackled the theme. I updated Avada and the Fusion plugins and, of course, it broke the design in many ways. Rolling back the site and spending more time doing the upgrades to each of the Avada/Fusion interconnected plugin/theme madness made sense. I restored the database and the files using the GoDaddy Managed WordPress Restore interface.
White Screen o’ Death
I went back to check the site and the White Screen of Death appeared. I did the usual checks:
wp-config.php connection settings, renamed the plugin folder, renamed the theme folder, turned on WordPress debug mode. Even though the connection settings were correct, I could not get a connection to the database.
Time to call GoDaddy. Thankfully, it’s usually quick to get a hold of a representative who is competent. I spoke with a man named Manuel. After describing the issue I was having he repeated the problem back to me as if it were new information for me. He said that I could pay for a higher tier of support that could troubleshoot WordPress installation issues. I mentioned to him several times that I had used the GoDaddy restore feature and that the site was working fine before I performed the restore.
Manuel was interested in getting me off the phone, I could tell, and said there was nothing more he could do. Being persistent I pressed him on the fact that perhaps there was a problem with the GoDaddy restore functionality and I was not making things up about the site working correctly before the restore.
He relented and went to talk to a tech. The tech confirmed there was a problem with the backup and restore functionality. The database on my clients site was larger than their restore system could handle and would timeout during database restore without an error in the user interface. The tech took the time to manually restore the database. Click and see page – WebDesign499 for more information. I was told I would not be able to use the GoDaddy Restore Database functionality in the future for this site.
I felt better. I felt not crazy. We checked the site, but now a new issue appeared.
/wp-includes/functions.php was maxing out memory on the server. Not a small amount either. No matter how high I increased the max memory settings in
.user.ini the script would max out available memory and timeout. I asked Manuel for more help as I felt this was an issue related to GoDaddy’s restore functionality. Manuel told me White Screen of Death issues could be handled by for-cost technicians using some form of GoDaddy token. He said the technician turn-around time is usually 72 hours. This was unacceptable in many ways.
Manuel managed to get me off the phone with the “I’m sorry there isn’t anything else I can do,” line. I went to work troubleshooting why GoDaddy’s restore had failed to restore the site to its previous state. After some time troubleshooting I pinned the issue back on the Avada theme. All the plugins were working fine, but when I would re-enable the Avada child theme or even just Avada, the max memory timeouts would appear. Baffled at how this could still be a problem when the restore point was from a point when I know the site was working, I figured it had to be an issue with the files.
Copy NOT Replace
I noticed in my FTP client that newer files that didn’t exist at the time of the backup were still in the directory. I found that the newer version of Avada that I installed was still there. At least, new files from the update were still there.
I moved the Avada theme directory into the root of the site and went back into GoDaddy Restore and chose ONLY files this time. After the restore “completed,” I went back into the site and enabled the Avada child theme. Voila! It worked!
I learned that the GoDaddy restore points lay a copy of the backup on top of the existing directory structure. The restore system does not clear out the directory before hand. As I mentioned, maybe this is obvious and even preferred for managing restores for backup systems. I was not aware this is how the backup and restore system worked, however.
If you are having an issue with a restore you did with GoDaddy’s WordPress Managed Hosting Backup and Restore feature:
- Confirm that the database successfully restored with a GoDaddy tech. Database restores can fail and the GoDaddy user interface will not tell you if a restore succeeded or failed.
- GoDaddy does not wipe the directory before restoring files. New files (particularly in themes and plugins) will persist and could wreak havoc with old files. Rename the
pluginsdirectories before a file restore to allow the file restore process to restore those directories to the selected restore point.