10000 Change default feature config to disabled · Issue #13703 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

Change default feature config to disabled #13703

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tobion opened this issue Feb 16, 2015 · 7 comments
Closed

Change default feature config to disabled #13703

Tobion opened this issue Feb 16, 2015 · 7 comments
Labels

Comments

@Tobion
Copy link
Contributor
Tobion commented Feb 16, 2015

What about disabling all components by default in symfony 3.0.
I think it's really confusing that some things are enabled by default and others are disabled by default. This way it's really hard to configure a symfony where only the stuff you need is enabled because you have to figure out all the defaults first.

Indeed, having everything disabled by default would be better; and Symfony SE can enable the most important things and add comments to enable less important features. Anyone willing to work on this for 3.0?
fabpot

#13672 (comment)

@sstok
Copy link
Contributor
sstok commented Feb 22, 2015

👍

@weaverryan
Copy link
Member

I like it a lot 👍

fabpot added a commit that referenced this issue Feb 26, 2015
…zal)

This PR was merged into the 3.0-dev branch.

Discussion
----------

[FrameworkBundle] Update assets configuration tests

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Previously, assets where enabled if `templating` didn't contain asset configuration. This has been removed in #13666.

Instead of enabling it back I propose to keep it disabled and update the tests instead, since we already discussed disabling all FrameworkBundle features by default for 3.0 (#13703).

Commits
-------

5007b41 [Form] Replace use of bind() with submit() in a test.
494e300 [SecurityBundle] Enable assets in functional tests.
4c26875 [FrameworkBundle] Fix a default config test case and add a new one for enabling assets.
b0f6a19 [FrameworkBundle] Remove a legacy test.
@Tobion Tobion added this to the 3.0 milestone Apr 11, 2015
@ghost
Copy link
ghost commented May 13, 2015

👍

@GuilhemN
Copy link
Contributor
GuilhemN commented Feb 1, 2016

I looked the FrameworkBundle configuration and I didn't see any components activated by default. Which one are you talking about?

Not completely related, but sometimes canBeUnset is used and sometimes canBeEnabled is used and it doesn't always make sense so IMO we should also make this less confusing.

@Tobion Tobion modified the milestones: 4.0, 3.0 Feb 1, 2016
@Tobion
Copy link
Contributor Author
Tobion commented Feb 2, 2016

It's true that the things that can be configured are disabled by default. But alot of stuff is loaded without being able to disable it:

  • property_access
  • annotations
  • fragment_renderer
  • translation

And the inconsistency withcanBeUnset and canBeEnabled between alot of configurations as you said. This is a pain when you use the SE and want to remove the stuff that you don't need. The most reliable way is to remove the entry completely.

# both behave the same for each config value luckily
framework:
    form: false | true | null
    session: false | true | null

framework:
    form: 
        enabled :false # works
    session:
        enabled :false # does not work (Unrecognized option "enabled" under "framework.session")

@GuilhemN
Copy link
Contributor
GuilhemN commented Feb 4, 2016

Ok thank you for your answer I'll see if I can do something :-)

@GuilhemN
Copy link
Contributor
GuilhemN commented Feb 5, 2016

@Tobion I opened #17690 and #17706

fabpot added a commit that referenced this issue Mar 2, 2016
…nset() for consistency (Ener-Getick)

This PR was squashed before being merged into the 3.1-dev branch (closes #17690).

Discussion
----------

[FrameworkBundle] Use canBeEnabled() instead of canBeUnset() for consistency

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #13703
| License       | MIT

I'm not sure if we should consider this as a bug fix or as a new feature.

Commits
-------

39723c5 [FrameworkBundle] Use canBeEnabled() instead of canBeUnset() for consistency
symfony-splitter pushed a commit to symfony/framework-bundle that referenced this issue Mar 2, 2016
…nset() for consistency (Ener-Getick)

This PR was squashed before being merged into the 3.1-dev branch (closes #17690).

Discussion
----------

[FrameworkBundle] Use canBeEnabled() instead of canBeUnset() for consistency

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | symfony/symfony#13703
| License       | MIT

I'm not sure if we should consider this as a bug fix or as a new feature.

Commits
-------

39723c5 [FrameworkBundle] Use canBeEnabled() instead of canBeUnset() for consistency
@fabpot fabpot closed this as completed Mar 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants
0