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 SubscribeWe're right in the middle of upgrading the FrameworkBundle recipe.
It apparently added a new line to our .gitignore
file: some config/secrets/prod/prod.decrypt.private.php
file.
We don't have that file yet. What is it? Oh, I can't wait to talk about it! It's part of Symfony's new secrets management system. OooOOooo. For now, say yes: we will want to ignore this file later when we create it.
The next change is inside cache.yaml
. It... yea... just updated some comments. We don't need that, but it's nice: type "y" to add them. Oh, and the next change is also from cache.yaml
- further down. It looks like they changed the example config... but we've already customized this. So, we do not want this. Enter "n" to not add it.
Next up is framework.yaml
. Interesting, two changes here: it removed the default_locale
and added two new cookie settings. I won't make you dig through the commit history to find the explanation behind these. default_locale
was removed from here because it is also defined in translation.yaml
... and someone realized it was pointless and a bit confusing to have it in both places.
The cookie settings are a bit more interesting: they activate two security-related features. The first is cookie_secure
. The auto
setting means that if a visitor comes to your site via HTTPS, then it will create an HTTPS-only cookie. It's a no brainer and you should exclusively be using HTTPs on your production site anyway.
The cookie_samesite
option activates a feature on your cookies called... well... "samesite". It's a relatively new security-related feature that's quickly been adopted by most browsers. We talk more about it inside our API Platform Security tutorial - but this setting shouldn't cause problems in most setups and is definitely more secure.
So let's say "y" for all of these changes.
Keep going! Now we're inside services.yaml
! Hmm... it looks like it's just removing a bunch of stuff! That's because we've customized most of this file. If you look closely, there is one change: the recipe apparently removed the public:
false line along with the comments describing it.
Why? Because since Symfony 4.0, public: false
is the default value. We actually never needed this config! It was included originally... mostly for historical reasons.
So we do want this change... but... we can't say "yes" to this because it would kill all our code. Enter "q" to get out of the git add -p
system. We'll need to make this change manually. First, undo all of the changes by running:
get checkout config/services.yaml
Move back and look at the file in our editor... the custom code is back! Now manually take out the public: false
line and the comments below it:
... lines 1 - 12 | |
services: | |
# default configuration for services in *this* file | |
_defaults: | |
... lines 16 - 17 | |
public: false # Allows optimizing the container by removing unused services; this also means | |
# fetching services directly from the container via $container->get() won't work. | |
# The best practice is to be explicit about your dependencies anyway. | |
... lines 21 - 54 |
Let's continue the process. Start again with:
git add -p
It's going to ask us about a few changes we've already said no to - say no again. And this time, for the services.yaml
change, enter "y" to add it.
The next change is inside public/index.php
. Hey! It's that namespace change from Debug
to ErrorHandler
. We know that's a good change. If we did skip this, we would see a deprecation warning telling us to make that change. So upgrading the recipes is... actually saving us time later!
Finally, we get to the most important file of the recipe: src/Kernel.php
. This is another file that you probably haven't added custom changes to. And so, it's probably safe to accept all these updates. But let's look carefully and I'll highlight the reason behind a few changes. It looks like a lot, but it's all minor.
For example, PHP 7.1 allows you to have private constants. The recipe update uses that. No big deal. The getCacheDir()
and getLogDir()
methods aren't needed anymore because they're implemented by the parent class with the same logic. Removing them is a nice cleanup.
And registerBundles()
now has an iterable
return type.
I'll clear my screen then answer "y" to add these changes.
Next, it added a getProjectDir()
method. This used to not be needed, because Symfony determined it automatically by searching for your composer.json
file. But since they didn't work correctly in some edge-cases, it's added directly in our class now. Probably not a super important thing for us, but we'll accept this change.
Next, configureContainer()
has a void
return type and some parameters got tweaked. The autowiring.strict_mode
parameter was removed because it was something that made Symfony 3 behave like Symfony 4 does by default. It's not needed anymore... and never was. Clean up!
Then, inline_factories
is a performance thing - cool - and there's a slight tweak to how the config files are loaded to make life faster in the development environment: it no longer looks recursively for files inside the environment config directories - like config/packages/dev
.
At the bottom, configureRoutes()
has a void
return type and a similar recursive tweak. Say "y" to add all of this.
And... we're done! This is symfony.lock
: definitely accept these changes.
Let's check out how things look:
git status
Oh! The recipe added a new file: config/routes/dev/framework.yaml
. Interesting. Let's go open that: config/routes/dev/framework.yaml
:
_errors: | |
resource: '@FrameworkBundle/Resources/config/routing/errors.xml' | |
prefix: /_error |
You may or may not know, but Symfony has a feature that allows you to test what your production error pages look like. Just go to /_error/404
to see the 404 page or /_error/500
to see the 500 error page... though... ha, that, uh, never happens on production.
This file loads an errors.xml
file that adds this route in the dev
environment only.
Previously, if you open the twig.yaml
file in the same directory, this feature came from TwigBundle:
_errors: | |
resource: '@TwigBundle/Resources/config/routing/errors.xml' | |
prefix: /_error |
Now it lives inside FrameworkBundle. That is why the framework-bundle recipe added the new file.
Hmm... but since we haven't updated the TwigBundle recipe yet, we temporarily have two routing files that are trying to add a route to the same /_error
URL. We'll update the TwigBundle recipe next to fix this.
Right now, add this file:
git add config/routes/dev/framework.yaml
And run:
git status
Hmm... yep! These last changes are the ones we do not want. Revert them with:
git checkout .
We're ready to commit the biggest recipe upgrade we're going to have:
git commit -m "upgrading symfony/framework-bundle recipe"
Phew! Next, let's update the TwigBundle recipe then keep going onto the Mailer recipe and then the rest. Home stretch people!
Hey shirleenkneppers!
Hmm, that's very interesting! I'm "fairly" sure (but I could be wrong!) that nothing significant has changed in how Flex handles these updates. From your screenshot, it's definitely weird-looking. Before you ran the command, if you ran git status
did it show that there were no changes? It appears like you already had uncommitted changes even before you ran the recipe update command... but I can't be sure. Can you tell me more about what commands you ran and if everything was committed before running them?
Cheers!
Hi
Well all I did was use this command in my terminal "composer recipes:install symfony/framework-bundle --force -v" then options came up for the updates which is strange. That is where the screen shot came in those options came before I even put in the git command in the terminal. I will experiment with this a bit later. Maybe give you proper screen shots of each step. Because think the options to update certain files comes then before you use the git command.
mmmmm this time around I didn't get that issue. It is now displaying exactly like your tutorial so I must have done something different before. But thank you for your reply. Seems everything else is now as it should be.
No problem shirleenkneppers! I appreciate you keeping a close eye for potential bugs or bad behavior that we would want to fix ;).
Cheers!
// composer.json
{
"require": {
"php": "^7.3.0",
"ext-iconv": "*",
"antishov/doctrine-extensions-bundle": "^1.4", // v1.4.2
"aws/aws-sdk-php": "^3.87", // 3.110.11
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"doctrine/doctrine-bundle": "^2.0", // 2.0.6
"doctrine/doctrine-migrations-bundle": "^1.3|^2.0", // 2.1.2
"doctrine/orm": "^2.5.11", // v2.7.2
"doctrine/persistence": "^1.3.7", // 1.3.8
"easycorp/easy-log-handler": "^1.0", // v1.0.9
"http-interop/http-factory-guzzle": "^1.0", // 1.0.0
"knplabs/knp-markdown-bundle": "^1.7", // 1.8.1
"knplabs/knp-paginator-bundle": "^5.0", // v5.0.0
"knplabs/knp-snappy-bundle": "^1.6", // v1.7.0
"knplabs/knp-time-bundle": "^1.8", // v1.11.0
"league/flysystem-aws-s3-v3": "^1.0", // 1.0.23
"league/flysystem-cached-adapter": "^1.0", // 1.0.9
"league/html-to-markdown": "^4.8", // 4.8.2
"liip/imagine-bundle": "^2.1", // 2.3.0
"nexylan/slack-bundle": "^2.1", // v2.2.1
"oneup/flysystem-bundle": "^3.0", // 3.3.0
"php-http/guzzle6-adapter": "^2.0", // v2.0.1
"sensio/framework-extra-bundle": "^5.1", // v5.5.3
"symfony/asset": "5.0.*", // v5.0.2
"symfony/console": "5.0.*", // v5.0.2
"symfony/dotenv": "5.0.*", // v5.0.2
"symfony/flex": "^1.0", // v1.17.6
"symfony/form": "5.0.*", // v5.0.2
"symfony/framework-bundle": "5.0.*", // v5.0.2
"symfony/mailer": "5.0.*", // v5.0.2
"symfony/messenger": "5.0.*", // v5.0.2
"symfony/monolog-bundle": "^3.5", // v3.5.0
"symfony/security-bundle": "5.0.*", // v5.0.2
"symfony/sendgrid-mailer": "5.0.*", // v5.0.2
"symfony/serializer-pack": "^1.0", // v1.0.2
"symfony/twig-bundle": "5.0.*", // v5.0.2
"symfony/twig-pack": "^1.0", // v1.0.0
"symfony/validator": "5.0.*", // v5.0.2
"symfony/webpack-encore-bundle": "^1.4", // v1.7.2
"symfony/yaml": "5.0.*", // v5.0.2
"twig/cssinliner-extra": "^2.12", // v2.12.0
"twig/extensions": "^1.5", // v1.5.4
"twig/inky-extra": "^2.12" // v2.12.0
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.0", // 3.3.0
"fzaninotto/faker": "^1.7", // v1.8.0
"symfony/browser-kit": "5.0.*", // v5.0.2
"symfony/debug-bundle": "5.0.*", // v5.0.2
"symfony/maker-bundle": "^1.0", // v1.14.3
"symfony/phpunit-bridge": "5.0.*", // v5.0.2
"symfony/profiler-pack": "^1.0", // v1.0.4
"symfony/var-dumper": "5.0.*" // v5.0.2
}
}
Well following this but for some reason it isn't showing things exactly like it would show on the tutorial so I think most of the files that you didn't want changed is now changed. I seem to see the set changes before the "git add -p" like so https://imgur.com/a/JOWFvfm . So I recon they have changed it since this tutorial. I am not sure to be honest. It might be my setup as well. It would be nice to shed some light on this.