Migrating framework Config

Hey Andreas B. !

An exception has been thrown during the rendering of a template ("The "esi" renderer does not exist.").' - so I guess that this file sets the configuration only for the new App namespace, is that right?

Hmm, that is a strange error. First, to answer your question, no: this file sets config for the FrameworkBundle in general - it should activate ESI for your entire system, not just for the App namespace. Do you have framework.esi config anywhere else in your app? I want to make sure that you don't have ESI disabled on accident in the "dev" environment. Otherwise, this "should work" - but obviously... it's not. Let me know if you have any other framework.esi config. Or, a good way to check is to run bin/console debug:config framework to see what the final, resolved value of framework.esi.enabled is.

If so, it's not really a gently migration imho. Because we have an old application with multiple custom "bundles", we need to make sure that we adopt a two-pronged strategy. Also, we don't have any code freeze so we have to go one step after another for the migration.
My question is now: is there also another (more gentle) way to accomplish the migration? (Or did I do something wrong?)

This is a tricky migration, I'd admit. However, as I mentioned above, your assumption that the framework.yaml file affects only the App\ namespace is (thankfully) incorrect :). In our app, we kept our existing bundles during this transition. And then after it was complete, we started slowly moving things out of our bundles and into App. That's what we do in this tutorial - we don't remove the AppBundle stuff until the final step (after we have things working).

Cheers!

Hey weaverryan ,
at first I want to thank you for this really precise reply! I really appreciate your help!
Unfortunately, it seems that there're some really weird things going on.
Namely the following:

If I set
`
framework:

esi: 
    enabled: true

`
in the app/config/config.yml file:

• return value of "bin/console debug:config framework" is esi: enabled: false
• site IS working

If I set
`
framework:

esi: 
    enabled: true

`
in the config/packages/framework.yaml file:

• return value of "bin/console debug:config framework" is esi: enabled: true
• site is NOT working

But the output of the bin/console command might be misleading, because I don't know if migrated the bin/console file correctly. As shown in the tutorial, I replaced our file with the new one from the recipes repository (https://github.com/symfony/recipes/blob/master/symfony/console/4.4/bin/console) but it seems that the output is only based on the new Flex app. If I simply execute bin/console debug:config with the OLD bin/console file then all of our custom "bundles" are listed. But if I instead replace the bin/console file and then execute the debug:config command, our custom bundles are not listed, only the "external" bundles.
But either way, that shouldn't have any consequence of the real handling of the Flex app, right? Means: even if bin/console might not be correct, the framework.yaml file should work for both "apps". But maybe I did something wrong with the migration and the new config files of the Flex app aren't "really" registered?

I tried to add a new controller with indexAction + route /foobar in the routes.yaml file, and when I execute "bin/console debug:router" it outputs "index ANY ANY ANY /foobar" but when I try to access the route I get a 404 response.

Maybe it has something to do with the public/index.php? Do I have to merge both app.php and app_dev.php with this new file before I get the new flex app to work or am I missing something else? Do I have to do something else to "activate" the new framework.yaml and it's components?

Best regards,
Andy

Ok I think I got one step further! I included the new public/index.php within the app_dev.php (and commented all other lines within app_dev.php), then I added the constants and things from app_dev.php in config/bootstrap.php.
Now, the new route /foobar is accessible BUT all the old routes are not.

I guess now that I "activated" the new Flex environment, all old config files (within app/config) are not loaded any more, is that correct?

That means that all the old stuff won't work until I migrated the services etc. into the new environment?
Or is there another way I could keep the old configurations as well?

Hey Andreas B.!

Excellent debugging with the index.php file! That file should have been added for you around this step - https://symfonycasts.com/screencast/symfony4-upgrade/flex-composer.json#scaffold-the-full-structure - where you allow Flex to execute all the recipes for you. I'm not sure why that would have no happened in your case.

I guess now that I "activated" the new Flex environment, all old config files (within app/config) are not loaded any more, is that correct?

Yes, this is correct! But it's not nearly as bad as you think :). The new directory structure (it's not really Flex, Flex is just a new tool that installs recipes and works well with the new directory structure) loads service and package configuration from config/services.yaml and config/packages/* - you can see this right in the src/Kernel.php file. It does not load any other config files (unless you have a bundle with a "DependencyInjection" class that loads its own services file).

So let's look at each type of config:

A) services: suppose you have some other configuration files with service definitions, maybe in a bundle or somewhere else. I would simply go into the new config/services.yaml file and import the old file from there. That should handle it just fine, and you can migrate over time.

B) bundle config (e.g. services, twig, etc): you could also import these from services.yaml - that should also work fine. But in this tutorial, I chose to move those into their new locations in config/ (mostly splitting config.yml into multiple files). If you didn't do this, you might have some trouble with new files in config/packages/ (that were added by the recipes) overriding your config.

C) routing: if you have routing files somewhere else in your app, you can move them into config/routing/ or import the routing files from config/routes.yaml - your call.

Oh, and if you still have some bundles in your app, you can totally keep those. You'll just need to make sure that they are initialized correctly in the config/bundles.php file.

Let me know if that helps! You can absolutely get your app running with the new and old code. But it is a tricky "dance" to get everything in the right spot and loaded.

Cheers!