Recipe Upgrades with recipes:update
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeLet'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.
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
.
// ... 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.
// ... 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.
// ... 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!
I think there is something not working with my setup, I got only this change now
`
`