Jon York

Just in case anybody needs to know in the future (as I needed to know today!), WordPress 4.2.24 will NOT run on PHP 7. You have to use 5.2.3 to get it to run.

It’s not a plugin problem. Version 4.2.24 of the WordPress core itself won’t run on PHP 7.

• This reply was modified 6 years, 7 months ago by Jon York.
• This reply was modified 6 years, 7 months ago by Jon York.

I think support for this plugin has unfortunately been dropped. Mine has stopped working about 2 days ago. Doesn’t work on any of 6 different sites spread over 3 servers and two web hosting companies. ALL sites now have plugins that have gone without updates for more than 2 days.

Also, looking around at the developer’s github, there’s nothing more recent there than 2 years ago!

Time to look for a new one.

I THINK I’VE FOUND THE PROBLEM!!

If you guys are having the same problem I’m having – it’s in the mod_sec (ModSecurity) rules that you have setup on your server.

If you have root access, you can probably fix the problem yourself. If you’re on a shared hosting server you’ll probably have to ask the host to do it. And if you’re on a cPanel server to which you have root access, you can ask cPanel to help you – they have awesome support.

To find out if you’re having the same problem I am – you have to do this. Do any of the actions that cause you to have the problem. Whether it’s trying to create and save or post a new article or edit an existing one. Go ahead and do the thing that causes the problem. For me, that meant simply typing in a few letters to an existing article and clicking Update. That always causes the problem.

Then, this is the important diagnostic step. SSH into your server and type in this command:

tail /etc/httpd/logs/error_log

I’m on a cPanel server, which has logs in different locations than the guy I got this info from – but this command still worked.

It produced this result:

“/etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/RESPONSE-980-CORRELATION.conf”] [line “37”] [id “980130”] [msg “Inbound Anomaly Score Exceeded (Total Inbound Score: 20 – SQLI=10,XSS=10,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): Detects MSSQL code execution and information gathering attempts”] [tag “event-correlation”] [hostname “yoursite.com”] [uri “/index.php”] [unique_id “WhStuaa5lh-WAkMBT3M1qQAAARY”], referer: http://yoursite.com/wp-admin/post.php?post=888&action=edit

You should see this at the end or near the end of this log file when you type in the “tail” command.

The text in bold gives you clues. The first bold word is “modsec” – that tells you that a ModSecurity rule prevented you from completing this action. And if that’s the case, that’s good news, because you can solve this problem – if it’s caused by ModSec!

The “Inbound Anomaly Score Exceeded” tells you the reason this action was prevented by the ModSec rule is because it exceed the score that your ModSec rules will accept.

“Detects MSSQL code execution” – is basically saying that ModSec believes someone is trying to inject malicious code into your site through an text input code injection action.

The next part “hostname yoursite.com” that will identify for you – that you are in fact looking at something in the log that is about the site you’re having trouble with. So if you see your domain name there, you’ll know you’re looking in the right place.

This guy has published very detailed instructions on what to do – however, know that each case will be a little different so you probably won’t be able to follow his instructions exactly.

https://www.tweaking4all.com/web-development/wordpress/mod_security-fix/

What I got from that is you can either readjust the sensitivity of your mod_sec settings, or you can create special rules to apply specifically to your copy of WordPress on your domain, or you can turn mod_sec off altogether.

I wouldn’t recommend turning mod_sec off altogether because it does provide a good deal of security for your server. But, in my case, I turned it off just for a few seconds, so I could publish this one thing I needed to publish. Then I turned it back on.

I’m not nerdy enough to be able to follow all his instructions, but since I have a cPanel server, I’m asking them to help me out. I know they’ll be able to tweak it just right.

Oh, also if you’re on a cPanel server, login to WHM and go to Home/Security Center/ModSecurity Tools. This will show you the exact same information you can get by using the “tail” command, but it will be in a much more readable format.

It will show all the sites on your server that are having problems with mod_sec. Just remember, some of the sites might be having legitimate problems and you shouldn’t mess with them. In my case, I saw a lot of sites that were getting tangled up with ModSec that shouldn’t have been. But I also saw one site, that I haven’t touched in weeks – also run into a ModSec rule – from an IP address that wasn’t mine. So that was some kind of hacker/spammer trying to do something bad. So I won’t mess with the rule on that site.

But it will show you every site that’s having problems and it will show you the exact ModSec rule that was violated and therefore responsible for clsoing down whatever action you were trying to complete.

Even if you can’t fix it yourself with this info – this info will be exactly what you need to show someone who can fix it. It’ll get them on the right path as quickly as possible!

Good luck!

UPDATE: As I mentioned, I’m on a cPanel server. I have ConfigServer firewall and its other suite of software installed. I just noticed they have a ConfigServer ModSecurity rule plugin that was running on my server. I just disabled it – AND EVERYTHING STARTED WORKING PERFECTLY!!!

So, I still have the OWASP ModSecurity rules in place – that come with cPanel so the server should still be protected. Either ConfigServer rules are just bad – or they conflict with the OWASP rules. (If you’re on cPanel you should know what I’m talking about).

• This reply was modified 8 years, 6 months ago by Jon York.

This exact same thing is happening to me! I’m surprised, but relieved to see it’s happening to so many others.

I’m on version 4.8.2. And this has been happening for a very long time. Eight to ten months at least.

First, I was able to actually publish a new post – which I’m not always able to do. And I did copy & paste all the text into it. I was careful to make all edits before publishing though because in the past, I’ve been able to publish initially but unable to save after making any edits after initially being published.

However, after I published it, I decided I wanted to add some images to it. No matter what I tried, even though the images would show up in the preview – they wouldn’t save. Whenever I clicked Update, it would take me to the home page of the site (instead of reloading the edit page), and the new images were not there. However, oddly, I could edit text and save with no problem!

Finally, I had to copy the Text of the post (including all code), directly into the database. There was no other way to get the text and code into the database except to put it there directly. But, even after doing that, the new page with the images still wouldn’t show up! But the code for the images was in the database.

Then, I tried one of the suggestions someone left here, which was to go into Quick Edit and change from Draft to Publish. Mine was already on Published, so I changed Categories, and suddenly, the post with my edits showed up!

It was only after going into Quick Edit and changing to a different Category that suddenly everything worked.

This is indeed very strange and I would think it was something on my end, if not for all the rest of you who are having the exact same problem.

But, I thought I’d check something else out before I post this message. I just went in and tried to add one more photo – and it wouldn’t do it. It did exactly what it was doing before. I added the photo, it showed up in the preview, but the minute I pressed Update, it went to the homepage and the new photo was not there.

This is so very infuriating. Obviously it’s happening to a lot of people and WordPress is apparently not addressing it in any way.

• This reply was modified 8 years, 8 months ago by Jon York.
• This reply was modified 8 years, 8 months ago by Jon York.

Just curious – what version of WordPress are you using? I have a client who had this problem after the host upgraded to php 7 and they were running a version of WordPress from 2013.

Clear instructions are not actually given on the admin page. All the admin page says is click here to download the pre-ajax version. But when you get to that page, the only thing to download is the current version!