Be careful mixing WordPress optimization plugins

Gears of different shades of blue are connected together showing business related icons.

I spent this morning cleaning up the blog from an issue that was caused by a misconfiguration of WordPress optimization plugins. Specifically a plugin was mixed with the popular WordPress Cache Plugin W3 Total Cache. The actual impact was my fault entirely for ignoring error messages and not restoring a backup right away. This post is a summary of the issue and how I fixed it.

How WordPress optimization plugins broke my website

After enabling the S3 Compatible CDN Host option to host my WordPress Media and Assets on DreamObjects, a nightmarish situation occurred. All links were downloaded and put into the WordPress Media Folder. I believe that another plugin I used to minify assets must of confused W3 Total Cache’s crawler or something. I ignored the error messages in CDN logs telling me it was uploading links or something. I was tired at the time and made bad technical decisions as a result. Because of my mistake content had to be repaired and a cleanup was in order.

Solution

For most posts the restore process was just go to the WordPress Revisions list and restore the previous version. Since WordPress keeps track of post revisions it wasn’t the end of the world for me but fixing this did eat up a bit of my time. This only worked for about 15 of 19 posts. For the other posts I had to go in and use Google’s web cache to figure out which links to fix and remove anything else which isn’t an ideal solution. To complicate things I’ll still have to go through older posts and add more links where I feel it’s relevant. An outbound link review is generally beneficial to readers and such anyways however the circumstances were unfortunate.

Update: This afternoon someone recommended to me for the old posts that lost the heavy amount of links, I should restore one of my older backups to a subdomain and copy the posts over in source code mode. This suggestion worked perfectly and older posts have been successfully recovered. I’m surprised I didn’t think of this earlier. The backups I had created worked out afterall. Although I still believe that my conclusion stands – be more careful!

Conclusion

I learned the following from this experience.

  1. Test all configuration changes on your staging website first.
  2. Make sure nothing broke right after you change a configuration. I would’ve been able to to just restore an old hourly backup however since then other content has been written and it’s not that simple any more. I keep hourly database backups, each one being only around 30MB is very cheap to store on DreamObjects. In my case I waited too long to test everything (I should’ve paid attention to those error messages!) and it made things harder than it had to be.
  3. Be careful about which plugins you mix and research whether they are compatible with each-other first.
%d bloggers like this: