I do something in Notifier Component few weeks ago. I think I can migrate src/Symfony/Bundle/FrameworkBundle/Resources/config/notifier.xml

@szepczynski Great, can you do notifier_transports.xml as well? I've added you name on both :)

yes, i missed them on the list

One question about migrating FrameworkExtension - I guess that we need temporary two loaders, one for not migrated XMLs, and one for migrated until all configuration will be migrated.

Can someone add at first Php Loader to FrameworkExtension that everyone who starting from current master don't need create Php Loader?

I can start with http_client.xml and http_client_debug.xml first 😅

@szepczynski Can you create the PHP loader in a separate PR that I can merge fast?
@IonBazan added, thanks

@fabpot ok

For third-party bundles, we should do the same

For third-party bundles, I think it is too early to start this migration. The migration relies on using the new PHP DSL to configure services (migrating to the lower-level PHP API would not make sense as that would make maintenance harder). And this DSL is incomplete in previous versions of Symfony.
As we expect third-party bundles to keep support for our LTS release in a maintained version (otherwise, the LTS becomes useless, if it forces to use unmaintained versions of these bundles), they will either have to maintain 2 versions in parallel (high cost with low benefit as the XML config files will keep working) or delay the migration until the time they can go on supporting Symfony 5.2+ (so near the time 5.4 becomes the active LTS and 6.0 gets released).
The good news is that there is no actual BC impact for bundles to do the migration (they can do it in any minor version). And dropping ext-xml from project requirements will be possible only when all packages are migrated and nothing else needs it (dom-crawler needs it for instance)

I want to help. Can I try to migrate [serializer] or something else?

Let me help. I can start from
src/Symfony/Bundle/FrameworkBundle/Resources/config/cache*.xml

@mamontovdmitriy serializer is yours
@iamvar cache*.xml files are yours
Thank you!

I want to give it a hand. Can I start with
src/Symfony/Bundle/FrameworkBundle/Resources/config/routing/errors.xml

@phamuyentri Sure, can you do routing*.xml?

Hi,
I can do annotations.xml to help :)

@magnetik Thank you, it's yours now.

Hi, I'd like to help with lock component.

I can help with src/Symfony/Bundle/FrameworkBundle/Resources/config/form*.xml
My understanding is they are 3 files, correct me if I'm wrong:

• src/Symfony/Bundle/FrameworkBundle/Resources/config/form.xml
• src/Symfony/Bundle/FrameworkBundle/Resources/config/form_csrf.xml
• src/Symfony/Bundle/FrameworkBundle/Resources/config/form_debug.xml

@misekai Great! Thank you.

@tomasjav Lock is yours, thank you

I can help with Bundle/FrameworkBundle/Resources/config/request.xml

@fabpot I can help with src/Symfony/Bundle/FrameworkBundle/Resources/config/console.xml

@dangkhoagms Thank you
@AhmedRaafat14 Thank you

Hi @fabpot, I think I can help src/Symfony/Bundle/FrameworkBundle/Resources/config/assets.xml

@fabpot I'd like to help with

