PHP 8.1 support

[mbrung]

Dear project maintainers,

Thank you very much for all your hard work, it has helped me tremendously!

Has any work been carried out towards supporting PHP 8.1? I haven't looked in details yet at what it would entail, just raising the question (and avoid duplicate work).

Thanks again!

[axelusarov]

Same here. Would be great to know if there are any plans to fix PHP compatibility issues.

[alquerci]

Hello @mbrung, @axelusarov

As, I know, there are not any plans to fix PHP compatibility issues yet.

A short view on CI

Regarding the nightly build that run PHP 8.0.3-dev
There are a bunch of issues.
It seems that's not so easy.

Canvas

• This project will need to keep the BC to PHP 5.3, so it will be harder and harder to comply with this constraint.

Contributions

Personalty, I do not have any project running on sf1, and therefore I do not have time to work on it.
But, I am working on applications running on PHP 7, so it will be instructive to contribute to the support of this one.

I will be glade to help for code-review.

But, I do not know the availability of guys who are merging access. cc @thePanz, @j0k3r

@mbrung, @axelusarov do you wish to contribute?

A plan ?

But let's, it is not too late to start tackling one problem at a time.
The goal is to unscale the difficulty with tiny issue.

1. for each Backward Incompatible Changes, needs to search code occurrences
2. etc...

Idea

• Using issue or PR prefix [PHP 8.0] and [PHP 8.1].
  Example: [PHP 8.0] String to Number Comparison

[j0k3r]

I really think you need to invest time in upgrading your application to move away from symfony1 instead of upgrading your server.

[e1himself]

@mbrung is your app under active development or is it just a legacy project requiring maintenance?

[mentalstring]

From a quick look, it does seem to need some work to support PHP 8.x, while being particularly tricky to keep support for PHP 5.3 at the same time as the changes keep compounding. I think at some point, PHP itself will have BC breaks that will not allow this codebase to support all PHP versions.

This fork started as a way to add some neat enhancements to Symfony 1.4, while also adding support for more recent PHP versions. I think we can all agree that, these many years later, it doesn't make much sense to continue investing new features into it.

However, I think the support for more recent PHP versions is still relevant to some — some devs are are still working in (active development) projects built on top of this fork from which it is too hard to move away from now, but supporting more recent PHP versions is still important.

So, I wonder if it would make sense to drop the PHP 5.3 compatibility goal — perhaps on a separate branch? — and only making the code changes to support more recent PHP versions?

I think the number of websites out there still running this fork with PHP 5.3 is likely close to zero (and even those can already use the code as is today to improve things). At the same time, I think it's much more likely that there are still devs who are using it with more recent PHP versions and still need to keep up with that.

I can put some time in trying to add PHP 8.x support if others can help with that too. However, the overhead of also keeping PHP 5.3 support at the same time is likely to require much more time (from just a quick look) and personally I wouldn't have use for that support myself.

Anyone else interested in helping with the PHP 8.x support?

[thirsch]

