* 2.2:
bumped Symfony version to 2.2.7
updated VERSION for 2.2.6
update CONTRIBUTORS for 2.2.6
updated CHANGELOG for 2.2.6
clearToken exception is thrown at wrong place.
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#8830).
Discussion
----------
clearToken exception is thrown at wrong place.
The PR https://github.com/symfony/symfony/pull/8528 has added a problem when logger is enabled.
The log message for clearToken exception throw actually a fatal error because $failed doesn't exist in clearToken method. I have moved the log message to the handle method.
Commits
-------
701c25b clearToken exception is thrown at wrong place.
* 2.2:
fix typo in test skipped message
[Form] Fixed Form::all() signature for PHP 5.3.3
[Translation] Grammar fix
[Translation] Fixed regression: When only one rule is passed to transChoice(), this rule should be used
Conflicts:
src/Symfony/Component/Form/Util/VirtualFormAwareIterator.php
This PR was merged into the 2.3 branch.
Discussion
----------
[2.3][Form] Dereferenced Form::&all() since it is not supported for PHP <= 5.3.3
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
see 00bc2708bc and #8851
Commits
-------
fd09484 [Form] Fixed Form::all() signature for PHP 5.3.3
This PR was merged into the 2.2 branch.
Discussion
----------
[2.2][Form] Dereferenced Form::&all() since it is not supported for PHP <= 5.3.3
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
see 00bc2708bc
Commits
-------
ea480bd [Form] Fixed Form::all() signature for PHP 5.3.3
This PR was submitted for the 2.1 branch but it was merged into the 2.2 branch instead (closes#8855).
Discussion
----------
[HttpFoundation] [Tests] fix typo in Memcached tests skipped message
| Q | A
| ------------- | ---
| Typo fix | yes
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
| Fixed tickets | -
| Doc PR | -
Commits
-------
83e4fcf fix typo in test skipped message
This PR was merged into the 2.2 branch.
Discussion
----------
[Translation] Fixed regression: When only one rule is passed to transChoice(), this rule should be used
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
There was one regression introduced by #8789, namely when exactly one message is passed to `transChoice()`. Before, the following code was perfectly valid:
```php
$translator = new IdentityTranslator(new MessageSelector());
echo $translator->transChoice('There are two apples', 2, array('%count%' => 2));
```
This didn't fail, because internally, the locale `null` was passed to `MessageSelector`, which always returned the index `0` in that case.
Now, the user's locale is passed, and if the selector returns anything but `0`, an exception is thrown.
I removed this exception for the case that exactly one standard message (without explicit interval) is passed. In that case, this message is returned (just like from `trans()`). If the message key contains more than one message, or if the message has explicit intervals, the exception will still be thrown. See the tests for clarification.
A use case for why no exception should be thrown is validation:
```php
/**
* @Assert\Length(min=2, minMessage="Please enter at least two characters")
*/
```
Commits
-------
2b3dcb9 [Translation] Grammar fix
0951b8d [Translation] Fixed regression: When only one rule is passed to transChoice(), this rule should be used
This PR was merged into the 2.3 branch.
Discussion
----------
[2.3][Locale] Fixed: StubLocale::setDefault() throws no exception when "en" is passed
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Same as #8846 for 2.3+.
Commits
-------
e1f40f2 [Locale] Fixed: Locale::setDefault() throws no exception when "en" is passed
This PR was merged into the 2.2 branch.
Discussion
----------
[2.2][Locale] Fixed: StubLocale::setDefault() throws no exception when "en" is passed
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This is necessary to fix `IntlTestHelper::requireIntl()` when ICU is not installed and the Icu component 1.0.0 is used instead. In that case, `IntlTestHelper::requireIntl()` calls `\Locale::setDefault('en')` and fails. Consequently, the Form component test cases are partially red when running without ICU installed.
This PR fixes that.
Commits
-------
d0faf55 [Locale] Fixed: StubLocale::setDefault() throws no exception when "en" is passed
* 2.2:
fixed request format when forwarding a request
[HttpKernel] added a comment to warn about possible inconsistencies
added a functional test for locale handling in sub-requests
Fixed issue #6932 - Inconsistent locale handling in subrequests
fixed locale of sub-requests when explicitely set by the developer (refs #8821)
Conflicts:
src/Symfony/Component/HttpKernel/Tests/Fragment/InlineFragmentRendererTest.php
This PR was merged into the 2.2 branch.
Discussion
----------
fixed request format when forwarding a request
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6932
| License | MIT
| Doc PR | n/a
When calling forward() in a controller, the format is not the same as for the master request.
Commits
-------
7e87eb1 fixed request format when forwarding a request
This PR was merged into the 2.2 branch.
Discussion
----------
fixed locale management in sub-requests
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6932, #5532, #8604
| License | MIT
| Doc PR | n/a
Same fix as #8821 but for `_locale`, and a rebase of #8604.
Commits
-------
7117328 [HttpKernel] added a comment to warn about possible inconsistencies
c4636e1 added a functional test for locale handling in sub-requests
05fdb12 Fixed issue #6932 - Inconsistent locale handling in subrequests
b3c3159 fixed locale of sub-requests when explicitely set by the developer (refs #8821)
This PR was merged into the 2.3 branch.
Discussion
----------
[Form][2.3] Fixed Form::submit() and Form::setData() to react to dynamic form modifications
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
ref #3767, #3768, #4548, #8748
cc @Burgov
This PR ensures that fields that are added during the submission process of a form are submitted as well. For example:
```php
$builder = $this->createFormBuilder()
->add('country', 'choice', ...)
->getForm();
$builder->get('country')->addEventListener(FormEvents::POST_SUBMIT, function (FormEvent $event) {
$form = $event->getForm()->getParent();
$country = $event->getForm()->getData();
$form->add('province', 'choice', /* ... something with $country ... */);
});
```
Currently, the field "province" will not be submitted, because the submission loop uses `foreach`, which ignores changes in the underyling array.
Contrary to #8827 (for 2.2), this PR also allows dynamic modifications during `setData()`:
```php
$builder = $this->createFormBuilder()
->add('country', 'choice', ...)
->getForm();
$builder->get('country')->addEventListener(FormEvents::POST_SET_DATA, function (FormEvent $event) {
$form = $event->getForm()->getParent();
$country = $event->getData();
$form->add('province', 'choice', /* ... something with $country ... */);
});
```
For 2.2, this fix is not possible, because it would require changing the signature `DataMapperInterface::mapDataToForms($data, array $forms)` to `DataMapperInterface::mapDataToForms($data, array &$forms)`, which would be a BC break. For 2.3, this change is not necessary (instead of an array we now pass an iterator, which is passed by reference anyway).
Additionally, this PR ensures that `setData()` is called on *every* element of a form (except those inheriting their parent data) when `setData()` is called on the root element (i.e., during initialization). Currently, when some of the intermediate nodes (e.g. embedded forms) are submitted with an empty value, `setData()` won't be called on the nodes below (i.e. the fields of the embedded form) until `get*Data()` is called on them. If `getData()` is *not* called before `createView()`, any effects of `*_DATA` event listeners attached to those fields will not be visible in the view.
Commits
-------
7a34d96 Merge branch 'form-submit-2.2' into form-submit-2.3
cd27e1f [Form] Extracted ReferencingArrayIterator out of VirtualFormAwareIterator
3cb8a80 [Form] Added a test that ensures that setData() reacts to dynamic modifications of a form's children
07d14e5 [Form] Removed exception in Button::setData(): setData() is now always called for all elements in the form tree during the initialization of the tree
b9a3770 [Form] Removed call to deprecated method
878e27c Merge branch 'form-submit-2.2' into form-submit-2.3
ccaaedf [Form] PropertyPathMapper::mapDataToForms() *always* calls setData() on every child to ensure that all *_DATA events were fired when the initialization phase is over (except for virtual forms)
19b483f [Form] Removed superfluous reset() call
5d60a4f Merge branch 'form-submit-2.2' into form-submit-2.3
00bc270 [Form] Fixed: submit() reacts to dynamic modifications of the form children
This PR was merged into the 2.2 branch.
Discussion
----------
[Form][2.2] Fixed Form::submit() to react to dynamic form modifications
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
ref #3767, #3768, #4548, #8748
cc @Burgov
This PR ensures that fields that are added during the submission process of a form are submitted as well. For example:
```php
$builder = $this->createFormBuilder()
->add('country', 'choice', ...)
->getForm();
$builder->get('country')->addEventListener(FormEvents::POST_SUBMIT, function (FormEvent $event) {
$form = $event->getForm()->getParent();
$country = $event->getForm()->getData();
$form->add('province', 'choice', /* ... something with $country ... */);
});
```
Currently, the field "province" will not be submitted, because the submission loop uses `foreach`, which ignores changes in the underyling array.
Additionally, this PR ensures that `setData()` is called on *every* element of a form (except those inheriting their parent data) when `setData()` is called on the root element (i.e., during initialization). Currently, when some of the intermediate nodes (e.g. embedded forms) are submitted with an empty value, `setData()` won't be called on the nodes below (i.e. the fields of the embedded form) until `get*Data()` is called on them. If `getData()` is *not* called before `createView()`, any effects of `*_DATA` event listeners attached to those fields will not be visible in the view.
Commits
-------
cd27e1f [Form] Extracted ReferencingArrayIterator out of VirtualFormAwareIterator
ccaaedf [Form] PropertyPathMapper::mapDataToForms() *always* calls setData() on every child to ensure that all *_DATA events were fired when the initialization phase is over (except for virtual forms)
19b483f [Form] Removed superfluous reset() call
00bc270 [Form] Fixed: submit() reacts to dynamic modifications of the form children
This PR was squashed before being merged into the 2.2 branch (closes#8824).
Discussion
----------
[Yaml] Fix comment containing a colon on a scalar line being parsed as a hash.
| 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
Note: I only ran the Yaml Component tests.
This PR fixes a bug in YAML parsing where a comment containing a colon followed by a space, like this:
foo # warning: this is a scalar with a comment, not a hash
was parsed as a hash, resulting in:
array( 'foo # warning' => 'this is a scalar with a comment, not a hash' )
instead of:
'foo'
Commits
-------
4563f1b [Yaml] Fix comment containing a colon on a scalar line being parsed as a hash.
