search

FriendsOfSymfony1 / symfony1

[DEPRECATED -- Use Symfony instead] Fork of symfony 1.4 with DIC, form enhancements, latest Swiftmailer, better performance, composer compatible and PHP 8 support
https://symfony.com/legacy
MIT License
337 stars 175 forks source link

FriendsOfSymfony1 organization what next? #201

Open alquerci opened 5 years ago

alquerci commented 5 years ago

Hello folks,

At the end of the discussion of the issue #102 symfony1 and doctrine1 has been moved to the organization.

Now the organization have to grow in order to be useful for the community.

Questions

Was there a decision made about who has commit access?

I was tagged in #200 with a request to review, and I'm happy to do so, but I do not have commit access.

Originally posted by @mkopinsky in https://github.com/FriendsOfSymfony1/symfony1/issues/102#issuecomment-434133137

@mkopinsky We may use the same policy as the Symfony Core Team.

In any cases the code review can be done by everyone and this can help a lot the mergers.

@fabpot Do you have any recommendations?

Originally posted by @alquerci in https://github.com/FriendsOfSymfony1/symfony1/issues/102#issuecomment-434212867

I suggest this to-do list.

I suggest its rules

Anyway, rules or other things are open for discussion.

cc @thePanz

Summary of comments

:warning: Following elements are not a consensus but just a formatting. I do my best in order to be the more objective as possible, I am just a human who can make mistakes.

The "HOW" is less important than the mission or goals which may changed.

The mission of FriendsOfSymfony1 organization

Provide trust until the obsolescence of the symfony1 ecosystem libraries, where libraries are no more used.

Maintainers of symfony1 ecosystem libraries are not alone.

Goals

e1himself commented 4 years ago

In regards to existence of the FOS1 organisation, I believe the most important is to define the mission and the goals.

Naming a few that come into my mind:

Once the goals are set, only then it makes sense to talk about the rest.

alquerci commented 4 years ago

Hello there,

For your information we have a dedicated Slack channel on symfony-devs. Check-out the Slack on https://symfony.com/community

The name of the channel is friendsofsymfony1.

Anyone are welcome to join the channel.

alquerci commented 4 years ago

We must keep in mind that this framework is deprecated.

This include doctrine1 and all sf*Plugin.

IMHO we should focus on following goals:

e1himself commented 4 years ago

Good stuff :+1:

  • Provide the most easier migration path to the latest Symfony version.
    • Write a migration path documentation.

However, I don't think it is feasible to move the fork closer to Symfony 2+ and keep backwards compatibility at the same time.

I have a similar goal in mind by slowly moving forward another fork of this fork: https://github.com/rock-symphony/rock-symphony Not aiming for the latest Symfony though, but just to build on top of PSR-based components.

Just to say, the fork is at version 5.x already (meaning it had 4 BC breaking releases already). That's why I have a solid confidence that it's not realistic to have full BC and move it closer to the latest Symfony.

alquerci commented 4 years ago

@e1himself

However, I don't think it is feasible to move the fork closer to Symfony 2+ and keep backwards compatibility at the same time.

The goal will not to add all features of Symfony2+ but just provide a migration path documentation and maybe on another repository a bunch of classes that will help to:

The most important is to help to follow best practices as remove all business logic on controllers and templates and move it to Symfony2+ DIC. That has already been done in one of my projects.

Regarding Symfony naming it will be named bridge.

e1himself commented 4 years ago

I'm not sure how many people really want to spend time on their sf1 projects and upgrade/migrate those projects to a new Symfony version. Most probably people are just looking for security patches and new PHP versions compatibility to keep their legacy running.

Is there a way to survey people?

alquerci commented 4 years ago

Most probably people are just looking for security patches and new PHP versions compatibility to keep their legacy running.

Maybe but a deprecated framework can not have an infinite maintenance period, this is not realistic.

Think that Symfony2 have currently no bug fixes and security patches period ends this year.

The most important thing that make legacy projects stuck on sf1 is that the migration cost is currently too high.

thirsch commented 3 years ago

