SymfonyCasts stands united with the people of Ukraine
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 are in the Flex home stretch! These last config/ files are the easiest. Start with config_dev.yml.
Ok, we have a cache_type parameter. This is meant to override the value that lives in services.yaml whenever we're in the dev environment.
How can we have dev-specific parameters or services in Flex? By creating a new services_dev.yaml file. Copy the parameter, remove it and paste it here.
| parameters: | |
| cache_type: array |
Symfony will automatically load this file in the dev environment only.
For the rest of this file... we haven't really changed anything: these are the original default values. So there's a good chance that we can just use the new files without doing anything.
And yea! If you investigated, you would find that the framework config is already represented in the new files. And the profiler... well actually... that's not even installed yet. Let's fix that:
composer require profiler
Go back and remove the framework and web_profiler sections. When Composer finishes... yes! This installed a recipe. The new web_profiler.yaml file contains exactly what we just removed. It even added config for the test environment and loaded the routes it needs. Thanks profiler!
| web_profiler: | |
| toolbar: true | |
| intercept_redirects: false | |
| framework: | |
| profiler: { only_exceptions: false } |
| web_profiler: | |
| toolbar: false | |
| intercept_redirects: false | |
| framework: | |
| profiler: { collect: false } |
| web_profiler_wdt: | |
| resource: '@WebProfilerBundle/Resources/config/routing/wdt.xml' | |
| prefix: /_wdt | |
| web_profiler_profiler: | |
| resource: '@WebProfilerBundle/Resources/config/routing/profiler.xml' | |
| prefix: /_profiler |
The last key in config_dev.yml is monolog. Monolog is installed... and its recipe added config for the dev and prod environments.
I haven't made any changes to my monolog config that I really care about - just this firephp section, which I could re-add if I want. So I'll use the new default config and just... delete config_dev.yml! We can also delete config_prod.yml.
Oh, by the way, if you have some doctrine caching config in config_prod.yml, I would recommend not migrating it. The DoctrineBundle recipe gives you prod configuration that is great for production out-of-the-box. Booya!
Next: config_test.yml. And yea... this is still just default config. But there is one gotcha: in config/packages/test/framework.yaml, uncomment the session config.
| framework: | |
| ... line 2 | |
| session: | |
| storage_id: session.storage.mock_file |
I mentioned earlier that the session config is not perfect smooth: if you need sessions, you need to uncomment some config in the main framework.yaml and here too.
Ok, delete config_test.yml!
What about parameters.yml? In Flex, this file does not exist. Instead of referencing parameters, we reference environment variables. And in the dev environment, we set these in the .env file.
We also had a parameters.yml.dist file, which kept track of all the parameters we need. In Flex, yea, we've got the same: .env.dist.
The parameters.yml file in this project only holds database config and secret... and both of these are already inside .env and .env.dist.
The only difference between the files is how you reference the config. In doctrine.yaml, instead of using %DATABASE_URL% to reference a paramter, you reference environment variables with a strange config: %env(DATABASE_URL)%.
But other than that, it's the same idea. Oh, the resolve: part is optional: it allows you to put parameters inside of your environment variable values.
So... we're good! Delete parameters.yml and parameters.yml.dist. If you have other keys in parameters.yml, add them to .env and .env.dist and then go update where they're referenced to use the new syntax. Easy peasy.
While we're on the topic, in .env, update your database config: I'll use root with no password and call the database symfony4_tutorial.
Copy that and repeat it in .env.dist: I want this to be my default value.
| ... lines 1 - 15 | |
| DATABASE_URL=mysql://root:@127.0.0.1:3306/symfony4_tutorial | |
| ... lines 17 - 25 |
Back to the mission! What about routing.yml? Copy its contents. I'll close a few directories... then open config/routes.yaml. Paste here!
| app: | |
| resource: "@AppBundle/Controller/" | |
| type: annotation | |
| homepage: | |
| path: / | |
| defaults: | |
| _controller: AppBundle:Main:homepage |
We already have a config/routes/dev/annotations.yaml file that loads annotation routes from src/Controller. But for now, we still need our import because it loads routes from AppBundle.
But we do need to make two small changes. Even though we'll keep the AppBundle directory for now, we are not going to actually register it as a bundle anymore. Yep, AppBundle.php can be deleted: we just don't need bundles anymore.
But to make this work, we need to replace @AppBundle with a normal path: ../src/AppBundle/Controller.
And for the homepage route, remove the weird three-part colon syntax and just use the full class name: AppBundle\Controller\MainController::homepageAction.
| app: | |
| resource: "../src/AppBundle/Controller/" | |
| ... lines 3 - 4 | |
| homepage: | |
| ... line 6 | |
| defaults: | |
| _controller: AppBundle\Controller\MainController::homepageAction |
I am so happy to be done with those two Symfony-specific syntaxes! Delete routing.yml. And... routing_dev.yml? Yep, delete it too! The Flex recipes handle this stuff too.
In fact, delete the config/ directory!
Does our app work? Try to list the routes:
./bin/console debug:router
Ha! Yes! We have our routes back!
Next, let's delete some files - that's always fun - and then welcome our new Flex app!
Hey Vlad,
Good question! And actually we're answering it in new Symfony 4 screencasts, for example, here: https://knpuniversity.com/s...
So, in shorts, you're correct, everything in config/packages/ level is considered as a global config which is loaded for any environment. But then you can overwrite some configuration using env-specific configs like config/packages/dev/, config/packages/prod/, config/packages/test/, etc.
Cheers!
danielqg93
| posted 10 months ago
Can version 3.4 be upgraded to version 4.4, following the steps shown in this course?
Hey Daniel,
This course only covers upgrading from version 3 to 4, if you're interested in upgrading to version 4 to 5, you can what this other tutorial https://symfonycasts.com/screencast/symfony5-upgrade
Although, it's quite easy to upgrade minor Symfony versions https://symfony.com/doc/current/setup/upgrade_minor.html
Cheers!
Hi! I didn't use annotations for my routes, I have a separate YML file for each of my bundles (from before, when code were supposed to be compartmentalized into bundles...). The video doesn't cover what to do about those, so I was wondering if I could have a quick hint? So I import my bundle-specific routes like this:
`extra_opening:
resource: "../src/AppBundle//Resources/config/routing/ExtraOpening/routing.yml"
prefix: /`
and the contents of that file would be
`extra_opening_extraopening:
resource: "@AppBundle/Resources/config/routing/extraopening/extraopening.yml"
prefix: /extraopening
extra_opening_price:
resource: "@AppBundle/Resources/config/routing/extraopening/price.yml"
prefix: /price
extra_opening_debitperiod:
resource: "@AppBundle/Resources/config/routing/extraopening/debitperiod.yml"
prefix: /debitperiod`
And each of those would in turn contain the actual controller connections as such
`extraopening_index:
path: /
defaults: { _controller: "AppBundle:ExtraOpening/ExtraOpening:index" }
methods: [GET]
extraopening_new:
path: /new/{debitPeriod}
defaults: { _controller: "AppBundle:ExtraOpening/ExtraOpening:new", "debitPeriod" : null }
methods: [GET, POST]
extraopening_edit:
path: /{id}/edit
defaults: { _controller: "AppBundle:ExtraOpening/ExtraOpening:edit" }
methods: [GET, POST]`
Perhaps it'd be easier to move to annotation routing, but I'd like to get my app working at all before digging into that project of further refactoring things...
Hey @MattiasWelander!
I agree to get things working first! It doesn't matter much what you do with these routes. You could keep them all as is. Or, could move them all into config/routes (and some sub-directories) and then have them import each other like you do now. Basically, these files never really depended on the bundles: they were just files importing other files. We kept these in our app, then moved them to annotations over time.
For the actual routes themselves (which reference AppBundle:, if you want to remove AppBundle, then refactor these to use the class name of the controller - I think it would be _controller: "App\Controller\ExtraOpening\ExtraOpening::edit".
Let me know if that helps - or if I totally answered the wrong question :).
Cheers!
I'm giving it a try. Although, with your backslashie format like this:
`position_index:
path: /
defaults: { _controller: "App\AppBundle\Controller\Poslog\Position::index" }
methods: GET`
I get this error:
<blockquote> The file "XXX" does not contain valid YAML: Found unknown escape character "\A" at line 5 (near "defaults: { _controller: "App\AppBundle\Controller\Poslog\Position::index" }")</blockquote>
Apparently, YAML doesn't like backslashes? =) It thinks I'm trying to escape a reserved character for some reason
I have been blocked for a few days with this error that I can not get out. Some idea tranks
You have requested a non-existent parameter "kernel.default_locale".
Hey there,
I believe you forgot to wrap with % the name of the paramter like this "%kernel.default_locale%"
Cheers!
// composer.json
{
"require": {
"php": "^7.1.3",
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"doctrine/doctrine-bundle": "^1.6", // 1.8.1
"doctrine/doctrine-cache-bundle": "^1.2", // 1.3.2
"doctrine/doctrine-migrations-bundle": "^1.1", // v1.3.1
"doctrine/orm": "^2.5", // v2.7.2
"fzaninotto/faker": "^1.7", // v1.7.1
"knplabs/knp-markdown-bundle": "^1.4", // 1.6.0
"sensio/framework-extra-bundle": "^5.0", // v5.1.3
"stof/doctrine-extensions-bundle": "dev-master", // dev-master
"symfony/asset": "^4.0", // v4.0.1
"symfony/console": "^4.0", // v4.0.1
"symfony/flex": "^1.0", // v1.9.10
"symfony/form": "^4.0", // v4.0.1
"symfony/framework-bundle": "^4.0", // v4.0.1
"symfony/lts": "^4@dev", // dev-master
"symfony/maker-bundle": "^1.0", // v1.0.2
"symfony/monolog-bundle": "^3.1", // v3.1.2
"symfony/polyfill-apcu": "^1.0", // v1.6.0
"symfony/profiler-pack": "^1.0", // v1.0.3
"symfony/security-bundle": "^4.0", // v4.0.1
"symfony/security-csrf": "^4.0",
"symfony/swiftmailer-bundle": "^3.1", // v3.1.6
"symfony/translation": "^4.0", // v4.0.1
"symfony/twig-bundle": "^4.0", // v4.0.1
"symfony/validator": "^4.0", // v4.0.1
"symfony/web-server-bundle": "^4.0", // v4.0.1
"symfony/yaml": "^4.0" // v4.0.1
},
"require-dev": {
"symfony/dotenv": "^4.0", // v4.0.1
"symfony/phpunit-bridge": "^4.0", // v4.0.1
"doctrine/doctrine-fixtures-bundle": "^3.0" // 3.0.2
}
}
Hello,
Why are some recipe YAML files installed in the dev, prod and test directories, while others in the top-level packages directory? A good example of it is swiftmailer.yaml, which is found in packages, dev, test but not prod. Is anything that's in packages considered to be a global config and anything in the inner directories overrides it?
Thanks and 73,