Composer, 3rd party libs and our stack

[fballiano]

Hi everybody, as some of you may know I'm trying to remove some 3rd party code from our repo, to keep it more tidy, organized and maybe going a bit more modern :-)

Today I was checking the Pelago_Emogrifier that we now have into /lib/Pelago and I found a problem which we'll have to address sooner or later, incompatibilities.

None of the composer versions of that library have a "requirer php versions" that's fully compatible with our v19 and v20 branches, the older versions are not supporting PHP8, the newer ones dropped support for PHP7.0.

I love the "old" monorepo approach that's always been used by M1 and I've never used composer in my M1 projects, but since the world (and openmage too) is going in the composer direction... what are we doing?

• We could upgrade our "required php version", since releasing new OM version on an insecure and unmaintained stack it's proably not a great idea.
• We could decide the OM 20 is composer only and do the cleanup only there
• Other ideas?

[Flyingmana]

we could still do the composer-only on a future version (OM 22 if its this year and we stay with mirroring the year)

what php versions are supported in what we currently have in our repository? If its both, maybe we just delay moving this one out till we drop the php7 support somewhen. (Iam a fan of the waiting approach where issues resolve itself and worktime is a limited factor)

[fballiano]

Pelago_Emogrifier 6.0 accepts "~7.3.0 || ~7.4.0 || ~8.0.0 || ~8.1.0"

[addison74]

Debian 10 that comes with PHP 7.3 has LTS until 2024. Anyone with older versions, for example Debian 9, can install whatever PHP versions they want from Sury. I know that many find it easier to benefit from operating system maintenance team updates than to compile source code or use 3rd party repositories. If this change is required in OpenMage I agree that the minimum should be raised to PHP 7.3.

[addison74]

Personally, I have no objection to the minimum requirements for running OpenMage being high compared to the current ones. As a system administrator I face two situations. I have servers where Debian 9 and 10 are installed and running PHP 7.0 and 7.3, which are supported by the maintenance team, but I also have servers where PHP > 7.3 and which I installed packages from the Sury repository.

The big challenge is that if OpenMage works flawlessly with the latest version of PHP we can't guarantee the same for extensions used in existing stores. In vain we make OpenMage perform so that without extensions it remains a simple Magento on steroids.

There is another issue that I have noticed over time. In OpenMage 20 very good features were put in place which in my opinion should be offered in OpenMage 19 as well.

[fballiano]

It is true, we've no idea if the extensions will work on new PHP stacks but I think that who manages a store with extensions that are uncompatible with new php version... than doesn't update neither the server nor the openmage version. I mean, it seems to me the only safe (well... as safe as having a EOL php version) way to keep everything running.

[addison74]

Our discussion is in a general way without facing a particular situation that we can analyze in detail. An experienced Magento 1 administrator if he wants to keep up with software updates he should be prepared for these changes. He should periodically conduct tests to prepare for changes in advance.

As an advice I recommend that those who use or will use the Sury repository block updates for programs other than PHP. Every time I added the repository after updating command a lot of programs appeared in the update list. So I blocked them so that they remain up to date from the source of the operating system.