Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine

Finishing framework Config

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.

Start your All-Access Pass
Buy just this tutorial for $8.00

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

Login Subscribe

Let's finish this! Back on debug:config, search for default_locale. Apparently, it's already set to en. Cool! Let's remove that from config.yml. You can move it if you want: the translator did add a locale parameter. I'll delete it.

Migrating csrf_protection

Close a few files: I want to keep comparing config.yml and framework.yaml. In config.yml, we have csrf_protection activated. Ok, so uncomment it in framework.yaml. Then, remove it from config.yml. Let's also remove serializer: I wasn't using it before. If you are, run composer require serializer to activate it. No config is needed.

framework:
... lines 2 - 3
csrf_protection: ~
... lines 5 - 16

Ok, let's see if we broke anything! Run:

./bin/console

Woh! We're busted!

CSRF support cannot be enabled as the Security CSRF component is not installed.

Ohhhh. Like translation and form, csrf_protection activates a component that we don't have installed! No problem! Go back to symfony.sh and search for "csrf". There it is! Run:

composer require security-csrf

By the way, once this is installed, the csrf_protection key in framework.yaml should not be needed... well, starting in Symfony 4.0.2... there was a small bug. Since I'm using 4.0.1, I'll keep it.

Let's go check on Composer. It downloads the package and... explodes!

CSRF protection needs sessions to be enabled

Enabling Sessions

Ah, sessions. They are off by default. Uncomment this config to activate them. Sessions are a bit weird, because, unlike translator or csrf_protection, you can't activate them simply by requiring a package. You need to manually change this config. It's no big deal, but it's the one part of framework config that isn't super smooth.

framework:
... lines 2 - 7
session:
# With this config, PHP's native session handling is used
handler_id: ~
... lines 11 - 16

Oh, and notice that this config is a bit different than before. In Symfony 3, we stored sessions in var/sessions. And you can still totally do this. But the new default tells PHP to store it on the filesystem wherever it wants. It's just one less thing to worry about: PHP will handle all the file permissions.

Tip

Just remember: when you change your session storage location, your users will lose their current session data when you first deploy!

Remove the old session configuration. Let's see if the app works!

./bin/console

Yes!

Migrate Twig

We're getting close! Next is templating. This component still exists, but isn't recommended anymore. Instead, you should use twig directly. So, delete it.

Tip

If your app references the templating service, you'll need to change that to twig.

But our app does use Twig. So find your terminal. Oh, let's commit first: I want to see what the Twig recipe does. Create a calm and sophisticated commit message. Now run:

composer require twig

Yay aliases! This added TwigBundle, and Flex installed its Recipe. Run:

git status

Ah, this made some cool changes! First, in config/bundles.php, it automatically enabled the bundle. Flex does this for every bundle. I love that!

It also added a config/packages/twig.yaml file. Where do templates live in a Flex app? You can see it right here! In templates/ at the root of our project. And hey! It even created that directory for us with base.html.twig inside.

The config in twig.yaml is almost the same as our old app. Copy the extra form_themes and number_format keys, delete the old config, and paste them at the bottom of twig.yaml.

twig:
paths: ['%kernel.project_dir%/templates']
debug: '%kernel.debug%'
strict_variables: '%kernel.debug%'
number_format:
thousands_separator: ','
form_themes:
- bootstrap_3_layout.html.twig
- _formTheme.html.twig

Oh, and the recipe gave us something else for free! Any routes in config/routes/dev are automatically loaded, but only in the dev environment. The recipe added a twig.yaml file there with a route import. This helps you debug and design your error pages. All of this stuff is handled automatically.

_errors:
resource: '@TwigBundle/Resources/config/routing/errors.xml'
prefix: /_error

Now that we know that template files should live in templates/, let's move them there! Open app/Resources/views. Copy all of the files and paste them. And yes, we do want to override the default base.html.twig.

Perfect! Now, celebrate: completely remove app/Resources/views. Actually, woh! We can delete all of Resources/! Our app/ directory is getting really small!

Migrating trusted_hosts, fragments & http_method_override

We're now down to the final parts of framework. So what about trusted_hosts, fragments and http_method_override? Remove all of those. And in framework.yaml, uncomment fragments.

framework:
... lines 2 - 12
fragments: ~
... lines 14 - 16

If you run:

bin/console debug:config framework

you'll see that the other keys already default to the old values. Yep, http_method_override is still true and trusted_hosts is already empty.

Migrating assets

This leaves us with one last key: assets. And guess what? This enables a component. And right now, in debug:config, you can see that assets is enabled: false.

Install it:

composer require asset

It installs the component, but this time, there is no recipe. But run debug:config again:

./bin/console debug:config framework

Search for "asset". Ha, yes! It enabled itself.

Ok: delete the framework key. This is huge! I know I know, it feels like we still have a lot of work to do. But that's not true! With framework out of the way, we are in the home stretch!