Well, I think compatibility with recent php versions might be the number one goal of everyone who is looking into this repo. It's not so much to get any new features here.

As already said, bigger legacy projects will probably never migrate to a modern Symfony, because of the migration cost. I can only speak for what we try to do: As it has become common to not build monolitic monsters anymore, we try to build small microservices to solve different tasks and on that way, we are trying to remove piece by piece from our big sf1 project.

Any news on maintainers? There are a few good prs waiting to be merged.

alquerci commented 3 years ago

:information_source: I had just add "Summary of comments" section to the description of this issue.

Any feedbacks are welcome.

connorhu commented 6 months ago

I found it last year and thought about what @thirsch wrote and it discouraged me a bit from doing anything forward thinking here. I'm sure many people are looking for this rep to just get support for new php versions and nothing more.

While I was porting the test system to PHPUnit I had a strong feeling that it's not that far away from each other, you can get to the point where you can have symfony7 components running in the background (e.g.: util folder some classes, finder, yaml parser, event dispatcher etc).

Then I realised that I do have a goal to not only keep alive the code of my two clients, but to eventually get the codebase to modern basics. Those codes aren't monolithic monsters, they're a predictable codebase, but the client doesn't want to invest the money to rewrite from scratch. If my work is not affordable in a closed source environment, I'd be happy to do something that benefits the community.

With symfony7's component approach I feel that it is possible to move the codebase forward, even keeping the no-breaking-change promise (1.5.x only php version tracking, 1.6.x major improvements).

With current analyzer tools, with symfony7's deprecation gathering approach, there are many tools that could be put in the hands of developers that would not leave them alone in tracking changes. Since I have two, not very large systems based on symfony1, I can test them on working systems all the time.

If drupal can benefit from symfony components I think we can too.

Would it really be nice to know who is using this code base and what their purpose is?

WDYT?™

ingcarlosperez commented 6 months ago

Hi @connorhu , I've been working with Sf1 for about 13 years and have a huge project with this framework. I encountered the same problem when transitioning to the Sf2 version. With a lot of code, I didn't have time to migrate my base code to the new version.

Hopefully, the FriendsOfSymfony1 community will come to the rescue with this fork. Currently, I haven't finished testing this version, but the results are OK for me at the moment.

In this scenario, I had the same question you have. My approach was to reorganize my ProjectConfiguration.class.php to include a new autoload.php for requiring new PHP components in my code.

I've been testing new libraries to replace some functions in my code (email, PDF generation, etc.), and at the moment everything looks good.

At the end of the day, I want to maintain the Sf1 route system, the generators (admin and modules), and the configuration approach. I expect to replace other tools with modern components.

If you'd like to see some of these changes, please let me know.

alquerci commented 6 months ago

With a lot of code, I didn't have time to migrate my base code to the new version.

5 years ago, I had a dream.

./symfony project:migrate-to-version-4

Today, this dream still exists.

Does someone share the same dream?

sbrowett commented 6 months ago

Same guys, and glad I'm not the only person on earth still stuck in this pleasant but ageing hole! Too big to migrate, still works great, but getting left behind! Where's the magic wand when we need it?!

On Mon, 8 Jan 2024 at 19:13, Alexandre Quercia @.***> wrote:

With a lot of code, I didn't have time to migrate my base code to the new version.

5 years ago, I had a dream.

./symfony project:migrate-to-version-4

Today, this dream still exists.

Does someone share the same dream?

— Reply to this email directly, view it on GitHub https://github.com/FriendsOfSymfony1/symfony1/issues/201#issuecomment-1881675158, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBTEID77NEYM2I5X3VGKTYNRAL5AVCNFSM4GC6TBIKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYGE3DONJRGU4A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

Regards,

Steve Browett @.*** 07985 417870

e1himself commented 6 months ago 
./symfony project:migrate-to-version-4

Does someone share the same dream?

Nope.

Not realistic, even for a dream, IMO :)

alquerci commented 6 months ago

Who has able to predict in 2018 that sf1 and doctrine1 be compatible with PHP 8.3?

