Loading...
 
Skip to main content

Features / Usability


Tiki 24 and PHP 8

posts: 25 Germany
End of live for PHP 7.4 is coming soon and I am running one of my Tiki instances for a small budget organization. The host operator charges extra support fees for outdated PHP versions. I want to stay with Tiki 24 because the name LTS promises longer term availability, and because Tiki 25 may not be available in time as a stable versiob. I may not be the only one in this situation. What is the best way to proceed?
posts: 126892 United Kingdom

Hi @bfw25

That's a very good question, but i'm afraid there's no easy answer - the fixes for php 8+ were pretty extensive and involved several dependencies having major upgrades (Smarty in particular) so it wouldn't be easy to back port those fixes to 24.x.

I suggest we discuss this at the new Roundtable Meeting or on gitter maybe?


posts: 1644 Canada

Executive summary: I would recommend to just pay the extra for PHP 7.4 support. And try to make sure you are getting what you are paying for (backported security patches). If they can't prove they are patching, ask for a refund.

  • Tiki24x will never officially support PHP8
  • Tiki25 is the first version with some support for PHP8, and it's not good yet.
  • I am hopeful Tiki26 will have good support for PHP 8.x


Tiki is hindered by a form of https://pluginproblems.com/.

Details:
We (Tiki) started working on PHP 8.x support in July 2020, a while before PHP 8.0 was released (2020-11). Some of the work:
2020-07: https://gitlab.com/tikiwiki/tiki/-/merge_requests/504

However, Tiki is a huge project: FLOSS Web Application with the most built-in features, and it re-uses a lot of code (which is a good thing). Ref.: https://doc.tiki.org/Composer

Unfortunately, a portion of the dependencies took more time to add PHP 8.x support, and it slowed down our whole process. If we know in advance that a component will falter, we can intervene (in some cases). But a struggling project will typically not announce this. And it would be a huge amount of work to track them all proactively. So, it's more a process of trial and error, report issues, wait, trial and error, etc. There is a similar situation when we go from Bootstrap 4 to 5. Not all the plugins may be ready in a timely fashion. This is why we concentrate all these types of changes in post-LTS versions (Tiki25, Tiki22, Tiki19, Tiki16, Tiki13, etc.). Full info at Lifecycle

More work:
2021-09: https://gitlab.com/tikiwiki/tiki/-/merge_requests/901
2022-01: https://gitlab.com/tikiwiki/tiki/-/merge_requests/1252

Because of its strategic importance to Tiki, we were specifically keeping an eye on Smarty: https://dev.tiki.org/Smarty-4

Sadly, the lead developer of Smarty had a stroke:
https://github.com/smarty-php/smarty/issues/553#issuecomment-544314004

It took a while for the community to re-organize. The lead dev is now Simon Wisselink:
https://github.com/smarty-php/smarty/graphs/contributors?from=2019-01-29&to=2022-10-21&type=c

And we made small contributions:
https://github.com/smarty-php/smarty/pull/743
https://github.com/smarty-php/smarty/pull/604

Similarly, we started work in 2021-12 for PHP 8.1 (released in 2021-11). Ex.:
https://gitlab.com/tikiwiki/tiki/-/merge_requests/1691

This should be easier, if PHP 8.0 support is complete (which wasn't the case). Work continues to get good support on PHP 8.x, and eventually, we'll drop support for PHP 7.4 and fully take advantage of PHP 8.x but putting a timeline on this is beyond our control.

In the meantime, Tiki24 and Tiki25 are fully supported on PHP 7.4, and while the end-of-life date for PHP 7.4 is November 28, 2022, we are not the only ones with this challenge. You wrote "I may not be the only one in this situation." Indeed, according to W3Techs, PHP 7 is used by 71.2% of all the websites who use PHP. PHP 8 is only at 5.6%, beaten by PHP5 at 23.1%
https://w3techs.com/technologies/details/pl-php

My company EvoluData will soon launch a Tiki hosting service (anyone interested, please contact me in private about the soft launch), and this is the type of challenge that we'll have to deal with (!) and one of the reasons why we didn't do it before.

Best regards,

Marc