> Symfony 6 > Upgrading & What's New in Symfony 6!
Buy Access to Course
06.

Recipe Upgrades with recipes:update

|

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Let's keep upgrading recipes! There are a bunch of them to do, but most of these will be easy. We'll move quickly, but I'll highlight any important changes as we go.

symfony/console Recipe Update

For the next update, let's skip down to symfony/console since that's another important one.

composer recipes:update symfony/console

This updated just one file: bin/console. Check out the changes with:

git diff --cached bin/console

Hmm. It changed from being kind of long to... pretty darn short! This is, once again, the Symfony Runtime component in action. The code to boot up Symfony for the console has moved into symfony/runtime. And... this fixed our bin/console command, which had been broken since we upgraded the FrameworkBundle recipe.

Let's commit this change... and keep going:

composer recipes:update

symfony/twig-bundle Recipe

Skip down to symfony/twig-bundle. That's number 7. I'll clear the screen and... okay! We have conflicts. Exciting! I'll clear the changelog since I've already looked at it. Ok, this deleted an environment-specific config file... and then we have two conflicts. Let's go check out config/packages/twig.yaml.

Once again, we're seeing the new environment-specific config feature. This when@test stuff used to live in config/packages/test/twig.yaml, but it's now been moved here. And because I have a custom form_themes config, it conflicted. We want to keep both things.

8 lines | config/packages/twig.yaml
twig:
// ... line 2
form_themes: ['bootstrap_4_layout.html.twig']
when@test:
twig:
strict_variables: true

The second conflict is in templates/base.html.twig. Our base.html.twig is pretty customized, so we likely don't need to worry about any new changes. The recipe added a new favicon by default. You probably won't use this since you'll have your own. To fix this conflict, since my project doesn't have a favicon yet, I'll copy the new stuff, use our code, but paste the favicon.

95 lines | templates/base.html.twig
// ... lines 1 - 2
<head>
// ... line 4
<title>{% block title %}Welcome!{% endblock %}</title>
<link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 128 128%22><text y=%221.2em%22 font-size=%2296%22>⚫️</text></svg>">
// ... lines 7 - 14
</head>
// ... lines 16 - 95

Perfect! Now we can commit everything.

doctrine/doctrine-bundle Recipe Update

Let's keep going!

composer recipes:update

We'll work on the rest from top to bottom. Next is doctrine/doctrine-bundle. This is a cool update. Once again, I'll clear the screen and run:

git status

It conflicted inside the .env file... which is probably the least interesting change. Recently, DoctrineBundle's recipe started shipping with PostgreSQL as the default database. You can totally change that to be whatever you want, but PostgreSQL is such a good database engine that we started shipping with it as the default suggestion.

But I'm using MySQL in this project, so I'm going to keep that. But to be super cool, I'll at least take their new example config... which looks a little different... and update my comments on top with it. Then I'll use my version of the conflict. The end-result is a few tweaks to the comments, but nothing else.

30 lines | .env
// ... lines 1 - 24
# DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
# DATABASE_URL="mysql://db_user:db_password@127.0.0.1:3306/db_name?serverVersion=5.7&charset=utf8mb4"
# DATABASE_URL="postgresql://symfony:ChangeMe@127.0.0.1:5432/app?serverVersion=13&charset=utf8"
DATABASE_URL="mysql://root@127.0.0.1:3306/symfony6_upgrade?serverVersion=5.7"
// ... lines 29 - 30

The other changes from the recipe relate to the config files, and I bet you can see what's happening. It deleted two environment-specific config files and updated the main one. Hmm.

Open config/packages/doctrine.yaml. Sure enough, at the bottom, we see when@test and when@prod. That's nice! Everything is now in one file. Just make sure that if you had any custom config in the old deleted, files, that you move it over to this file.

43 lines | config/packages/doctrine.yaml
// ... lines 1 - 18
when@test:
doctrine:
dbal:
# "TEST_TOKEN" is typically set by ParaTest
dbname_suffix: '_test%env(default::TEST_TOKEN)%'
when@prod:
doctrine:
orm:
auto_generate_proxy_classes: false
// ... lines 29 - 43

One other change that's new is this dbname_suffix under when@test. This is cool. When you're running tests, this will automatically reuse the same database connection configuration, but with a different database name: your normal name followed by _test. And this fancy part on the end makes it really easy to run parallel tests with Paratest. This will ensure that each parallel process will use a different database name. You get that all, for free, thanks to the updated recipe.

There's one other change in this file, and it's important. In PHPStorm, I can see that the recipe update deleted the type: annotation line. Right now, we are still using annotations in our project for entity configuration. We're going to change that in a few minutes to use PHP 8 attributes, which is going to be amazing. But anyways, in the DoctrineBundle configuration, you no longer need this type: annotation line. If you don't have it, the correct format will be detected automatically. If Doctrine sees annotations, it'll load annotations! If it sees PHP 8 attributes, it will load those. So the best config is no config... which tells Doctrine to figure out things for us.

Once again, add all these changes, commit, and... let's keep going! Well, let's keep going in the next chapter, where we upgrade DoctrineExtensionsBundle, some debug recipes, routing, security and more!