Are you up to date with SP core and plugins is forst question.

Second question is… if this is one post it suggests there might be something in the post content that is failing. Is that possible? Anything special or different about the content? Did you use an Emoji for example?

Thanks for the quick reply!

WP, SF and all plugins are all current. (SP Version: 5.5.8, Build: 13000)

I’ve been ruling out plugin conflicts all morning, and I (and others) have been able to comment on a dozen plus other topics successfully. Content of the post is simple, no emoji or any other special characters.

I’ve optimized db tables and continue to get the blank page with ahah URL. Server error logs include no entried with forums/ referer. But I did notice this new warning in the SP error log…

23 June 2015 11:25 am | spaErrWarning | 3 | php

file: /simple-press/sp-api/sp-api-globals.php
line: 140
function: spHandleShutdown
Warning | ini_set() has been disabled for security reasons

PS: I also attempted to rebuild index for forum where the topic is posted.

I then deselected the “load javascript in footer” admin option and that made no difference.

Have tried from different computers and two different user accounts…only this topic is still throwing the blank page with ahah URL…

http://tripawds.com/forums/eating-healthy/tripawd-nutrition/

Any other “housekeeping” options recommended?

OK – let’s talk mod_security.

It is – to put it bluntly – the bane of a developers life.  It can effect a single forum post (for example) because it is looking at patterns of characters in the url. And each and every topic will have a different combination of characters.

So ye – it would be worth looking at the url for the topic post in question to try and ascertain if any portion of the url broke one of the mod_security rule sets.

Well… before seeing your last reply, I completely disabled mod_security for the domain, and the problem persisted.

I was finally able to reply to the topic in question only after disabling SP plugins (Auto Lining, Blog Post Linking, Post As, Captcha, and Subscriptions) AND typing in the comment instead of pasting in what I had copied. FYI: We only have Captcha enabled for guests anyway.

I now how other members reporting identical behavior on other topics, but this is clearly not all topics.

My gut feeling here Jim is that this is going to be environmental or something to do with post content. You do appear to be having a totally unique experience with this which is why I favour the former of the two – especially if you are now seeing random failures.

So what about this http 301 condition you are seeing? I admit this is away from my knowledge comfort zone but why is the server rejecting a pretty standard call to the index.php file? What has changed server side that might be having an effect here?

I am also a little worried about the ini_set() being ‘disabled for security reasons’. Has this been a long term thing or is this recent? Leaving aside the fact that this failed call should not leave any trace in the error logs (a different and unrelated php issue), the particular ini item being set has (a) been in force for many years now and (b) was particularly put in place to overcome a WordPress shortcoming . I remember that much bit am damned if I can remember exactly that it was now after all these years. (Steve will probably remember but he is on vacation currently). But it did have something to do with posting! So can that be turned back on to see what then happens?

Thank you for the additional feedback.

My server manager assures me no mod_sec changes have been made recently, at least not within the last couple days when this started happening. But I did finally identify a pattern of the post failing when including certain keywords, then dug deep and found a mod_sec “pharmacy spam” rule including those words…odd how the issue persisted when disabling mod security altogether. But at least I’m on to something!

I am also a little worried about the ini_set() being ‘disabled for security reasons’.

Me too. Not knowing ini_set from tea set, I assumed it was something SP had disabled. Apparently not, and I will look into that too.

Why this all started happen suddenly has me most baffled. Thanks again!

I checked up on that ini_set item. The problem was that posts (and this is blog posts as well as forum posts) could be saved but would lose all their content. This was due to a WordPress issue.

Now I think, in the interim, the WP team have probably fixed this up but as I am not 100% sure we keep the call in as it is essentially harmless. If you are not having empty content issues then you are probably safe here.

Yellow Swordfish said
If you are not having empty content issues then you are probably safe here.

in the past we have had issues with posts not saving upon page refresh. And this new aha issue returns an empty page when trying to save. Perhaps the two are unrelated, but we haven’t heard reports of the former in a while. The latter still has me baffled…

Guess I was just looking for clarification about where ini_set() is configured, and how it can be enabled since i don’t know how it got disabled.

I presume “probably safe” means I could turn it back on to see if that helps our issue. Assuming it’s a server level thing and not a WP or SP function, I wonder if it is in Apache, PHP, SQL or??? I can consult with my server manager once I know a bit more.

Thank you!

jim said

in the past we have had issues with posts not saving upon page refresh. And this new aha issue returns an empty page when trying to save. Perhaps the two are unrelated, but we haven’t heard reports of the former in a while. The latter still has me baffled…

Sorry – I thought you said this was resolved due to a mod-security setting. Is that not now the case?

Guess I was just looking for clarification about where ini_set() is configured, and how it can be enabled since i don’t know how it got disabled.

The php.ini file is the main configuration file that sets up all the options that php needs to run and do its stuff. Think of it like a Windows ini file or a Mac OSX preferences file.

It will be on the server somewhere – your server guy will know.

ini_set() is a php function that allows code to modify the ini settings during run time. To be honest I have not got a clue where you set this option to disallow ini settings being modified in code. That might be an Apache thing. I really don’t know off-hand, But again – whoever looks after your server should know. WordPress calls the ini_set() function quite  few times…

Yellow Swordfish said
I thought you said this was resolved due to a mod-security setting.

We just had another user report the issue, after I whitelisted the mod_sec rules I thought were causing the problem (posts not saving with ahah URL).

In earlier troubleshooting I was able to replicate the issue after disabling ModSecurity altogether.

The php.ini file… ini_set() is a php function… might be an Apache thing….

Thanks for the clarification!

When you disabled mod_security did you reboot the server?
And stepping back a bit… what has actually changed in your environment that this suddenly starts to happen?

Yellow Swordfish said
When you disabled mod_security did you reboot the server?

No, apparently only a restart of Apache is required for the changes to be applied

And stepping back a bit… what has actually changed in your environment that this suddenly starts to happen?

That’s the odd thing, nothing that I know of. We did have a consultant harden the server security, but that was over a month ago. Perhaps this issue of posts failing is coincidental due to new instances of users discussing certain content (medication for their dogs).

With that said, I did discover and whitelist certain “antispam” mod_sec rules and have since been able to post content that previously threw the blank aha page.

Still monitoring things and awaiting any further reports from members.

FYI: Prior to doing that, I did re-enable ini_set() and that made no difference with this issue. But I have not yet seen another entry about it being disabled in the SP error log either.

As usual, having this forum as a sounding board for tossing around troubleshooting ideas has proven valuable. Thanks again for all the feedback!

Web developers the world over shudder at mod_security. It is a good idea and on a website where the urls are known and fixed then it is just fine. But on any website where the urls are dynamic ‘permalinks’, then there will always (and yes – I do mean always) be the odd problem. Let’s hope this is all it is.