We made it!

Let's target Mars, at least we can reach the Moon.

Now we can think about things a bit more interesting, like @connorhu said:

benefit from symfony components

Behind that thinking, sf1 may become a bridge to Symfony components like Laravel. Later, the bridge can be dropped.

e1himself commented 6 months ago

not the only person on earth still stuck in this pleasant but ageing hole

Just to share:

We are still successfully running our project (being under active development of new features all these years) on a symfony1 fork (with some amount of incremental updates, including PHP 8.3 support), plus several new components added at the application level: SQS command bus integration, Laravel-inspired service container, new authentication layer and request data validators.

Though the app has evolved over the years into becoming a REST API backend mostly, with almost no responsibilities over rendering any HTML templates or forms -- it's all React in the frontend. So we only use the (stock) HTTP kernel and middleware logic (aka filters), with homebrew request validators, and our own service container. Keeping the app binding to the framework as minimal as possible, with the hope to replace the HTTP kernel with a PSR-based standalone (non-framework) library some day in the future.

Ah, and Propel. But there's no visible path to replace it with anything else at any time in the future :)

e1himself commented 6 months ago

Who has able to predict in 2018 that sf1 and doctrine1 be compatible with PHP 8.3?

Or better to mention January 2010 (14 years ago! :scream_cat:) -- the official EOL date of the symfony1 framework :)

mentalstring commented 5 months ago

Like some of you here, I have an active, large-ish project built on top of symfony1 that is too hard to rewrite from scratch on something else. Hence, I'm happy that FOS1 exists and has been helping support new PHP versions, and even the composer support has been quite helpful (thank you all 💙). Meanwhile, I've been trying to use Symfony components wherever I can to avoid building more on top of the legacy code, but things like routing, authentication and orm (anyone else still on propel1?) are hard to move away from.

At the very least, I would like that FOS1 continues to add support to newer PHP versions, and I'll try to help where I can. I'm in favor of progressively dropping support for the oldest PHP versions: keeping that support is only getting harder over time as newer versions of PHP come up, and, at some point, it may not even be possible to keep the support all the way back to PHP 5.x without having BC changes anyway. Personally, I'm only interested in 8.x+ these days, but I reckon that that is a big jump and wouldn't push for that right away; perhaps 7.x would be a good place to move to first.

As for bigger changes, nobody is starting a new project with symfony1... but, for those stuck with hard to rewrite projects built on symfony1, I think there can be room for some improvements a little beyond supporting newer PHP versions (and security updates). Here I don't mean building any new core features, but primarily modernizing the code and keeping up with the PHP ecosystem, for example, transitioning from Swiftmailer to symfony/mailer, updating the coding style, moving to PHPUnit tests, etc. — some of those are already under way and some may require minor BC breaks, but they can be documented on the UPGRADE file.

As for anything more ambitious, I don't know if there's a realistic path from symfony1 to anything on Symfony2+ end of things. As most of us are painfully aware, despite its name, Symfony2+ is a whole different thing, and it's a moving target, which doesn't help. Another challenge, I think, is that with symfony1 being quite a monolith, replacing parts of it will necessarily introduce some significant BC breaks before getting there... Hence, I'm not sure if a project:migrate-to-version-4 concept might be feasible, especially for large projects.

