I wrote in WYSIWYG hides WordPress hacking that my client was mysteriously unable to save edits or new Posts or Pages. Whatever save type button we clicked, the edits would silently disappear, and a completely blank admin page would be the response. It was my job to fix this odd behaviour.
The first real step I took was to note that his copy of WordPress was out of date. I was pretty sure that updating WordPress and the half dozen plugins he uses would see him right.
I loaded up v2.3.3, the current release version, ran the upgrade script, checked and updated his plugins, then confidently created a test post. No joy. The problem remained.
Next, check for correct permissions and content
Using FTP, I compared his WordPress install with one of my own. I confirmed that all permissions seemed to be correct. Since we also suspected he’d been hacked, I opened his
wp-config file and his theme files — the only files that weren’t replaced in the upgrade — and looked for anything that didn’t belong. They were clean and in order.
This WordPress install should be working correctly.
Disable a suspect plugin
Googling led me to believe that one particular anti-spam plugin he was using may be the problem. I disabled it. No change.
No help in the forums
Checking the WordPress forums led me to several threads from people with the same ‘blank admin page’ problem. There were no answers that helped me.
I did pick up on a fix for the spam injection though, involving the xml-rpc file. But that needs a separate post.
Alternate access to the database
Next up I used MarsEdit to create a new post on my client’s blog. Ah, now there was progress: that was successful.
I also used PHPMyAdmin to access the database directly. This allowed me to remove the unwanted spam from his post. So again, there was success.
So now I knew that direct access to the database was successful, while editing posts through the web interface was the problem. There was something wrong with the WordPress files themselves.
The files were all fresh and up-to-date, permissions were correct, and there were no signs I could see of malicious scripts or whatever on the server. I had ruled out the suspect plugin. Or had I?
Another look at the plugins
I decided to look at the plugins again. They were all up-to-date. Several of them, such as Bad Behavior, I use myself, so I believed they were not the problem. But when something doesn’t work there is a problem somewhere.
I decided to disable all the plugins simultaneously and then enable them one by one until the problem showed itself. Thank goodness for the Deactivate All Plugins link on the Plugins page.
OK, all plugins deactivated, and the blog worked correctly again. Hooray!
I reactivated Akismet. The blog worked.
Reactivate Bad Behavior. OK.
One by one I reactivated each plugin, and then tested editing a post. Each time it worked.
Until there was just one plugin left … ah, I’d found the culprit, and it was the one I’d suspected in the first place.
Reactivate. Test. Editing a Post worked fine. Wait a minute! This was supposed to be the problem. I shouldn’t have been able to edit a post successfully.
OK: in the first place, with all plugins active, we could neither edit a post nor create a new post.
Nevertheless, after deactivating and then reactivating all plugins the problem was fixed.
The end result was the same — all plugins active — but the effect was different: now editing or creating a post worked correctly. Strange but true.
I’m guessing that one of the plugins was the problem, before I updated it, but that somehow the update didn’t ‘register’. I suspect that deactivating and reactivating the plugins forced something else in WordPress to register the change and correct the problem.
The p*rn in the post
So now the ‘save’ part of my client’s blog was working correctly, but let me tell you about the porn in the post … in another article to come.