Update: a strange problem resolved

[Summer]

Back around the end of September, I had begun moving all of my FarPoint Media sites to a new server, but after moving several Genesis sites over, I began experiencing some strange behavior while in the admin panels.

After I could easily duplicate this problem on every single one of the Genesis sites, I had asked in the old forums if this behavior had been encountered before. I was fairly sure that it wasn't a theme problem, since the initial problem I'd found went away when I moved one site again to a new host.

Nick and I went back and forth on the old forum, spitballing possible causes, but to no avail at the time, except to discover that the problem wasn't limited to Genesis sites. Scouring the WordPress forums for clues didn't help... I'd found a lot of instances over the past few years where others had the same problems when it came up being unable to attach uploaded images, but no solutions were ever presented in those threads, either.

The problem started out as this: being unable to save Genesis theme settings when there was javascript in the header or footer scripts areas, the result being that the page would hang while trying to return a "Settings updated" response (but the information would have been saved in the database). If I removed those items from the header/footer scripts areas, it would save just fine.

During further testing, it was discovered that any javascript present in a sidebar widget would hang the same way, even to also updating the info in the database but unable to return a successful result. Additionally, uploading images had an unusual result: using the "Set Featured Image" link would successfully upload and attach an image, but using the main "Upload/Insert" function would upload an image, but fail and hang when attempting to insert it into the post or page (would happen with new posts or trying to update existing posts).

After a month of arguing with the new network's architect that the issue had to be on the server or firewall and had nothing to do with "poor programming techniques on the part of theme developers", the source of the problem was finally tracked down: WordPress does not play well with an intrusion detection tool called Snort.

At the settings being used on the new network, Snort had decided that several WordPress actions were potential intrusions and blocked them completely: anything called from wp-admin to save or update javascript to the wp_options table was being flagged as a cross-site scripting attack, and the way media-upload.php is inserting media attachments into posts from post.php was being flagged as an SQL injection attack.

So when set at what I can only guess might have been the "paranoid" detection levels, Snort thinks WordPress itself is a hacker tool  🙂

Once the firewall settings were changed to only flag those actions rather than block them, all my sites started working again.

So here's hoping that my two months of pain & anger can save someone else some time later!

---

WordPress / Genesis Site Design & Troubleshooting: A Touch of Summer | @SummerWebDesign
Slice of SciFi | Writers, After Dark

[nickthegeek]

Thanks for the update. I remember trying to figure this out and how confusing it was because some of the transferred sites were fine for a bit then went south all of the sudden.

I recently went through some real headaches with my hosting company when my sites started going really slow. They kept blaming the software and telling me to contact the developer. Of course contacting the developer is easy, I talk to myself regularly.

They eventually relented when I showed them even loading a php file with a single line of code (phpinfo();) was producing errors and taking ages to load. Their concession, the server must have been hacked. We spent a couple of days setting up and rolling out a new server but things we still slow. They kept trying to upsell me and finally I found the problem after going through server files myself. At some point during an update the php.ini file had a line duplicated. This was throwing about a dozen errors every page load resulting in each of my sites having exceptionally large error_logs.

Once I reported the issue they fixed it and the site started working like it was supposed to.

So, the moral of the story, just because the host refuses to believe their server settings might possibly be at fault doesn't mean that they are right. Keep pushing for a resolution.

[Author]

Posts