That said, if I were to dream high here (it's free, right?), I think one possible direction could be to make changes towards making the framework progressively less decoupled, for example, by implementing some of PHP PSR's, with the goal that at least some parts of the framework could be more easily replaced by, e.g., Symfony components (or anything else that follows the standard). In other words, I would like to see a path away from the symfony1 monolith, perhaps directionally towards being able to use Symfony components in it, but not necessarily to Symfony2+ (the framework). The main idea being to chip away at the monolith to make it smaller over time, and as more and more parts would be decoupled and/or replaceable, perhaps at some point the monolith could be small enough to realistically be replaced by something else by those of us currently stuck with large projects built on top of it.

alquerci commented 5 months ago

Good points @mentalstring

And now, the question of one billion.

To focus on what is used in practice.

How are yours projects attached to symfony1?

make it smaller over time

connorhu commented 5 months ago

I would like to share some of my previous experiences and thoughts with you.

I used to do a project I started in symfony2 with 3 separate applications, never having actually worked with symfony1 and not knowing that there were multiple application architects by design. After a while I had to admit that it could be merged because symfony was actually going towards one application architecture. Because of this I think that symfony1 is actually multiple SymfonyCurrent Applications. Each Application in the app library can actually be interpreted as a separate Symfony.

Another SymfonyCurrent experience is that I started to port a custom php codebase, a rather poorly designed system, to symfony. The project owner requested that all changes should be small and that the result should be visible immediately (instant success experience, no giga changes to be lost). After three steps I had a fully functional integrated symfony:

There are parts that can't be converted to SymfonyCurrent with a command (View layer, sfConfig full static interface), but you can dump a lot of stuff from Symfony1 and convert it to SymfonyCurrent components. I also don't think you can get this migration down to the level of a single command.

Key moments:

What do I see when I look at the source code of symfony1?

Still, there is room for modernization here (even if not everything can be changed). Currently I see a distant goal of running a legacy symfony in a HttpKernel that Apps (backend, frontend etc) communicate with wrappers.

Along the wishes of @mentalstring we can start

By now, though, symfony has become very powerful in attributes. A completely parentless class can also be a controller, service and DI/autowire can handle it: https://symfony.com/doc/current/reference/attributes.html#dependency-injection

Branches:

What should I do next? I would make a 1.6.x branch and drop the <8.2 support. I would solve the 872 phpstan error (level 9) and make all classes have unit tests. Then I would look for a low level component and replace it with symfony/* coponent.

alquerci commented 5 months ago

That's very interesting.

But what will be the final state?

running a legacy symfony in a HttpKernel that Apps (backend, frontend etc) communicate with wrappers.

There are 2 distinct targets

1. SymfonyCurrent behind Symfony1

sf1 app is in front of SymfonyCurrent. Where sf1 app boot and handle requests.

image

2. Symfony1 behind SymfonyCurrent

SymfonyCurrent is in front of sf1 app. Where the HttpKernel boot and handle requests.

image

What target to choose?

My opinion is to choose the second one.

Having Symfony1 behind SymfonyCurrent.

The source code of symfony1 is dead, but the source code of the application running in production are alive.

I see the source code of live applications:

Example from test/functionnal/fixtures/ directory.

apps
├── frontend
│   ├── config
│   │   ├── dirmyconfig
│   │   ├── app.yml
│   │   ├── factories.yml
│   │   ├── routing.yml
│   │   └── frontendConfiguration.class.php
│   ├── lib 
│   ├── modules
│   │   ├── assetInclusion
│   │   │   ├── actions
│   │   │   │   └── actions.class.php
│   │   │   ├── config
│   │   │   │   └── view.yml
│   │   │   ├── data
│   │   │   └── templates
│   └── templates
└── backend
    ├── config
    ├── i18n
    ├── lib 
    ├── modules
    │   ├── someModule
    │   │   ├── actions
    │   │   ├── i18n
    │   │   ├── lib 
    │   │   └── templates
    │   └── sfI18NPlugin
    │       └── i18n                                                                                                                                                                          
    └── templates
config
├── dirmyconfig
├── databases.yml
├── filters.yml
├── properties.ini
└── ProjectConfiguration.class.php
lib
└── form
plugins
├── sfAutoloadPlugin
├── sfConfigPlugin
└── sfI18NPlugin

What is the smallest thing to do, to validate or invalidate that the goal is reachable?

There are 2 distinct endpoints to tackle.

What can we do in 6 months, duration of SymfonyCurreny version?

alquerci commented 4 months ago

Ho, a wrapper of sf1 into Symfony2 until 4 already exists.

https://blog.theodo.com/2015/01/wrap-up-your-legacy-application-with-symfony/

The bundle: https://github.com/theodo/TheodoEvolutionLegacyWrapperBundle/tree/master