This PR was merged into the 2.3 branch.
Discussion
----------
[2.3][Form] Check if IntlDateFormatter constructor returned a valid object before using it
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
`IntlDateFormatter` constructor [may return false](http://www.php.net/manual/en/intldateformatter.create.php#refsect1-intldateformatter.create-returnvalues). This patches avoids fatal errors in these cases
This PR replaces #11334
Commits
-------
ebf967d [Form] Check if IntlDateFormatter constructor returned a valid object before using it
This PR was squashed before being merged into the 2.3 branch (closes#10777).
Discussion
----------
[Form] Automatically add step attribute to HTML5 time widgets to display seconds if needed
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #9976, #10203
| License | MIT
| Doc PR | none
Same issue as #9976 and #10203: when you add a `time` field to a form with options `single_text` (so HTML5) and `with_seconds`, the generated input does not contain the `step` attribute, therefore the browser does not show them, leading to an error at the submit because of an invalid format.
Compared to #9976/#10203:
* Unit testable
* Available directly in the component
* Available in other templating format than twig
* Still able to customise the step attribute by hand
Commits
-------
a379298 [Form] Automatically add step attribute to HTML5 time widgets to display seconds if needed
This PR was merged into the 2.3 branch.
Discussion
----------
unified return null usages
| Q | A
| ------------- | ---
| License | MIT
This PR unifies the way we return `null` from a function or method:
* always use `return;` instead of `return null;` (the current code base uses both);
* never use `return;` at the end of a function/method.
Commits
-------
d1d569b unified return null usages
This PR was merged into the 2.3 branch.
Discussion
----------
made {@inheritdoc} annotations consistent across the board
| Q | A
| ------------- | ---
| License | MIT
Commits
-------
810b9ed made {@inheritdoc} annotations consistent across the board
This PR was squashed before being merged into the 2.3 branch (closes#10410).
Discussion
----------
[Form] Fix "Array was modified outside object" in ResizeFormListener.
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #10405
| License | MIT
| Doc PR |
This is the second pull request for this issue. The history of this is as follows:
Original Fix was added Feb 11th under Pull Request #10232.
Users began complaining of Doctrine ArrayCollection not being updated in forms.
Revert was added Feb 15th under Pull Request #10269.
Issue #10405 was opened on 7th Mar for the original bug.
Pull Request #10269 has a failing test that illustrates users concerns.
I have added failing tests to this pull request to illustrate the problems described in #10405.
All tests now pass, and all forms of $data are now supported, including arrays, DoctrineCollection, ArrayObject, and other IteratorAggregates.
__Details as follows:__
The onSubmit() method of the ResizeFormListener class is assuming the data is an array, and calling unset directly inside a foreach. This works fine in most scenarios, but if data is an instance of IteratorAggregate that is iterating over $data by reference, it breaks with the following error:
Symfony\Component\Form\Extension\Core\EventListener\ResizeFormListener::onSubmit(): ArrayIterator::next(): Array was modified outside object and internal position is no longer valid in ./vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Core/EventListener/ResizeFormListener.php line 142
This is because the foreach loop is using an Iterator in the background, but the ResizeFormListener has unset the underlying data directly, causing the value that the Iterators internal pointer is pointing to to change.
The Iterator provided by IteratorAggregate may or may not have the ability to modify it's underlying data. So it is not possible to rely on the Iterator to modify the data. Instead, it is simpler to avoid modifying $data at all while we are iterating over it. So instead, we simply iterate over $data once to determine the keys we need to delete, and store them. Then we iterate over the keys and delete them from $data.
Commits
-------
aa63fae [Form] Fix "Array was modified outside object" in ResizeFormListener.
This PR was squashed before being merged into the 2.3 branch (closes#10251).
Discussion
----------
[Form][2.3] Fixes empty file-inputs getting treated as extra field.
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #8575 (https://github.com/symfony/symfony/pull/8575#issuecomment-34867485)
| License | MIT
Re-applies 968fe23 (PR #8575).
The test for this already exists, it was just this line that got overwritten by eb9f76d5ba (diff-ca5e25b47f3ecc94cd557946aeb486c6L542)
To clarify, this is a PR into 2.3 branch - this already exists in 2.4 (and later from this PR: https://github.com/symfony/symfony/pull/9146)
Commits
-------
8d99d75 [Form][2.3] Fixes empty file-inputs getting treated as extra field.
The onSubmit() method of the ResizeFormListener class is assuming the data is an array, and calling unset directly inside a foreach. This works fine in most scenarios, but if data is an instance of IteratorAggregate, it breaks with the following error:
Symfony\Component\Form\Extension\Core\EventListener\ResizeFormListener::onSubmit(): ArrayIterator::next(): Array was modified outside object and internal position is no longer valid in ./vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Core/EventListener/ResizeFormListener.php line 142
This is because the foreach loop is using an Iterator in the background, but the ResizeFormListener has unset the underlying data directly, causing the Iterator and data to be out of sync. When the data is an instance of IteratorAggregate, the loop should use the iterator directly and not rely on foreach.
The onSubmit method has been updated accordingly.
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
When replacing a child form from within a form event, it's not obvious that you have to use the 'add' method. Though it's minor, this will save somebody a google search.
