There were added not that long ago and very welcomed by some developers (including myself).

I don’t think it hurts to leave them. Especially debug_toolbar.

@hacfi when you use the ParameterHandler to ask you for the parameters when running a composer install (which is quite handy when you add a new feature requiring a new parameter, to avoid having all devs of your team complaining about their setup being broken because of a missing parameter for instance), having parameters which are not related to the infrastructure (and so that you don't need to define yourselves) is annoying.

I would even say that %database_driver% would be a good candidate for the simplification too. Your database platform is very unlikely to change depending on the place where you deploy, as it would make things much harder.
IIRC, the reason it is there was because of the web configurator shipped in SensioDistributionBundle, which was the main way to start using Symfony in the 2.0 era, allowing to configure parameters through a form rather than writing YAML (and failing half of the time because of app/config/parameters.yml not being writable by the webserver...)

@hacfi note that nothing prevents you to keep these parameters in your own project if you find them handy

Ok..I’m fine with the removal then. I just thought it’s a feature (enable/disable debug_toolbar) even beginners might want to use early on.

In few projects I maintained, I do the following tricks:

• I create a app/config/parameters_static.yml will all default values, like email_from, support_email_to, use_real_payment_gateway, assets_on_cdn, toolbar, etc etc.
• I try to keep app/config/parameters.yml.dist as small as possible (as explained by @javiereguiluz in the PR description).
• In app/config/config.yml I do

imports:
    - { resource: parameters_static.yml }
    - { resource: parameters.yml }

Like that:

• all parameters are override-able in parameter.yml
• specific parameter are override-able in config_test.yml
• the project installation for new comers is simple
• it's easy to override some param with ParameterHandler for production deployment

That's a great solution..thanks @lyrixx

Now that the "Best Practices" book has been published, another reason for merging this proposal is that it's better aligned with those recommendations.

👍

Thank you @javiereguiluz.

@fabpot what do you think about my comment related to the database driver ?

The locale shouldn't be in parameters as well?! The default locale does not change from server to server or developer to developer.

And the changes reverted here were done in #603 exactly to be able to change it per dev.

And what about secret. I don't think it's used for CSRF tokens anymore as explained in http://symfony.com/doc/current/reference/configuration/framework.html#secret
And even if yes, it makes no sense that the secret would be different from server to server. If you have a loader balancer in front, the token could be invalid depending on which secret is configured on which server.

@Tobion I agree with you about the locale, but I disagree with you for the secret. Because you should avoid to commit "password / secret" in your SCM.

Also, when you analyze your app with Insight tool, it suggests you to put your secret key in parameters.yml.