• src/Symfony/Bundle/DebugBundle/Resources/config/services.xml and
• src/Symfony/Bundle/WebProfilerBundle/Resources/config/*.xml

@wouterj
I was not really emphasizing only file structure. Don't take this in wrong way but we have started thinking that symfony has started loosing its flexibility.

i just want to say that updating symfony is really hard job.

I don't think you should have that feeling :). I think from a base, Symfony is just as flexible as in the past. However, I agree that one thing changed: The experience when using the default is now much much better by the introduction of Symfony Flex. This hasn't made the other formats worse though, they are still at the same level as when Symfony 2.0 was released.

And to be honest, I think that makes sense. Symfony allows you to get to your destination. When using the paved road, you have a smooth experience to the destination. You can also use the unpaved road, you still get to the destination but the experience is not so smooth. In Symfony 2.0, there was no paved road, in Symfony 4.0+ there is a paved road.

Anyway, yes it was a hard upgrade from the unpaved to the paved road in Symfony 4.0. I think the core team also realizes this. See e.g. this tweet from Fabien (responding to some people that expressed the same feelings as you): https://twitter.com/fabpot/status/1270981253962043392 "4.0 -> 5.2 is really about new features and refinements but no big changes. I don't envision any revolution in the next few versions either."

In any case, this is completely off-topic for this issue, as this issue is purely internal.

@adsazad i just want to say that updating symfony is really hard job.

I feel you. I recommend you hire an external upgrade consultant to upgrade it. Doing it manually is hell... and non-sense in 2020. I do around 1 project upgrade a month on average, usually Symfony 3 to 5. With right tools like @rectorphp, coding standard and @phpstan it's piece of cake

this month i did 6 upgrades. i have even developed my own tool for upgrading them.

I just wanted to highlight:

You can also use the unpaved road, you still get to the destination but the experience is not so smooth. In Symfony 2.0, there was no paved road, in Symfony 4.0+ there is a paved road.

I disagree, I used to bend Symfony in all most terrible ways I could think of (starting at 2.8) and it was fine, until 3.4. 3.4 did some great optimizations, and very nice end-user improvements, but it broke some of the natural flexibility it had before. I think it's the natural cost of specialisation and optimisation, nobody can't get around, not even Symfony.

Don't take it wrong, it's not a complaint, I love Symfony and continue gladly to use it, yet in my experience, trying to walk out the paved road since 3.4 may be very difficult, at least compared to how it was very easy and nice before. Especially with debug component, which is really invasive, and a few other performance optimisations that made the code much harder to read, and broke some undocumented edge cases.

FWIW (and sorry for the OT) I agree with the sentiment that the "paved road" comes with a cost. Increasing the magic while keeping the flexibility leads naturally to greater code complexity. This is also often the case for speed optimizations. The end result is a framework which makes a lot of tedious operations quick and easy, but is harder to grasp when you want to tweak/change bits of it.
Maybe it's just me getting old and taking time to learn all the novelties (aka grumpy), but I am a great fan of code which is easy to read and fits in my head.

Here, it's all about internal changes, it does not change anything for developers.

@fabpot Looks like this issue has caused some confusion and some people thought it affects all configuration files.

Also see here: https://www.reddit.com/r/PHP/comments/h93fjc/symfony_will_now_promote_php_over_yaml_and_xml/.

Be warned that semantic configuration will stay in YAML for now (as using PHP is much harder there).

@fabian Can you be more specific? Which parts of configuration will stay in YAML?

I think he's referring to semantic config (the one you parametrize through Configuration class and its ArrayNodse, prototypes, and so on)

@Taluu As in bundles will still be configured in YAML?

@enumag You can cofigure these in php you just have to load them yourself.

// src/Kernel.php
class Kernel extends BaseKernel
{
    use MicroKernelTrait;

    protected function prepareContainer(ContainerBuilder $container)
    {
        parent::prepareContainer($container);

        (require dirname(__DIR__) . '/config/packages/workflow.php')($container);
    }
}

// config/packages/workflow.php
return static function (ContainerBuilder $container) {
    $container->loadFromExtension(
        'framework',
        [
            'workflows' => [
                ChangeEmailWorkflow::NAME => [
                    "type" => "state_machine",
                    "marking_store" => [
                        "type" => "method",
                        "property" => "state",
                    ],
                    "supports" => [Token::class],
                    "initial_marking" => ChangeEmailWorkflow::STATE_PENDING,
                    "places" => [
                        ChangeEmailWorkflow::STATE_PENDING,
                        ChangeEmailWorkflow::STATE_APPROVED,
                        ChangeEmailWorkflow::STATE_VERIFIED,
                    ],
                    "transitions" => [
                        ChangeEmailWorkflow::TRANSITION_APPROVE => [
                            "from" => ChangeEmailWorkflow::STATE_PENDING,
                            "to" => ChangeEmailWorkflow::STATE_APPROVED,
                        ],
                        ChangeEmailWorkflow::TRANSITION_VERIFY => [
                            "from" => ChangeEmailWorkflow::STATE_APPROVED,
                            "to" => ChangeEmailWorkflow::STATE_VERIFIED,
                        ],
                    ],
                ],
            ],
        ]
    );
};