We are using symfony1 in a legacy project as well and would also love to get support for 8.x. From our point of view, we could drop support for any version below 7.3, as they are not supported anymore (https://www.php.net/supported-versions.php) and as mentalstring already mentioned, there will be no or, if any, very minor new features coming to the updates and therefore anyone using sf1 with a php version between 5.3 and 7.3 is able to use older releases.

While we are already migrating to newer versions of symfony and/or other frameworks, there is quite a huge codebase running on sf1 and it will still take a few month if not years to fully drop sf1 from our stack.

As we already implemented some fixes for 8.0 and 8.1 in our branch, we can offer to help on the project.

[alquerci]

Trying to answer what PHP versions are still installed, sf1. I found that Packagist can contribute to answer to this question.

friendsofsymfony1/symfony1 statistics PHP Versions

This can give an idea because it is partial data.

Anyway, in any case, dropping support to old PHP version will require to bump the major version and maintain 2 minor version branches, that will be more time-consuming for mergers.

@thirsch said

anyone using sf1 with a php version between 5.3 and 7.3 is able to use older releases.

As @j0k3r said

I really think you need to invest time in upgrading your application to move away from symfony1 instead of upgrading your server.

In my honest opinion

Symfony 5 depends on PHP >=7.2.5
Symfony 6 depends on PHP >=8.0.2

If you want to migrate to Symfony 6, sf1 needs to supports at least PHP 8.0.

---

@mentalstring @thirsch If you still want to provide the supports, then the first step will be to start working on it by creating the beginning of the plan.

The goal is to discover the difficulty, we can even put the first iteration on a time-box. That way, we can fail fast.
Each week, we should readjust the plan regarding what we will learn.

The first iteration might be.

	time-box	Goal
Iteration 1	4 weekends	Make 90% tests pass for PHP 8.0

How do you want to proceed?

Following is just a draft about the plan, you are free to amend it.

• On what branch to work on, a feature branch on a fork or directly to master ?
  • I suggest to having a feature branch.
  • To speed up the dev, I can provide a local environment for testing with docker and docker-compose, I already have it, except for PHP 8.0 and PHP 8.1.
• Does the first steps, of the plan, are
  • Add pending PHP versions to allow_failures on travis.yml (8.0, 8.1, nightly)
  • For each failed test group, issues related to Backward Incompatible Changes
    • Fix the issue on a dedicated pull request
  • For each Backward Incompatible Changes that are not tackled, needs to search code occurrences
    • Add test to cover and fix the issue on a dedicated pull request
  • etc...

Each problem will have its own solution, it will be challenging. So I invite you both to submit pull requests, I will be happy to code-review.

As I said before, let's go step by step.

What do you think, feedbacks are welcomes ?

[mkopinsky]

I just want to chime in - my team maintains a large sf1 app with no viable migration path to sf2+. There are lots of non-sf1 parts of the codebase - anything not web-focused uses illuminate/queue or custom daemons (which do extend sfTask) but the web portions of the codebase do still use sf1. One of these days I want to convert the tasks and daemons from sfTask to symfony/console, and templates from PHP to twig, and introduce PSR4, and switch from doctrine1 to doctrine2 (this is probably the hardest piece of all). As a whole, though, moving from sf1 to sf2 just isn't feasible on any reasonable timescale.

As far as steps forward:

• Even if we do break BC by dropping older versions, I'm not sure that warrants a major version bump. Unless by version bump you mean 1.5 to 1.6. Having a 2.0 version of sf1 is just too confusing. This is 2022, composer.lock is a thing, I really expect/hope that people aren't blindly installing the latest fos1/symfony1: dev/master onto their PHP 5.3 servers without any checks. Let's face it, the people still running PHP 5 probably never update dependencies on anything - automatically bumping to a version incompatible with PHP 5 isn't a real worry.
• I think we should entirely ignore PHP 5.3-5.5. Packagist stats do show a meaningful amount of PHP 5.6 usage, but I think BC to 5.3 is unnecessary. I could also get behind @thirsch's suggestion of supporting 7.3+ if necessary - we don't need to arbitrarily drop support for <=7.2 just because php.net has done so, but if there are features of 7.3+ that we want or need, bumping is fine.
• I agree with @alquerci's plan of one PR per breaking change. I have no opinion on whether those PRs go into master vs a feature branch.

[thirsch]

Thanks for your feedback, @alquerci and @mkopinsky!

Just a short feedback from me:

• Version: I'd also go for 1.6 (1.5 can be used for any fixes in the old version and 2.0 would be too confusing, as @mkopinsky already said and composer can handle the version selection based on the local or configured php version)
• Branch: No real opinion here, we can also create a branch for version 1.5 and move master towards the next upcoming release.
• PRs per issue: Sure, that sounds good.
• PHP-Version: From what we see in the stats, it should be ok to go at least to 7.0 and 7.1. Maybe we just try to focus on any changes required for 8.x support and try to fix it without changing the minimum version. If it's too much effort to support the older version, we can fix the concrete lowest version? For 8.1 we will have to add the new attribute #[ReturnTypeWillChange] to some methods, but as the attribute is a comment below 8.x, it should be ok.
• Dev Environment: Having the same docker based env will ease things a lot, so maybe the first pr is to add the required docker files?

[mentalstring]

It's great to still see some activity and interest in this. I'm sure we are not the only ones still having to work on top of sf1 with the problem that moving away from this monolith is a hard thing to do for some projects.

I think in general the feedback so far is fairly aligned, so just sharing my thoughts:

• Seem consensual that dropping the PHP 5.3-5.5 support is acceptable. Above that, personally, I would go for 7.4 as the new minimum to support due to being the oldest PHP version that still receives security updates, but wouldn't mind keeping support for other 7.x versions if someone there's need/interest.

• I agree that bumping up the version to 2.0 would be a confusing move and may be overcomplicating things. IMHO, jumping to 1.6 and documenting the BC break would be enough.

• I have no preference regarding the PRs per issue idea, but, I don't know if making weekly iterations would work: speaking for myself, I can only work on it whenever time allows and that is rarely predictable/consistent. But having a roadmap sounds good.

• Without being sure where this effort will take us, I would work on this on a branch as to not run the risk of leaving master in an incomplete state where neither 5.3 nor 8.x is fully supported. Once support for 8.x is complete, it would be merged.

  • Optionally, a 1.5 branch could be created from master beforehand, if someone shows interest in having security updates for the PHP 5.x version. In the limit, that 1.5 branch decision could be deferred to whenever that is really needed/asked for which may actually never come.

• Depending on the branching decision, updating travis.yml for 8.0 and 8.1 and adding a PR with a docker env to facilitate the testing seem like good first steps. If afterwards the existing work to support PHP 8.x could be pushed too, it would enable us to have a better picture of the work still to be done and then plan how to go from there.

[mkopinsky]

I'm curious - if we would schedule a half-day hackathon to collaborate on this, how many of you would be interested/able to participate? Let's say we did it a weekday (Monday through Thursday) starting at 13:00 UTC (thus 8:00 US Eastern, 15:00 Eastern European Time). We could do this via Zoom, Slack, or the like.

If you're interested but that timing doesn't work out (e.g. prefer a weekend, prefer evening, are in a timezone that's not between US Eastern and Eastern European Time) let me know.

If this of interest, we could also coordinate logistics by email - back and forth discussions about scheduling don't need to live permanently in Github Issues. Hit me up at my github username at gmail if you wish.

[e1himself]

@mkopinsky

FWIW we at @prezly are maintaining a fork of sf1, which has been slowly moving forward (mainly by shaking off old functionality that, as we believe, is better to unload to specialized software. Like view-cache, for example, has been completely dropped in favour of offloading it to Varnish or a similar solution).

It's here https://github.com/rock-symphony/rock-symphony

We're at v10 (which means there were several BC breaks already).

[thirsch]

Thanks @e1himself, I've had a look at your project a couple of month ago. The biggest issue for us are your BC breaking changes. We are aiming for just running it with newer PHP versions but without substantial changes in the codebase. New applications have already been moved to a newer Symfony version or to a different framework or technology.

[arendvw]

In addition to the statistics: here the list when the support for php stops from the big lts vendors. (They will generally patch up vunerabilities in old php versions)

	Release	End of life	PHP Version
SUSE Enterprise server 12	2014-02-25	2024-10-31	7.0
SUSE Enterprise server 15	2017-10-18	2028-07-31	7.4; 8.0
Red Hat Enterprise Linux / CentOS 7	2014-06-10	2024-06-30	5.4
Red Hat Enterprise Linux / CentOS 8	2019-05-01	2029-05-01	7.2
Debian 10, Buster	2019-07-06	2022-08-01	7.3
Debian 11, Bullseye	2021-08-14	2023-08-14	7.4
Ubuntu 18.04, Bionic beaver	2018-04-01	2023-04-01	7.2
Ubuntu 20.04, Bionic beaver	2020-04-01	2025-04-01	7.4
Ubuntu 22.04, Bionic beaver	2022-04-01	2027-04-01	8.1