This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6945).
Commits
-------
a2a2f54 fixed wrong indentation
Discussion
----------
fixed wrong indentation
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6944).
Commits
-------
2b850b5 [Form] [Validator] [Security] Add Arabic translations.
Discussion
----------
[Form] [Validator] [Security] Add Arabic translations.
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6925).
Commits
-------
0586643 renamed some classes and Twig functions to more descriptive names (refs #6871)
Discussion
----------
renamed some classes and Twig functions to more descriptive names (refs #6871)
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6871
| License | MIT
| Doc PR | symfony/symfony-docs#2205
Todo:
- [x] update the docs
In #6871, @kriswallsmith wondered if the names used for the ESI/HIncludes sub-framework were meaningful enough.
I agree that this was not the case and I propose to remove the notion of **sub-requests** in favor of **fragments**. This sub-framework is a way to render fragments of a resource (the fact that it's done via another request is an implementation detail).
With that decision, all names can be renamed and are probably more meaningful. Some examples:
* `HttpContentRenderer` -> `FragmentHandler`
* `RouterProxyListener` -> `FragmentListener`
* `router_proxy` -> `fragments` (configuration entry)
* `DefaultRenderingStrategy` -> `InlineFragmentRenderer`
---------------------------------------------------------------------------
by fabpot at 2013-01-31T09:50:14Z
I forgot to mention that this renaming will also probably help documenting the feature as understanding the notion of a fragment is probably easier.
---------------------------------------------------------------------------
by Tobion at 2013-01-31T14:18:40Z
I'd like to say again that the word `render` in `FragmentRenderingStrategy` does not fit because it's not about rendering (that's left to the templating) of a fragment.
I suggest to rename it to `FragmentInclusionStrategy` because it defines the strategy to include the fragment.
This is also consistent with every strategy there is:
- ESI: `<esi:include`
- SSI: `<!--#include file="header.shtml" -->`
- hinclude (even in the name)
- inline (similar to phps `include()`)
---------------------------------------------------------------------------
by fabpot at 2013-01-31T14:48:07Z
I've just renamed `FragmentRenderer` to `FragmentHandler` and strategies like `EsiFragmentRenderingStrategy` to `EsiFragmentRenderer` (and everything is put into a new `Fragment` sub-namespace).
---------------------------------------------------------------------------
by fabpot at 2013-01-31T21:11:44Z
I've reverted the Twig function name change as the current name is more expressive with its arguments: `render(controller(...))` or `render_esi(url(...))`.
HttpContentRenderer has been renamed to FragmentHandler.
The RendererStrategy subnamespace has been renamed to Fragment.
The strategy classes now have Fragment in their names.
ProxyRouterListener has been renamed to FragmentListener
The router_proxy configuration entry has been renamed to fragments.
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6258).
Commits
-------
d4acd6d Classcollectionloader: fix traits + enhancements
Discussion
----------
Classcollectionloader: fix traits + enhancements
Commits:
- some tweaks
- generates smaller cache files (20% decrease for the SE)
- fix traits dependency - thanks php for consistency https://bugs.php.net/bug.php?id=61554
---------------------------------------------------------------------------
by vicb at 2012-12-11T07:56:07Z
@stloyd @fabpot thanks for the useful reviews, everything should be fixed now.
---------------------------------------------------------------------------
by vicb at 2012-12-11T10:03:48Z
Should be ready.
---------------------------------------------------------------------------
by vicb at 2013-01-15T21:05:42Z
@fabpot I initially marked this PR for 2.3 but it contains a fix for traits, should you merge it ?
---------------------------------------------------------------------------
by vicb at 2013-01-23T20:09:32Z
@fabpot could this be in 2.2 ?
---------------------------------------------------------------------------
by vicb at 2013-02-01T14:07:08Z
@fabpot fixed
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6938).
Commits
-------
b279dcb [Validator] Fix a deprecated method call in the tests
Discussion
----------
[Validator] Fix a deprecated method call in the tests
BUG FIX - Travis happier ?
---------------------------------------------------------------------------
by stloyd at 2013-02-01T12:23:18Z
This should go to `2.2` I guess... =)
---------------------------------------------------------------------------
by vicb at 2013-02-01T12:25:43Z
Well there has been no official announcement for the 2.2 branch I think ?
I hope that some PR pending for master will go into 2.2 anyway ?
/cc @fabpot
---------------------------------------------------------------------------
by vicb at 2013-02-01T12:38:35Z
C'mon Travis, aren't you allowed to fail for 5.5 ?
---------------------------------------------------------------------------
by stloyd at 2013-02-01T12:43:42Z
@vicb error != failed ;-) Yet I agree, that now it's more confusing than before this new status...
---------------------------------------------------------------------------
by fabpot at 2013-02-01T13:27:11Z
I will merged it into 2.2. 2.2 is entering the RC phase, so no more modifications will be merged.
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6632).
Commits
-------
a1c0ff5 Update `composer.json` files: - to allow versions ~2.2 (>=2.2,<3.0) of Doctrine DBAL, ORM & Common - fixed Propel1 versions difference between main and bridge files - fixed Twig versions difference between main and bridge files - to allow versions ~1.11 (>=1.11,<2.0) of Twig - fixed Locale ext-intl version to accept all, not non-existing version
Discussion
----------
Update `composer.json` files
---------------------------------------------------------------------------
by fabpot at 2013-01-09T17:55:54Z
When will Doctrine 2.4 be released? If not in the next couple of weeks, this PR cannot be merged as we need to ship Symfony 2.2 with a stable version of Doctrine.
---------------------------------------------------------------------------
by stof at 2013-01-09T18:13:59Z
@fabpot This allows to use Doctrine 2.4. It does not require to use 2.4. Actually, as Doctrine releases are BC, I would even vote for using ``~2.2`` as requirement
---------------------------------------------------------------------------
by fabpot at 2013-01-10T08:18:52Z
If the Doctrine is fine with `~2.2`, let's do that. @beberlei Can you confirm?
---------------------------------------------------------------------------
by stloyd at 2013-01-10T08:30:19Z
As Doctrine latest release is `2.3.2` maybe for Symfony `2.2` we should increase to `~2.3` not `~2.2` ?
---------------------------------------------------------------------------
by stof at 2013-01-10T09:15:00Z
@stloyd Why should we force using 2.3 when we don't require any of the 2.3 features ? Composer will use the most recent package matching the constraint anyway, so 2.2 will not be used unless someone forbids 2.3 in another package.
---------------------------------------------------------------------------
by stloyd at 2013-01-29T19:24:09Z
@fabpot ping
This PR was merged into the master branch.
Commits
-------
924c256 Remove executable bit from all PHP files
Discussion
----------
Remove executable bit from all PHP files
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? |
| Fixed tickets |
| License | MIT
| Doc PR |
Apologies if I haven't got the protocol quite right here. This is my first interaction with this project.
By the way, I've noticed a non-trivial number of pull requests to remove executable bits. Could there be an automated test to prevent files getting into the repo with them on in the first place?
This PR was merged into the master branch.
Commits
-------
d0341e8 Replaced call that triggers deprecated error
Discussion
----------
[Validator][ChoiceValidator] Replaced call that triggers deprecated error
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
This removes the deprecation warnings from the ChoiceValidator.
This PR was merged into the master branch.
Commits
-------
b1d1168 Fixed the NullLogger to implement the HttpKernel interface again
Discussion
----------
Fixed the NullLogger to implement the HttpKernel interface again
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no (reverting one introduced by mistake)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR | n/a
This BC breaking mistake has been reported in https://github.com/schmittjoh/JMSSecurityExtraBundle/pull/105#issuecomment-12908659
This PR was merged into the master branch.
Commits
-------
ed3a875 [Finder] Fixed test
Discussion
----------
[Finder] Fixed test
Fixed tests broken by PR #6911.
Iterator keys were considered as incremented index in `FilePathsIteratorTest`.
This PR was merged into the master branch.
Commits
-------
ef593fa [Finder] Fixed iterator keys
d16e28a [Finder] Added iterator keys test
Discussion
----------
[Finder] Fixes iterator keys
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6891
| License | MIT
Previous PR I did on finder introduced a BR break (finder iterator keys must be the pathname of the file, not an incremented index). This PR adds a test to ensure this wont be broken again and fixes the BC break.
This PR was squashed before being merged into the master branch (closes#6852).
Commits
-------
fde7585 [DIC] Better handling of enableable configurations
Discussion
----------
[DIC] Better handling of enableable configurations
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no, this feature has not been released yet
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
My definition of bug fix might be discussable. The thing which I think is not discussable is that this PR fixes the semantic - and I think it is important for a "semantic configuration": before this PR, some nodes had `->canBeDisabled` for nodes that were actually disabled by default. Those nodes now have `->canBeEnabled` which sounds right.
**Edit: Jan 28, 2013** - history:
See [the related comments](https://github.com/symfony/symfony/pull/6829#discussion_r2727742).
I think Symfony **must** get the configuration right as we can expect of lot of devs to use this as a template when writting their own configuration.
@schmittjoh could you please give me your feedback on [this change](https://github.com/symfony/symfony/pull/6852/files#L4R224) considering [the rationale](https://github.com/symfony/symfony/pull/6852/files#L3R7).
---------------------------------------------------------------------------
by stof at 2013-01-23T16:10:33Z
@vicb your links are broken as they are pointing to the PR creation page
---------------------------------------------------------------------------
by stof at 2013-01-23T16:10:55Z
and to create a TODO list, it has to be a list first
---------------------------------------------------------------------------
by vicb at 2013-01-23T16:31:10Z
@stof thanks for reporting the broken links, they are fixed /cc @schmittjoh
---------------------------------------------------------------------------
by vicb at 2013-01-23T16:31:50Z
@Tobion please submit a PR to my repo, I don't have much time to work on this. Thanks !
---------------------------------------------------------------------------
by vicb at 2013-01-25T15:14:47Z
@fabpot @schmittjoh I'd like your feedback on the latest commit, rationale is in the method phpDoc. It better matches what we do now and seem the most sensible thing to do.
edit: with this you can no more disable the node explicitly, I have to find a better solution
---------------------------------------------------------------------------
by schmittjoh at 2013-01-25T15:20:13Z
Looks good.
On Fri, Jan 25, 2013 at 4:15 PM, Victor Berchet <notifications@github.com>wrote:
> @fabpot <https://github.com/fabpot> @schmittjoh<https://github.com/schmittjoh>I'd like your feedback on the latest commit, rationale is in the method
> phpDoc. It better matches what we do now and seem the most sensible thing
> to do.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/6852#issuecomment-12704585>.
>
>
---------------------------------------------------------------------------
by vicb at 2013-01-28T14:37:57Z
@fabpot I know I keep insisting on this one and I am sorry for that but I think this should be considered as a bug fix (see the PR header for details) and should be merged in 2.2. I think the Symfony core should be exemplary as it is used by many developers as a template when creating their own bundle. *This PR is no more a WIP and can be merged right now*.
In addition to fixing the enableable nodes, this PR contain new UTs and some fixes to the code / tests.
---------------------------------------------------------------------------
by fabpot at 2013-01-28T16:43:42Z
@vicb As explained in a comment, this is not a BC break as this feature does not exist in 2.1. So, I can make the change to the CHANGELOG if you want after merging, or I can let you make the change.
---------------------------------------------------------------------------
by vicb at 2013-01-28T16:46:33Z
I am going to change it right now !
---------------------------------------------------------------------------
by vicb at 2013-01-28T16:46:56Z
(and thanks for having checked this)
---------------------------------------------------------------------------
by vicb at 2013-01-28T16:54:37Z
@fabpot I have updated the changelog and the PR header.
I am not sure if the commits should be squashed or not. On one side the multiple commits can help understand the changes but on the other side that's a lot of small commits which could pollute history. I let you choose what to do.
This PR was squashed before being merged into the master branch (closes#6893).
Commits
-------
7cff461 [Routing] Improve RouteNotFoundException messages
Discussion
----------
[Routing] Improve RouteNotFoundException messages
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | Travis?
| Fixed tickets | -
| License | MIT
| Doc PR | -
The error message that is generated when a named route is not found can be a little confusing in the sense that one could think the name actually references a path for the route. This PR should make that a little clearer.
See [this Laravel ticket](https://github.com/laravel/framework/issues/177) for reference.
---------------------------------------------------------------------------
by franzliedke at 2013-01-28T09:44:43Z
Okay folks, I changed those. Thank you!
This PR was submitted for the master branch but it was merged into the 2.1 branch instead (closes#6884).
Commits
-------
c261760 Fixed missing class argument when throwing exception
Discussion
----------
Added missing parameter to Exception in DebugClassLoader
The DebugClassLoader was missing the $class argument to sprintf() when it tries to throw the exception, making the actual error you are getting more daunting :)
---------------------------------------------------------------------------
by stof at 2013-01-25T23:31:58Z
oops, sorry.
@fabpot this should be merged in 2.1 as you merged the change there
This PR was merged into the master branch.
Commits
-------
e3086cc [Console] added some missing information in the phpdoc (closes#6464)
Discussion
----------
[Console] added some missing information in the phpdoc (closes#6464)
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6464
| License | MIT
| Doc PR | n/a
This PR was merged into the master branch.
Commits
-------
ed64413 removed deprecated message in FieldType
Discussion
----------
removed deprecated messages coming for internal calls
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6407
| License | MIT
| Doc PR | n/a
It's probably not the cleanest code possible, but I don't see any other way to keep the type for BC and avoid the deprecated message when called internally.
That should fix the deprecated messages thrown by the Form and Validator components.
---------------------------------------------------------------------------
by stof at 2013-01-24T15:41:26Z
The cases where you should actually be warned about the deprecation of FieldType is when using ``field`` to create a field with the factory (which would not trigger the constructor)
---------------------------------------------------------------------------
by fabpot at 2013-01-24T15:46:23Z
@stof: what do you mean? That we can remove the `trigger_error()` call altogether?
---------------------------------------------------------------------------
by stof at 2013-01-24T15:49:31Z
Nobody will ever instantiate the FieldType directly as the framework is registering it (btw, you are missing the FrameworkBundle lazy registration here).
The constructor of a form type is not the right place to deprecate it as registering it does not mean it will be used in the app.
---------------------------------------------------------------------------
by fabpot at 2013-01-24T15:51:26Z
@stof: I've updated the PR to remove the `trigger_error` call.
This PR was merged into the master branch.
Commits
-------
749087e updated ValidatorExtension to avoid using a deprecated method
Discussion
----------
updated ValidatorExtension to avoid using a deprecated method
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by stof at 2013-01-24T13:05:43Z
👍
Btw, this is needed to simply make it work against the ValidatorInterface by having the right expectation on getMetadataFactory()
This PR was merged into the master branch.
Commits
-------
8bfd7a7 Remove custom error handler for deprecations
efbff0c Change deprecated Min and Max constraint
c47f027 [Validator][Constraints] Update AllValidator using new Validator API
Discussion
----------
[Validator][Constraints] Update AllValidator using new Validator API
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
License of the code: MIT
