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!

Dec 18 '21 12:12 mbrung

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

Jan 11 '22 17:01 axelusarov

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.

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

Idea

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

Jan 11 '22 19:01 alquerci

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

Jan 11 '22 19:01 j0k3r

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

Jan 12 '22 14:01 e1himself

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?

Jan 15 '22 23:01 mentalstring

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.

Jan 17 '22 19:01 thirsch

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 ?

Jan 17 '22 21:01 alquerci

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.

Jan 18 '22 14:01 mkopinsky

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?

Jan 18 '22 15:01 thirsch

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.

Jan 18 '22 19:01 mentalstring

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.

Jan 18 '22 23:01 mkopinsky

@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).

Jan 20 '22 09:01 e1himself

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.

Jan 21 '22 16:01 thirsch

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

Jan 22 '22 10:01 arendvw

Summary

test/bin/test php73 highest
- Failed 1/236 test scripts, 99.58% okay. 1/7477 subtests failed, 99.99% okay.
test/bin/test php74 highest
- Failed 1/236 test scripts, 99.58% okay. 1/7477 subtests failed, 99.99% okay.
test/bin/test php80 highest
- Failed 29/236 test scripts, 87.71% okay. 1435/6317 subtests failed, 77.28% okay.
test/bin/test php81 highest
- Failed 146/236 test scripts, 38.14% okay. 2587/4731 subtests failed, 45.32% okay.

Issues

The first pass, can be reproduced with #262 using command test/bin/test php80 highest.

PHP 7.3 and 7.4

RuntimeException: PHP sent a "warning" error. Trying to access array offset on value of type bool

PHP 8.0

ValueError: DOMDocument::loadHTML(): Argument 1 ($source) must not be empty
ArgumentCountError: Too few arguments to function lime_test::handle_error(), 4 passed and exactly 5 expected
TypeError: count(): Argument 1 ($value) must be of type Countable|array, Foo given
ArgumentCountError: Too few arguments to function lime_test::handle_error(), 4 passed and exactly 5 expected
TypeError: abs(): Argument 1 ($num) must be of type int|float, string given

Jan 22 '22 15:01 alquerci

What's news ?

symfony1

Good vibes for following PRs

#262
#263
#266

PHP version	Status
php80	:green_circle:
php81	:red_circle:

PHP 8.1 tests failed as doctine1 does not support yet.

doctrine1

Good vibes for following PRs

FriendsOfSymfony1/doctrine1#56
FriendsOfSymfony1/doctrine1#86
FriendsOfSymfony1/doctrine1#85 have a great potential

PHP version	Status
php80	:red_circle:
php81	:red_circle:

Thanks to @mentalstring, @teymour, @thirsch, @Tybaze, @xNatek

Jun 10 '22 23:06 alquerci

Great work in adding support for PHP 8.0 and 8.1 while keeping support all way to 5.3. 👍 And #262 really helped here.

I've been using #266 in a fairly busy website both with 7.4 and 8.0 and spotted no issues so far.

As there's no significant functionality changes and support from PHP 5.3 is kept, it could be the next release, v1.5.14, as there's no need not complicate the versioning. Either way, would be great to see these improvements merged in a near future.

Jul 06 '22 18:07 mentalstring

I've been using #266 in a fairly busy website both with 7.4 and 8.0 and spotted no issues so far.

After running it with 8.1 I found a few additional things, in particular that the new full_path introduced on PHP8.1 was breaking form validation.

I submitted a PR on https://github.com/Tybaze/symfony1/tree/compat_php8.1 to avoid a separate PR here with changes for PHP8.1 support. @Tybaze Could you take a look and merge when you can?

Otherwise, symfony1 seems to be running smoothly under PHP 8.1 with the changes.

Aug 15 '22 20:08 mentalstring

Should we close this issue as now PHP v8.2 is supported? @alquerci @thirsch @mentalstring

Jan 13 '23 13:01 thePanz

I agree. One day, it will be required to drop older php versions and hopefully at least one of us remembers this issue and the discussions we already had 😛 But for now, php 8.1 is supported and the primary topic of the issue is solved.

Jan 13 '23 15:01 thirsch

symfony1
symfony1 copied to clipboard