Debugging a 500 error with Wordpress
Everyone's nightmare
Today I woke up, and logged into slack and received a screenshot from one of the team members showing that the sales site was down. I don't manage that site, I didn't set it up, and I don't maintain it, but it fell to me to fix it. A lot of developers out there can relate to this.
So I know the site was made using wordpress with Apache as the web server and I have ssh credentials into the site. From the site itself there was only the error:
"There has been a critical error on this website. Learn more about troubleshooting WordPress"
So I needed more information. But from this we can see the server is running (the machine itself is not down), and it is returning a 500, meaning that the apache webserver is functioning fine, but the application is returning a 500. This indicates an error in wordpress, not apache or the hardware.
Looking into the apache
Just for kicks and giggles and to make sure I take a look from one end to another, I did a quick check in the apache logs:
$ tail -f /var/log/apache2/access.log
wordpress-vm.c.project.internal:80 <IP> - - [02/Nov/2022:16:02:18 +0000] "GET / HTTP/1.1" 301 405 "-" "Mozilla/5.02257024 Mozilla/5.0 (Linux; U; Android 2.2; en-us; Nexus One Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
wordpress-vm.c.project.internal:80 <IP> - - [02/Nov/2022:16:02:19 +0000] "GET / HTTP/1.1" 500 5497 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36"
And clients are being sent either 301 redirects or 500 errors. So everything is fine with apache.
Looking at the sites-enabled I can find where the wordpress installation is:
$ cat wordpress.conf
<Directory /var/www/html>
Options -Indexes
AllowOverride FileInfo
</Directory>
So the site is in /var/www/html
Checking wordpress
First I logged into our wordpress admin site. Everything was fine there. So it seems to be an issue with rendering the pages, rather than the admin site. The site had just been upgraded to version 6.1 and the standard fix is to eliminate the plugins. The site is using a dozen or so plugins and some are critical to the look/feel of the site so I didn't want to just disable them all and then end up with a site that works, but looks like garbage.
The next step was to see what the error is. To do this I turned on the debugging for wordpress.
I opened the file <site-root>/wp-config.php and added these lines:
/* That's all, stop editing! Happy publishing. */
# DEC added debugging to trace 500 error
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
These turn on debug mode, ensure it isn't displayed to the users, and send output to a debug log file. That log file is located under <site-root>/wp-content/debug.log
Upon saving that file and refreshing the site I received several errors. The key one is this one:
[02-Nov-2022 16:08:54 UTC] PHP Fatal error: Uncaught Error: Call to undefined method WP_Textdomain_Registry::reset() in /var/www/html/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LanguageSwitch.php:139
Stack trace:
#0 /var/www/html/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LanguageSwitch.php(119): WPML\ST\MO\Hooks\LanguageSwitch->resetTranslationAvailabilityInformation()
#1 /var/www/html/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LanguageSwitch.php(73): WPML\ST\MO\Hooks\LanguageSwitch->changeMoObjects()
#2 /var/www/html/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LanguageSwitch.php(48): WPML\ST\MO\Hooks\LanguageSwitch->switchToLocale()
#3 /var/www/html/wp-includes/class-wp-hook.php(310): WPML\ST\MO\Hooks\LanguageSwitch->languageHasSwitched()
#4 /var/www/html/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
#5 /var/www/html/wp-includes/plugin.php(517): WP_Hook->do_action()
#6 /var/www/html/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php(1178): do_action()
#7 in /var/www/html/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LanguageSwitch.php on line 139
PHP Fatal error is definitely no good.
This tells me that the plugin wpml-string-translation is the cause of the problem. So I disabled that plugin and the site came back online.
Cleanup
To cleanup, I just went in and commented out the debug lines in the wp-config.php
I left them there in case the next guy needs to do the same.
/* That's all, stop editing! Happy publishing. */
# DEC uncomment these to enable wordpress debug logging. Debug log is in ./wp-content/debug.log
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);
# @ini_set('display_errors', 0);
Then I deleted the debug log as it is not necessary to have around for no reason.
Conclusion
My part here is done, it's up to the actual maintainer to now communicate with the plugin provider and report the bug. The site is up and running and things are working in both english and spanish. I'm not 100% certain exactly what the plugin does as I'm not the one who configured the site, but as always, I'm there to help if the maintainer needs it.