no posted comments

[Noelb]

ok all event plugins disabled, dont seem to be able to disable sidebars though?

[Noelb]

I still see the "Multiple DNSBL checks will be performed on submission of your comments" message, while the captcha is gone. I think you are missing one

Hrmmm all are inactive.
I did do a @define msg for plugin event spamblock error rbl is local conf, Ive also now commented that out

[onli]

Okay, there is something off there. I also get no feedback message after submitting the comment, as if the comment flow did not engage.

There is still this message: "Submitted comments will be subject to moderation before being displayed." Is that coming from the entry settings? Can you disable that as well? I'm looking at the newest entry of the blog.

[Noelb]

Okay, there is something off there. I also get no feedback message after submitting the comment, as if the comment flow did not engage.

There is still this message: "Submitted comments will be subject to moderation before being displayed." Is that coming from the entry settings? Can you disable that as well? I'm looking at the newest entry of the blog.

That must be a default setting, yes, its checked by default I have now unchecked that option as well. On the latest about MFA

[Noelb]

haha yes - in relation to pvt msg

[onli]

Okay, how strange! I noticed the preview is also not working, you just see the regular article.

It is as if something is filtering out all the form parameters the comment formular set for the POST request before the serendipity code can react to it. Is there something between visitor and server that could cause that? I don't see cloudflare headers, but something similar? This is not a known error state of serendipity, I would bet it is caused by the hoster.

If you can't think of something I'll next check the comment flow and see where to add debug output, maybe we can pinpoint that way when those parameters vanish.

[Noelb]

Okay, how strange! I noticed the preview is also not working, you just see the regular article.

It is as if something is filtering out all the form parameters the comment formular set for the POST request before the serendipity code can react to it. Is there something between visitor and server that could cause that? I don't see cloudflare headers, but something similar? This is not a known error state of serendipity, I would bet it is caused by the hoster.

If you can't think of something I'll next check the comment flow and see where to add debug output, maybe we can pinpoint that way when those parameters vanish.

nothing in between, interesting the preview was working earlier when i checked it, i host it locally so have direct access to everything so can try anything, apache confirms rewrite is loaded, I doubt the vhost block has been changed in a decade or more , I'll send you PM with that, note, I did try without all the phpflags and openbase and so on, so cant see that being culprit.

[Noelb]

Im off to bed, need to get up early, if it helps, I just replied to a comment from the dashboard->comments, and it accepted it into pending, I could see it as well, but that uses the serendipity_admin.php url in the POST

[onli]

In the include/functions_routing.inc.php is this line 350:

Code: Select all

if (!empty($serendipity['POST']['submit']) && !isset($_REQUEST['serendipity']['csuccess'])) {

Please change it so there is one line on top of it:

Code: Select all

print_r($serendipity['POST']);
if (!empty($serendipity['POST']['submit']) && !isset($_REQUEST['serendipity']['csuccess'])) {

In line 363 and 364 are these two lines:

Code: Select all

header('Status: 302 Found');
header('Location: ' . $sc_url);

Comment them out:

Code: Select all

//header('Status: 302 Found');
//header('Location: ' . $sc_url);

Then please try to submit a a comment via the regular comment form. You should come to an empty page with code somewhat like this like this:

Code: Select all

Array ( [entry_id] => 4 [name] => John Doe [email] => snip [url] => [comment] => test 123123 [replyTo] => 0 [token] => snip [submit] => Submit Comment )

Then please show the content here.

If the regular article view occurs instead, is there a similar line at the top then? With what content?

[Noelb]

done, the page is blank no nothing.
actually it was blank just clicking into the article before commenting, but made the change so I could, typed my comment, re-did the change, submitted, blank page, error logs show nothing still

strange, its so blank, right clicking in chrome doesnt even bring up the option for inspector or source

[onli]

If the entry itself is blank there likely is a PHP error, though there definitely would be an entry in the error log then. It all works again if you remove the

Code: Select all

print_r($serendipity['POST']);

?

[Noelb]

If the entry itself is blank there likely is a PHP error, though there definitely would be an entry in the error log then. It all works again if you remove the

Code: Select all

print_r($serendipity['POST']);

?

Yes.

I also loaded the main page, loaded inspector, and then went back in to the article, again blank page, but inspector caught:

net::ERR_CONTENT_DECODING_FAILED 200 (OK)

connecting to the html page we have been using in our tests that your aware of.
Hrmm theere only half a dozen vhosts on that machine, and I've many times thought the issue is with php itself, but one vhost being osticket, is pretty picky about php errors, and it runs fine.
I dont know what else to try, could there be an entry in the database thats causing this? I'm thinking about doing a test by doing a brand new install using a dummy temporary subdomain and creating a dummy article and see if it works, but I wont have time for that until weekend, that I guess would eliminate or confirm php, if it works, I'll grab a backup of main blog and load it up, ad see if errors persist. Bare in mind I've done update to update and update over the years, there are some plugins with directory dates going back to 2012 - although not used, could there very presence bring aout a problem?

Also again, no log files show anything, teh 2k11 logs dir log only shows the fetch to github for plugins every so often, likely when we were tinkering in that area yesterday, that file is 0 bytes since midnight (currently 1347)
servers php_error log still 0 bytes and nothing in main server or vhosts log error logfiles except the usual when apache's been restarted.

[Noelb]

likely unrelated, but did you notice that articles lost all its paragraph formatting since all plugins were disabled - but I'll keep them all disabled until posting is accepted again.

[Noelb]

likely unrelated, but did you notice that articles lost all its paragraph formatting since all plugins were disabled - but I'll keep them all disabled until posting is accepted again.

it bugged me and i had spare 15 mins, well i can confirm php is fine, my test fresh install, took the comment!
interestingly this only seems to work with no rewriting in the appearance section, if I enable errorhandling or mod rewrite, it goes to text only appearance, no graphics, no comment this really comes back to your earlier thoughts on mod rewrite being the problem I think, I'll try look at testing that in my dummy test host later today.

hrmm mod rewrite seems to work, well by apache testing anyway. not sure how to use php to test, but I've come to despise php8.2, seems it was ignoring servers wide the disable_functions, phpinfo shows things like exec disabled, but it actually wasnt.... now it is since i moved those options back to php.ini, so have lost flexibility between vhosts, damn that mob are destructive in their changes

[onli]

I don't really understand why just having the print_r in the file causes the encoding error - on my servers that is not a problem. https://stackoverflow.com/questions/140 ... ing-failed suggests that either gzip or an unicode issue might be the source of the problem there.

short on time now, but we can ofc also change the code to write to a file instead, maybe avoiding this error.

For a new install, yes might help, I still think there is some server component in play here that strips the form parameters.

For old plugins, yes they are loaded anyway to determine version, so theoretically can cause issues. Usually errors at the start though, not later.