Wow, diese SQL-Abfrage sieht ja wirklich übel aus. Ein Problem erscheint mir, dass plugin/tag mehrfach im Request vorkommt. Bist du durch die Abfrage durchgestiegen? Doppelt sie da einfach joins über das zweite plugin/tag/tag4? Habt ihr ähnliches auf euren Seiten gesehen und wie kann man das eventue...

Confirmed. The plugin seems to not be compatible with 2.4.0 anymore. I will have a look at this soonish (but of course would be happy if someone beats me to it).

Die Fehlermeldung wird im log stehen, phps error.log oder das vom Webserver. Mit der wird dann bestimmt klar, an welchem Plugin es hängt (oder ob es das Theme ist).

Awesome :) We could consider adding this as an option to the s9y configuration, but on the other hand, the the PHP configuration can also solve this + the existing offset configuration might be enough. What do you think?

Interesting! Maybe this is about the timezone not being set in PHP, and cPanel solves this correctly? Have a look at https://stackoverflow.com/questions/20451719/cannot-set-date-timezone-in-php-ini-file and https://www.php.net/manual/de/datetime.configuration.php#ini.date.timezone please, is the cor...

Okay, but it should, right? You said "the comments are displayed with an offset of one hour (-1) from the real time which is also the server time.", so it did not use GMT before. Could you show the output of "date" run on the server?

I understand, but getting either that time to the target time or applying the offset is the only solution we have. The option above is interesting for that, the "use server timezone" option. If toggling that one does not help I think we have no options in serendipity left (though if toggli...

Then that's the problem. You have to set the offset to correct whichever time is displayed in that configuration. Serendipity simply calls `date('H:i')` for that part of the description, which formats a timestamp and falls back to `time()` to get one if none is given like here. Which is exactly what...

I also realized my theory how this work is probably wrong. The code probably has no trigger for the server offset because it calls serendipity_serverOffsetHour() for that - and that one applies the offset depending on the configuration. So we save the time the server returns and then return that tim...

Okay. I had a look into the code. Code walkthrough follows. When we store a comment, that is done in serendipity_insertComment. The timestamp is generated like this: serendipity_db_escape_string(isset($commentInfo['time']) ? $commentInfo['time'] : time()); So it is very directly saving the timestamp...

Okay, I would trust the hoster here, this is likely a serendipity bug. One question more: Do you know whether old comments are also displayed with one hour off? (Then it might be an error in the timestamp generation, while if it is only wrong with new comments the issue might be when saving comments...

I don't really have an idea. Blog entries are published at the correct time?

In 8.0 we indeed fixed all warnings in the core apart from doubled language constants, where we suppressed the errors in the language file loading function. But sure, in 8.1 and 8.2 there will be new warnings that would need to be addressed.

widdi, kannst du mit git umgehen? Vielleicht könntest du ja das Permalink-Plugin für alle reparieren? https://github.com/s9y/additional_plugins/ wäre das Repository. Zu Spartacus, das ist natürlich für PHP 8.0 aktualisiert worden. https://board.s9y.org/viewtopic.php?t=25672 ist ein Beispiel bei dem ...

Wait, that might be a misunderstanding. It is supposed to be based on the version string. The bug is that despite the version string marking a stable, some installations show error messages anyway. I don't see how setting `$serendipity['production'] = true` manually could fix that? And I think it di...