The WordPress Developer From Hell – Or Why I Never do Plugin Updates on a Production Site

If you update a plugin on a clients live website you will probably come into hell

It’s happening again. You are looking into your customer’s WordPress dashboard, and you see there is a new update available for this great fancy plugin you install in all of your customer websites all the time whenever you create a new WordPress website.

You start reading the changelog of the plugin, and you decide it’s time to update the plugin. Maybe you even do not read the changelog, and you just start the updating process.

“What should happen? It went smoothly all the time previously, and I never needed a staging or testing website so far.”

So you are convinced it will work this time as well.

You click on update, and the progress status is switching from Updating… to Updated.
You start checking the new settings of the plugin to learn what is new.

“Everything seems to be working fine. This took me only 3 minutes – great.”

You are opening the front page of the website!

The neverending whiteness of a blank pure empty page welcomes you, and you slowly start panicking. Your heart pounds and you can’t breathe. You even feel like you’re dying or going crazy.

Nothing worst can happen now, and you feel lost when your phone starts ringing.

The angry sounding voice of your customer is on the phone. You only take a few words like the campaign, emails not going through, no order orders possible, financial loss…
You immediately start realizing that you need to solve this pressing issue right now.
This is not the right time to mention with any word that you have caused the issue, and you just tell your angry client that you will hurry up to bring the website online again. When it is done, there is more time to explain the situation and the reasons for later, for sure.

“So let’s get back the baby. No problem.
I can login with FTP to the customer website, go into /var/www/htdocs/wp-content/plugins/ and rename the folder of the broken plugin to something else. WordPress will deactivate the plugin automatically, and everything is fine.”

Thought and quickly done at a glance!

You are glad that you have the FTP credentials data in the mail correspondence, so it only takes you 3 minutes until you are ready to log in for doing that job.

You press F5 to reload the website. Nothing! The white screen of death still welcomes you with an angry smile on your face. Your stomach turns around and you feel someone punched you directly into it.

“Holy Cow, why isn’t this working? 15 minutes have already been passed since the website is offline. My client will kill, or worst, sue me.”

You realize that you need the WordPress debug.log file, faster than ever before. Without any proper error message, you are not able to find out what’s going on here.

You log in again via FTP, and you are checking the file
wp-content/uploads/debug.log.

“What the heck, it’s empty!”

You suddenly remember that there were some permissions issues on the site, which prevented the debug.log from being written before, but you never fixed this.

“Oh my, if only I’d ever done this as it was planned.”

Other things were more important to do, as always.

So whenever you had some spare time for such ungrateful jobs, you have moved them, as always.

It does not help, you need to enable error messages on the website front end.  No matter if visitors might be disturbed by these errors or not.

“What if there are any security-relevant warnings or errors on the frontend which could open attack surface for hackers or script kiddies?
There is no way out without enabling the debug mode on the frontend.”

You need to see the thrown error!

So you go into
wp-content/wp-config.php
and make sure that debugging is enabled by adding the simple lines
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_DISPLAY’, true);

20 minutes have been passed, and you are sweating more and more.

You are pressing F5 again. The stress and adrenalin in your brain make you think in lightspeed and everything out of your body seems to be in slow motion. You are looking at the slowly rendered screen until the reflected light of text reaches your retina and your optic nerves and another error appears on the screen:

Fatal error: Call to undefined function cookie_shortcode() in /var/www/htdocs/thesite/wp-content/themes/twentysixteen/page.php line 17

“Someone seems to be playing with me. This error says that WordPress is trying to load a function that does not exist in its source code any longer.”

You know the WordPress source code a little bit, and you have the gut feeling that this function is not part of the official WordPress core. It is also not mentioned in the official WordPress function reference.

You feel you are only one step away from solving this.

25 min have already passed the clock. Your fingers are still trembling in the tact of your heart muscle, which is pumping the blood through your stressed-out body.

“Heart is a suitable keyword, so let’s continue the operation at the open heart of the website to fix this finally now. ”

You access the file post.php directly from your FTP client and open it with your editor. You comment out the function cookie_shortcode() so that it is not executed any longer, and you upload the file again to the theme directory.

“Hopefully, the last F5 for this session!”

At the screen, the customer’s logo is appearing, and finally, the website is loading as expected!

Instantly you feel as if someone took off the weight of the world from your shoulders.

“That’s enough of trouble for one day.”

You put on your Jacket, already on your way out of the office when it comes to your mind:

“How do I explain to my customer that I’ve updated a plugin on his production website without testing it first on a testing website?”