Recently, a old friend of mine said, on Facebook, that they were having issues with their WordPress website. I volunteered to help them, thinking I’d probably learn something in the process.

The Problem

My friend’s problem suddenly appeared a week or so: when they updated a post, they would see a 404 error. (Here is a video, showing me saving a post, and then getting a 404 error). My friend asked for help from their host, and they suggested she should first update WordPress (she was on 4.8.3 or something), but for some reason her automatic updates also weren’t working.

So there were really two problems:

1. Automatic updates weren’t working on their website
2. They were getting 404 errors when saving posts

The Solution

Automatic Updates

My friend sent me credentials to log into their site, and strangely enough, her site reported that WordPress 4.8.3 was the most recent version (at the time of writing, the current version of 4.9.4).

When I went to turn on WP_DEBUG in their wp-config.php file, I noticed define( 'WP_AUTO_UPDATE_CORE', false ); was set. I also noticed they had a cPanel plugin active, which automatically added that, and even changes WordPress core files in order to handle updating WordPress via cPanel. While that sounds ok, unfortunately its corresponding cPanel cpAddon was deprecated and so doesn’t take care of updating WordPress either.

So I removed that line in their wp-config, and disabled the cPanel plugin. Then WordPress could auto-update as normal. Yeah! But that didn’t fix the 404 error when saving posts.

404 Errors when Saving Posts

This issue was much trickier to track down. I traced through the code and determined:

• the requests were NOT making it to the wp-admin/post.php file, but were instead going to index.php (this is normal when mod_rewrite is on and you’re sending a request to the site’s front-end, but unusual for requests to the admin)
• this issue was reproducible even with all plugins deactivated
• the issue was reproducible on a brand new install (on their server) of WordPress, using the default theme
• when I turned WP_DEBUG and WP_DEBUG_LOG on, there were no additional errors (there were some warnings on some other pages, but nothing related to this)
• the apache server logs reported nothing of interest (they reported a 404 error, which I was also seeing, but nothing more)
• the .htaccess file was unaltered
• when I copied the website’s exact files to my local vvv setup, I couldn’t reproduce the issue

Given all the above, it seemed the problem wasn’t being caused by a plugin, theme, or even WordPress core. I spoke with the hosting company’s support, but they were basically trained to assume all problems were WordPress’ fault.

I posted an issue to the WordPress support forums and to WordPress Stack Exchange to see if I was overlooking something. During that process, I realized an important clue: if I set permalinks to default, instead of getting a 404 error, I would get a different error

Forbidden You don’t have permission to access /wp-admin/post.php on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request

https://drive.google.com/a/eventespresso.com/file/d/14Kzkm14AJ5e7XXKCAuR-4NHBlcOZKdJ_/view?usp=drivesdk

At first I skimmed over this, thinking it was just a different kind of 404 Not Found page. But later I realized this was the crux of the issue: access was being denied to wp-admin/post.php, and so somehow Apache was seeing if it could handle the request by sending it to index.php and then using URL rewrites… or something, I guess I need to freshen up more on how URL rewrites work.

Anyways, also important: there was also an error while recording the error, so there was no trace of it on the server or in logs.

I approached the host’s support folks with this info, saying all signs pointed to mod_security having a bad directive. They responded they would not deactivate mod_security for one customer (reasonable) but they also weren’t going to make any attempt at verifying what I was reporting. This was the first report they’d received of it, so obviously it must be an isolated incident.

I would say their position was reasonable, but with an important exception: they had not tested any other WordPress sites on their server with their mod_security rules. There were other customers using WodPress, but the host didn’t want to test on them, nor did they want to set up WordPress on one of those sites and test it themselves. So they had no proof the error did not exist, and so were  taking that as proof the error did not exist.

What’s more, I pointed out this error came up somewhat recently, and only occurred when saving posts with hyperlinks in them, so it’s possible others’ just hadn’t noticed yet.

Anyways, the solution seemed to just be to change hosts.

Incidental Information

I didn’t realize that before I created the WordPress support forum post, my friend also created one. Once I realized this, I thought I’d point out my mistake to the forum moderators, because maybe they would want to mark my new forum thread as a duplicate. Instead, they kinda censured me for “jump[ing] into other topics.” Either my comment wasn’t very clear, or they only skimmed it, but either way they thought the duplicate issue I was reporting was another topic…  so obviously there was some miscommunication there.

Also, a little way into my original forum thread, the user who was helping me out said they couldn’t see any of my screenshots or videos (which I thought were really helpful) because they were blind! OUPS. To be honest, this was probably my first interaction, ever, with someone online who’s actually blind. This made accessibility issues much more real, for me.

The Take-Aways

So here’s what I learned from participating while helping my friend out:

• mod security. Pretty standard tool for adding security at the webserver level for Apache. Also a possible source of problems when being too aggressive.
• it really does help to have a host who knows/specializes in WordPress. When I saw a host “specialized” in WordPress, I used to always think that was rubbish. WordPress is easy, why do I need a special host for running it? The answer is that, it seems, is that many hosts aren’t setup quite correctly for running WordPress, like my friend’s host. What’s more, many of them utterly refuse to help once you mention “WordPress”. Pagely has been very helpful in that regard for us in running EventSmart.
• helping folks for free can often builds confidence, which can build business. Jackie McBride helped troubleshoot the issue with me, and once my friend was again in the market looking for a new host, Jackie was one of the people my friend was probably going to buy hosting from. That might actually be Jackie’s purpose in “volunteering” in the support forums: acquiring new customers by first helping them out, building a relationship of trust, and then it’s pretty easy to transition to a paid relationship. And I don’t think I mind that: I prefer that to receiving spammy emails or advertisements