no posted comments

[Noelb]

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.

That fresh install, when I deleted all content, and changed it to mod rewrite, and same with apache errorhandling, it failed, (at least that means my database isnt corrupted), so yes its server related somehow, I tonight built php 8.2.29 no change, though I did discover despite what phpinfo reports, most php_admin_values are ignored - thankfully open basedir is still honored, luckily this upgrade only occurred nearly 4 weeks ago, so had to move the disable functions into the ini file, but these directives wont be teh cause as I had them completely disabled for a day when starting to figure this out, its completely got me stumped. based on the dummy test install results being same now I re-enabled the plugins after comparing the new tests plugins, but leaving a couple in use - meaning now most of the old plugins are gone from the plugins dir, maybe drastic, but I got nothing to lose at the moment and I've already had to delete nearly 200 spammy tracebacks haha, I'd end up with RSI if it kept going.

Copy the little time at moment, I really appreciate the time you've spent helping on this, thank you, and I too wont have much availability for next day or so anyways, Friday is always hectic and long day here.

[onli]

To avoid the encoding error, try replacing the print_r line with this:

Code: Select all

ob_start();
$output = file_get_contents($serendipity['serendipityPath'] . 'templates_c/testlog.txt');
print_r($serendipity['POST']);
$output .= ob_get_contents();
ob_end_clean();
file_put_contents($serendipity['serendipityPath'] . 'templates_c/testlog.txt', $output);

Then do for example a comment preview, you should then immediately see a logfile under templates_c/.

For the trackback spam, I think there will be no harm to our debugging here if you re-enable the default spamblock plugin. It has a couple effective protections against these spammers, like the IP validation.

[Noelb]

Thanks, that did out to a file, its only contents are

Array
(
)
Array
(
)

[Noelb]

may have fixed it!

I'm just going to check live.

I reinstalled 2.3.5 on dummy site
re-upgraded to 2.5.0 and it worked, applying it shortly on live site, will report back

[Noelb]

Hi Onli,
OK, your initial suspicion I think was on the mark - php - 8.x to be precise
With no changes to my vhost config, or my php.ini copying as pointed out errorhandler did no longer work = this must be a php failure, moved to mod rewrite , and still no go, but then it struck me, the htaccess file only had 2 lines in it when it was changed over, in the test site it has dozens, so might be 2 part, serendipity did not create the big mod rewrite rulesets it did in the test domain, 195bytes V 2.1k, so I enabled loglevel alert debug:trace8, and a lot of things looking going PT, so stopped, backed up - again, reinstalled 2.3.5, re applied the 2.5.0 update, changed apache errorhandler to mod rewrite, and voila, we all of a sudden had 2.1k htaccess file, ran a test, it succeeded, your testlog file also was no longer showing empty array, it was outputting data, uncommented our 2 lines for Header status/Location, tested and worked as it used to.

So I'm gathering in a summary, the initial update didnt go to plan, and/or, changing from errorhander to mod rewrite, back to errorhandler and back mod rewrite in trying to debug all this confused it. Second, the fact errorhandler no longer works says php has a big part to play in this mess.

I guess using serendipity for near 15 years, and every upgrade working, I was a little complacent, and need to check everything, the fact it coincided with major 7-8 php upgrade
I should have known better to test and test again

I do appreciate your time on this, I cant explain why the change from E/H to M/Rewrite didn't populate, only that the initial update must have failed at one point, because the re applying 2.5.0 was the same archive file I d/l'd a month ago, so couldnt have been newer,

Thanks again, and I'll let you enjoy your Sunday in peace

[onli]

Maybe also a s9y bug in there, if the .htaccess was not properly recreated. If you stumble over that again please let me know.

For now I'll be very happy that the site is working :)

[Noelb]

Maybe also a s9y bug in there, if the .htaccess was not properly recreated. If you stumble over that again please let me know.

For now I'll be very happy that the site is working

Me too!

And yes, because everything I did after this weekends old_backup->re_upgrade, I'd done before. Like that apache errorhandler to mod rewrite, I'd done a dozen times, probably more in the past week, thats why I'm sure something errored in the initial update, although why apache errorhandler no longer works is another question I'm not game enough to change back to it to find out LOL.
Thanks again...