Recent Changes - Search:
PITS /

01504: Raising Minimum PHP Version Requirement to 7.0

Summary: Raising Minimum PHP Version Requirement to 7.0
Created: 2024-05-02 04:32
Status: Confirmed, ToDo
Category: CoreCandidate
From: gnuzoo
Assigned:
Priority: 14
Version:
OS:

This is to discuss raising the minimum required PHP version for PmWiki. Currently, we support PHP 5.3 and above, but maintaining compatibility with such old versions is becoming increasingly difficult and time-consuming. Also, running old unsupported PHP versions is risky, as they no longer receive security updates.

Most users I know already run PHP 7.x or 8.x, and Pm's server runs PHP 7.0. I'm proposing we raise the minimum requirement to at least PHP 5.5 — or ideally PHP 7.0 — to simplify development, allow us to use more modern features, and reduce the amount of my unpaid work.

Please vote by adding your name below. The next PmWiki version 2.5.0 should be published in the next 2-4 weeks and should be compatible with PHP 5.5 or possibly 7.0, depending on the poll results. --Petko

Pm's message to the mailing list about supporting PHP 7.0 and newer.

Poll: Oldest PHP version you use to run PmWiki

See PHP Supported versions (currently 8.1 and more recent) and Unsupported branches (currently up to 8.0.30)

What is the oldest PHP version that you use to run PmWiki, on any of your wikis, and that you cannot upgrade to a more recent version?

Please add your name or signature in a numbered list item, and optionally explain why you cannot upgrade. You can include a short note with your name, or a longer explanation below in the section "Discussion".

All my wikis run a supported PHP version (currently PHP 8.1+), and that is regularly updated:

  1. Petko (my own wikis and my clients' wikis)
  2. Wlkl (running 8.3+)
  3. Jdd replied on the mailing list
  4. Piotr Dybczyński replied on the mailing list (Debian stable)
  5. simon
  6. Felix Pleșoianu (8.2 on Debian stable, choice of 8.1-8.4? on cPanel)
  7. NeilHerber all my sites run on 8.2
  8. (your name or signature)

I cannot upgrade past PHP 8.0 (EOL 26 Nov 2023)

  1. (your name or signature)

I cannot upgrade past PHP 7.4 (EOL 28 Nov 2022)

  1. Reiner (I have one Debian 11 system that is still on php 7.4.33)

I cannot upgrade past PHP 7.3 (EOL 6 Dec 2021)

  1. (your name or signature)

I cannot upgrade past PHP 7.2 (EOL 30 Nov 2020)

  1. Gb (running 7.2.34 ; upgrading would give headache because of outdated forum – but it's doable with time and aspirin)
  2. (your name or signature)

I cannot upgrade past PHP 7.1 (EOL 1 Dec 2019)

  1. (your name or signature)

I cannot upgrade past PHP 7.0 (EOL 10 Jan 2019)

  1. Petko (I cannot upgrade pmwiki.org myself, it is managed by Pm.)
  2. (your name or signature)

I cannot upgrade past PHP 5.6 (EOL 31 Dec 2018)

  1. (your name or signature)

I cannot upgrade past PHP 5.5 (EOL 21 Jul 2016)

  1. (your name or signature)

I cannot upgrade past PHP 5.4 (EOL 3 Sep 2015)

  1. (your name or signature)

I cannot upgrade past PHP 5.3 (EOL 14 Aug 2014)

  1. (your name or signature)

Discussion

Is it time to upgrade PHP requirements to at least PHP version 8.1?

PHP 8.0 has reached end of life and has abandoned all support.
From https://www.php.net/eol.php - "you are strongly urged to upgrade to a
current version, as using older versions may expose you to security vulnerabilities
and bugs that have been fixed in more recent versions of PHP."

I do not like the idea of other people having "security vulnerabilities" because PmWiki said it is OK to use old unsupported versions of PHP.
Another site said "Using PHP 5 Becomes Dangerous" - At least abandon PHP version 5. --gnuzoo

I have updated the PmWiki:Requirements page. We never said it was okay to use vulnerable PHP versions, this was about the technical prerequisites, as in, the core doesn't normally call PHP functions or implement patterns that were only added in more recent PHP versions. In some cases people cannot update their PHP version, in others they cannot update their old recipes that the new PHP versions inevitably break. They would appreciate being able to use the latest PmWiki features like PmTOC, PmSyntax, or the dark mode, for example on an internal/non-public webserver. --Petko

Perhaps you can freeze PmWiki PHP 5 development for 'security fixes only'.
PHP does this for older versions https://www.php.net/supported-versions.php
--gnuzoo

Revisiting this a year later, ready to bump to at least PHP 5.5. --Petko

I support reducing the number of PHP versions supported. https://www.php.net/supported-versions. Old PHP version often have security issues.PHP 8.1 was first released 25 Nov 2021 (PHP 8.0 is no longer supported).
I recommend the PmWiki only support PHP versions that are actively supported, or under security fixes support. I appreciate this may break some older recipes. (again which might have security issues).
Most hosting providers will offer supported version of PHP, and will retire unsupported versions.Upgrading PHP is, IMHO, pretty straightforward.

simon

At the moment this is what makes it complex to support PHP 5.3 -- using the old patterns makes the PHP 8.4 version slow, but PHP 7.0 should work in this case (although not for the international part of 01499). We should try a pragmatic approach - keep the compatibility as long as it is practical. We could also decide to support PHP versions for say 2 years after their EOL, which allows the users enough time to update, or to request assistance. Also, older PmWiki versions should be compatible with the then-supported PHP versions and people are not required to update PmWiki. --Petko

My sites run in a single shared hosting account where it is a pain (but possible)to have different versions of PHP in each domain. I have other apps running on some of those domains that require PHP 8.2, so that has become my default. The hosting service actually allows back to PHP 5.x, but managing a bunch of sites in one hosting account takes time I would rather spend on the site content. --NeilHerber