serendipity_event_multilingual: not compatible with PHP 8

[floppes]

After I was forced to switch to PHP 8 by my hosting provider, I upgraded Serendipity to 2.4.0. This worked fine except for the plugin serendipity_event_multilingual.

serendipity_event_multilingual uses the PHP keyword each at serendipity_event_multilingual.php:280, which was removed from PHP 8.

I tried to replace
while(list($key,) = each($properties))
with
foreach ($properties as $key => $property)
but I wasn't lucky. My PHP skills are basic. My blog loads without PHP errors, but switching the language doesn't work anymore...

[onli]

Maybe something for @stephanbrunker ?

[surrim]

It's part of additional_plugins repo. I included your code fix on the new fix/801-serendipity_event_multilingual branch.

I think there are other things broken somewhere. Unfortunately I can't investigate much time on S9Y at the moment. But this branch can be used by whoever wants to fix this issue.

[stephanbrunker]

I have a running serendipity_event_multilingual on my blog, under PHP8 with no problems. There is just the issue that I am effectively running my own fork of s9y now with the additional features depending on a little cleaned up core and merge the new main s9y commits into it. So, I am not 100% sure at what point it diverged and depended on the altered core functions.

But if I did everything correctly in order, the commit stephanbrunker/additional_plugins@f4f5a95 should bring a major improvement to the multilingual plugin without it depending on the altered functions of my fork and stephanbrunker/additional_plugins@ee4812a is an additional PHP8 bugfix. If I remember correctly, the "language determination in the core" commits from the multilingual changelog are in the main s9y build now and only the major multitlingual commit was held back because it depended on these 2.4 changes.

So, feel free to pull these two commits from my repo.

I also started to perfect the multilingual functionality by moving the plugin to the major s9y and adding multilingual mail support - e.g. that the language of someone making a subscription is stored and the notification mail is then sent to him in his language. But never completed this one because of obvious reasons because that needed major changes in the core mail functions.

And now I am going back to amusing myself with an Joomla page, where all the additional components don't work if I upgrade from 3.10 to 4.0 and support of 3.10 is terminated in August 2023.

[floppes]

Thank you Stephan, I applied your two patches and the plugin works again :)
I hope the patches will find their way into an official release to help others, too.

Something else I noted:
I created my own template years ago with custom navigation where I have links to change the language. Until now, the links looked like this:
index.php?user_language=en

This did not work with version 2.4.0 anymore and I had to change them to
index.php?serendipity[user_language]=en

[onli]

Where do those two commits live exactly? https://github.com/stephanbrunker/Serendipity ?

[floppes]

Here and here

[stephanbrunker]

I did not change anything on the link structure, the format with [user_language] already existed when I first installed the plugin. I had some issues linking the commits here, but I fixed them.
Correction: Iooking at the Changelog, I did change the value generated from the sidebar plugin. It was so long ago, I think for unification purposes ... the other structure already existed, so I conformed that and it says that is had something to do with the POST values too.

[surrim]

I cherry-picked the two commits into the branch and made a pull request. As I said I can't test it here, but if it's fine, we can merge.

[onli]

user_language was broken in #650 (I think). We can not switch the plugin now to just use serendipity[user_language], as that would break all versions before 2.4. We will have to add a version switch to the sidebar plugin.

I added a comment to the PR.