Leave a comment!

18
Login or Register to join the conversation
Gianluca M. Avatar
Gianluca M. Avatar Gianluca M. | posted 2 years ago

Your requirements could not be resolved to an installable set of packages.
Problem 1
- twig/extra-bundle v3.0.1 requires symfony/framework-bundle ^4.3|^5.0 -> no matching package found. I'm upgrading from 3.4 to flex 3.4 with skeleton

I'm resolved , simple. composer require twig-bundle

1 Reply

Hey Gianluca Mazzeo

I'm glad that you could fix your problem and thanks for sharing the solution

Cheers!

Reply
MattWelander Avatar
MattWelander Avatar MattWelander | posted 1 month ago

Hi! Trying to follow along =) "composer install asset" does NOT set assets enabled:true, for me it is still false in the "...debug:config framework". Suppose I can just set it manually, but that hints to me that perhaps I have a bigger problem, if other composer installs can't do what they are meant to either in my config. Could I have restricted composer from making changes somehow?

Reply

Hey Mattias,

Do you mean "composer require asset" instead of "composer install asset"? Because "install" command will fail as it does not exist.

I think you should check if you have Symfony plugin enabled, probably you forbid? In the composer.json you should have "symfony/flex": true, I think, otherwise Symfony Flex won't be able to make any changes in your project.

Also, it might be so that you have a few "assets:" keys in different config files, and so a one overwrites another.

Cheers!

Reply
MattWelander Avatar
MattWelander Avatar MattWelander | victor | posted 1 month ago

Indeed I meant "composer require asset" (@6:45 in the video). I have the same problem when running the require with monolog, no files are generated in config/packages/dev and config/packages/prod

"config": {
"preferred-install": {
"*": "dist"
},
"sort-packages": true,
"allow-plugins": {
"symfony/flex": true
}
},

Reply
MattWelander Avatar

Hmm.. removing monolog all together from the composer.json, running composer update, and then doing composer require monolog fixed the problem, then it actually created those files.

Reply

Hey Mattias,

Awesome, glad you were able to fix it! It sounds like you probably copy/pasted a symfony.lock file from our source project code? Symfony base on that file to make sure if it should execute any changes from recipe or no. Anyway, if something is not working right - the best option would be probably to remove it completely and try to install it again as you did with monolog, good job! This way it should work unless you deny the recipe execution.

Cheers!

Reply
Default user avatar
Default user avatar Farfunni | posted 1 year ago

Hello! Thank you for this great guide! I do have a problem with the framework.yaml configuration sadly though and I have not been able to figure out where the problem lies. All the configuration I put into framwork.yaml seems to be ignored. I cannot remove the framework block from the old app/config/config.yml file, because else all of the really necessary values are not set (f.e. secret, csfr_protection, session, .. ). Values that come from other configuration yaml files (from packages/*.yaml) are read as they should, it is really just framework.yaml that is broken. Have you had any similar experiences when upgrading to Symfony 4+ from 3.4? Thanks in advance!

Nevermind, I continued to open the page via app_dev.php instead of the new index.php. It is working now!

Reply

Hey Farfunni,

Glad you were able to figured out the problem yourself! Yeah, tricky problem to notice, well done! ;)

Cheers!

Reply
picks Avatar

Hi, what's the right folder stracture for business related JSON and YAML files ? I used to store them in app/Resources/json and app/Resources/yaml until now.
Thanks!

Reply

What do you mean by business related files? What do you store on such files? You can store those files inside config folder or probably inside var depends on your content but actually, you can use any folder you feel like it's better for your application

Cheers!

Reply
picks Avatar

ok. couldn't find anything about that online. these are JSON files that are used as small database, extracted from other online tools. I parse them to get data in my app. I just need somewhere to store them. for now I decided to create a "resourses" folder at the root of the app.

Reply

Oh, I get it, then I would suggest you to put it inside var/data folder, it just fits better :)

Reply
picks Avatar

Nice thanks!

Reply
Kaizoku Avatar
Kaizoku Avatar Kaizoku | posted 4 years ago

You need to keep the templating key if you use FOSUser Bundle.

Reply

Ah, you're right. And I think it's just for ONE spot in FOSUserBundle. Hopefully they can just remove that!

Reply
GDIBass Avatar
GDIBass Avatar GDIBass | posted 4 years ago

What's the right folder structure for overriding bundle templates now? I assume they're in templates? Is it templates/bundles/BundleName

Reply

Hey Matt,

Yes, you're right! It should be "templates/bundles/{BUNDLE_NAME}/{PATH/TO/TEMPLATE.html.twig}". Actually, check this docs: https://symfony.com/doc/cur...

Cheers!

Reply
Cat in space

"Houston: no signs of life"
Start the conversation!

What PHP libraries does this tutorial use?

// 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
    }
}