It Started with a Customer Support Ticket

This is a true story about an eCommerce website and how it’s sales stopped suddenly in the middle of the day. For no apparent reason.

This business gets a steady stream of transactions on any given day, both for their free and paid products. It’s not uncommon to see several dozen transactions per day. And when I say transactions, I mean items added to their eCommerce shopping cart and the checkout process completed.

The owner started to notice a decline in transactions a short time after 12 noon. He didn’t think too much of it until he was made aware of a support ticket that had come in from a customer saying…

…your “Purchase” buttons are not working and I can’t add any items to my cart. Please advise.

The Troubleshooting Begins

I was brought in to help and started the usual first step in troubleshooting; duplicating what the customer was experiencing.

To be honest, I assumed that it was probably due to an outdated browser issue or some other rather simple explanation. But in the website maintenance and management world, making assumptions can get you nowhere fast.

Be methodical in your troubleshooting and follow the facts.

Duplicating the Issue

I loaded the site in three browsers and in each one, I was seeing the same issue. The Purchase and Add to Cart buttons simply weren’t working.

Odd.

I then discovered that logging into the site presented me with a white screen, rather than the expected WordPress Dashboard screen.

Uh Oh.

WordPress Admin White Screen

PRO TIP: I also use Cross Browser Testing to ensure I can duplicate the customer’s exact browsing environment as close as possible.

Communication with your Customer

After confirming there’s a global issue, you need to get as much information from your customer as you can. This should help you narrow down some clues and give you a better starting point.

It’s helpful to ask questions like: “Have there been any recent changes made to your site by you or anyone else?” “Have you recently installed any new plugins?”

In this case, there were no changes made in over four weeks and up until that moment, sales had been happening just fine.

Checking Plugins – Round One

Customers always have the best of intentions, but I’ve seen it happen before where someone on their staff that has administrator access may have made changes to their site without their knowledge.

There’s an easy way to double check if any plugins have been installed recently, and that’s by looking at the Last Modified dates of files and folders once you’re connected to their server via FTP (or SFTP).

Last Modified Date

If you find that the Last Modified dates of any of their plugins are recent, go ahead and deactivate those plugin to see if that solves the issue.

I checked these for this client, and unfortunately, the Last Modified dates hadn’t been changed in four weeks. Just like they said.

Check the Hosting Environment

If the site is loading for you, it’s unlikely that your website host is experiencing downtime, but it doesn’t hurt to check with your host’s support before doing anything else. Even though the site may not look like it’s completely down, I have seen intermittent connectivity issues with hosts that have caused some very strange results on the frontend.

It’s also worth noting that your host can also more easily check the status of your server and look at error logs more quickly to determine if something is going on at the server level or if any plugins (or anything else) are throwing errors that could lead you to another clue.

I contacted their host in this case, and as you may have guessed already…they could report nothing out of the ordinary.

Checking Plugins – Round Two

My normal next step in troubleshooting is to rename plugin folder on the server. Doing this will automatically deactivate ALL plugins on a WordPress site. If the problem goes away, then you know you have a plugin conflict and can start reactivating your plugins one by one while testing the frontend behavior in-between activations.

This can be a tedious process if you have a lot of active plugins, and definitely one you want to do on a staging environment.

However, in this case I wasn’t yet convinced it was a plugin issue because there had been no recent plugin additions or updates.

That took me to the next step.

Escalate and Get Another Pair of Eyeballs

The beauty of working with a team is that you have more eyeballs to look at these kinds of issues. There is truly power in numbers and it’s likely that someone else will see or try something you haven’t thought of, especially in a stressful moment of troubleshooting when the pressure is on

I reached out to a team member and described all the information I had about what was happening, and then it happened…

The First Solid Clue

My colleague immediately enabled Debug Mode in WordPress and was able to see some “500 Server Unavailable” errors in relation to an AWeber plugin installed on the site.

In retrospect, Debug Mode is probably one of the first things I should have tried. Duh!

The Two Culprits

Now that we knew it was related to an AWeber plugin, we deactivated it and were immediately able to log back into the admin side of the site and the mysterious Purchase and Add to Cart link errors had disappeared.

Problem solved?

Yes, but not without continuing questions.

This plugin had been enabled and working fine for almost two years. Why was it causing a conflict all of a sudden?

On a hunch, and knowing that this plugin was dependent on the AWeber API, I decided to look at the AWeber service a bit closer by loading their site and also looking at their Twitter account and status blog.

Are you ready for the punchline? Can you guess what I found?

Yep. The AWeber service was completely down and they were reporting an extensive DDoS attack.

AWeber Downtime

So in short, because the AWeber service (and thus their API) was down due to the attack, the AWeber plugin they were using couldn’t communicate with the AWeber server (the “500 Sever Unavailable” message) and that was causing the whole issue.