PHP 8.2

[tr-electronic-edv]

Greetings to you PHP nerds!

As a sysadmin I failed to install the Monarc App via Docker and now struggle with the native install. One of the issues is the outdated PHP version.

Nowdays the PHP 8.2 is the minimum PHP version in the standard Ubuntu 24 and Debian 12 repositories.

PHP Update problems:

I've scanned the php files against the PHP 8.2 incompatibilities and found nothing, but
some compose.json dependencies are incompatible for sure:

Package	Version	Issue	Recommendation
laminas-mvc	3.1	Too old (2018-2019), predates PHP 8.0. May have deprecated features	Upgrade to 3.3+ or 3.5+
symfony/console	5.0	Released before PHP 8.0, deprecated notices in 8.2	Upgrade to 5.4 LTS or 6.x
robthree/twofactorauth	1.8	Partial compatibility, older package	Upgrade to 3.x (latest)

Recommended Changes:

{
    "name": "monarc/monarc",
    "description": "Monarc application",
    "license": "AGPL-3.0-or-later",
    "require": {
        "php": "^8.2",
        "ext-json": "*",
        "ext-pdo": "*",
        "ext-bcmath": "*",
        "ext-openssl": "*",
        "ext-imagick": "*",
        "ext-intl": "*",
        "monarc/frontoffice": "^2.13.1",
        "monarc/core": "^2.13.1",
        "laminas/laminas-mvc": "^3.5",
        "laminas/laminas-di": "^3.2",
        "laminas/laminas-permissions-rbac": "^3.0",
        "laminas/laminas-log": "^2.18",
        "laminas/laminas-i18n": "^2.21",
        "symfony/console": "^5.4",
        "laminas/laminas-dependency-plugin": "^2.2",
        "laminas/laminas-mvc-middleware": "^2.4",
        "robthree/twofactorauth": "^3.0",
        "endroid/qr-code": "^4.8",
        "laminas/laminas-captcha": "^2.18"
    },
    "config": {
        "bin-dir": "bin/",
        "platform": {
            "php": "8.2.0"
        },
        "allow-plugins": {
            "laminas/laminas-dependency-plugin": true
        }
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

Aside the dependencies upgrades, ext-imagick and ext-intl has been added as monarc/frontoffice use them but they are not declared in the current composer.json

Also the php and platform should be upgraded because the current

• "php": "^8.0" → Allows PHP 8.0, 8.1, 8.2, etc.
• "platform": {"php": "8.1.0"} → Composer will pretend to run on PHP 8.1.0 locally
  • This may mask actual PHP 8.2 compatibility issues during local testing

PHP upgrade plan:

1. Update php requirement from ^8.0 to ^8.2
2. Add missing extensions: ext-imagick and ext-intl
3. Update platform PHP from 8.1.0 to 8.2.0 for accurate local testing
4. Upgrade dependencies:
   • laminas-mvc: 3.1 → 3.5+
   • symfony/console: 5.0 → 5.4 (LTS)
   • robthree/twofactorauth: 1.8 → 3.0+
   • Other Laminas packages to latest in their major version
5. Run composer update and test thoroughly
6. Run project tests with PHP 8.2
7. Fix bugs in place (create sub-issues if major problems occur).

[ruslanbaidan]

The exact php version platform setting was removed from the config part of the composer json.
The release version was updated as well as the package artefact MonarcAppFO-v2.13.4.tar.gz.
It should not now limit you to use php version 8.2 on your server.
In any case we are planning the update in the future, but have to keep in mind that many of the Monarc installations are still relying on php v8.1, as Ubuntu 22.04 LTS is installed there.

[tr-electronic-edv]

Yes you're right, I forgot about the old Ubuntu. Sure the php8.1 compatibility should be kept.
Still, the dependencies upgrades are important to support PHP8.2 upwards.

I will try to install Monarc v2.13.4 on the clean Ubuntu 24 (default php8.3) and tell if any incompatibility appears.
On success I'll add ./INSTALL/INSTALL.ubuntu2404.md

[tr-electronic-edv]

As I see now, the production install use no Composer and no NPM which is great.
I assume those are used in development to compile the front-end.
I suggest to create a production Dockerfile without the Composer and NPM.
Existing Dockerfile could be renamed as Dockerfile.dev or something.

[ruslanbaidan]

As I see now, the production install use no Composer and no NPM which is great. I assume those are used in development to compile the front-end. I suggest to create a production Dockerfile without the Composer and NPM. Existing Dockerfile could be renamed as Dockerfile.dev or something.

Your points are reasonable and I will reference the issue to the infrastructure Dokerization ticket.