Fix #292 #297 deprecated id resolving functions

[michitux]

• Add a new gerneric resolver to resolve ids without cleaning
• Replace deprecated calls
• Remove some unused variables

Tests are passing but I haven't tested this any further. This is basically what we discussed in #299.

[michitux]

Okay, CI shows that tests are passing on PHP 8 but not on 7.4, really strange. On master all tests are passing, I've just fixed the CI setup. I'll try having a look in the next few days but if somebody has any idea, please let me know.

[michitux]

Okay, reading the log from the start helps, it seems like PHP 7.4 doesn't like include in the namespace. This changed in PHP 8. Not sure how to solve this properly. It seems to me that we just cannot define classes with namespaces in the include plugin until support for PHP 7 has been dropped.

So we probably need to use an "old" name without a namespace. I would need to check how this could work with auto loading, I guess in the worst case we can also just put the class inside helper.php as we only need it there.

[Miro-Collas]

@michitux Thanks so much for tackling this!

[yaynstuff]

PHP 7 has been end of life since November 2022, I would not lose any sleep over it not working for PHP 7 - Yes I understand there might be some people out there still running PHP 7, but really, anyone running a version of PHP that's end of life and not receiving any security updates on a production system deserves to be prodded gently with a pretty featherduster.

Okay, reading the log from the start helps, it seems like PHP 7.4 doesn't like include in the namespace. This changed in PHP 8. Not sure how to solve this properly. It seems to me that we just cannot define classes with namespaces in the include plugin until support for PHP 7 has been dropped.

[Klap-in]

@yaynstuff please take care of your language.

[yaynstuff]

@yaynstuff please take care of your language.

Sorry? I did not use any profanities, what exactly is offensive?

[yaynstuff]

There we go, edited, hopefully now compatible with the highly "woke" world of 2023 :)

[michitux]

For your information, PHP 7.4 is supported by Red Hat as part of Red Hat Enteprise Linux 8 until May 2029. From a quick search, I found at least two web hosting providers in Germany that offer an extended support release of PHP 7.4 for a higher price.

DokuWiki officially still supports PHP 7.2 with the most recent stable release. As a widely used plugin, it would be strange to switch to a more recent PHP version than DokuWiki itself just to avoid deprecation warnings that have no impact on the functioning of the plugin. In the worst case, we wait until either resolve_id and resolve_pageid have actually been removed or DokuWiki doesn't support PHP 7 anymore in its stable release.

[yaynstuff]

It is officially end of life from the creators of PHP themselves...

Talk about beating a dead horse..

The majority of people hosting an opensource wiki would probably not choose RHEL as the distribution (unless its some corporation that really needs the vendor support from Redhat and doesn't mind paying all the license fees involved every year). With IBM basically ruining the CentOS project (IBM have a habit of ruining most things they get their hands on and most people know it), many are sick and tired of it and have moved away from the RHEL like distributions and over to debian or ubuntu server.

Basically what I am saying, is that apart from that RHEL corner case you outline, and some niche provider who wants to keep offering support for PHP 7 (for a pretty penny), the rest of the world has moved on. Those corner cases dont represent the majority of installations out there - I personally don't understand the need to have to please "everyone".. But whatever :)

There are some corporations still using Windows XP (despite that being long dead) and paying some astronomical amounts of money to Microsoft for extended support - all because someone in their organization lacked the foresight to plan for the future. The same argument can be made for people building software for windows to make sure it still runs on that platform, because there might still be some people out there still using it who have somehow got support for it. lol.

[Autumnf0x]

Question from a PhP-dilettante: Maybe a temporary solution could be to split the code into sections for different versions of PHP? Or... "temporary fork" for PHP 8.x/2023-04-04a "Jack Jackrum"?
A very useful plugin, only to lose it due to refactoring... (

[LouisOuellet]

For your information, PHP 7.4 is supported by Red Hat as part of Red Hat Enteprise Linux 8 until May 2029. From a quick search, I found at least two web hosting providers in Germany that offer an extended support release of PHP 7.4 for a higher price.

There is a difference between support as in "I will continue to make sure it runs on my OS/Servers" and support as in "I will provide support by providing security updates to the PHP 7.4 source code to extend its support".

[LouisOuellet]

There are some corporations still using Windows XP (despite that being long dead) and paying some astronomical amounts of money to Microsoft for extended support - all because someone in their organization lacked the foresight to plan for the future. The same argument can be made for people building software for windows to make sure it still runs on that platform, because there might still be some people out there still using it who have somehow got support for it. lol.

Don't confuse who forces someone to keep supporting deprecated software. It's rarely the IT department of the institutions. Most of the time its because they need to support a nich software that hasn't received any updates in so long and that nich software makes that super expensive hardware work. IT Departments would usually try and isolate those within their network.