This PR was merged into the 2.3 branch.
Discussion
----------
[Form] fix form handling with OPTIONS request method
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #8282
| License | MIT
| Doc PR | -
The OPTIONS request is just handled as any other request method. And accoring to the spec, an options request can also contain a request body like a POST. This only applied when using the deprecated form processing with `$form->submit($request)`. The change also makes the handling consistent with the `handleRequest` behavior via https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/HttpFoundation/HttpFoundationRequestHandler.php
Commits
-------
28eabd8 [Form] fix form handling with unconventional request methods like OPTIONS
This PR was merged into the 2.3 branch.
Discussion
----------
[Validator] Simplified testing of violations
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I simplified the assertion of violations in preparation of a replacement PR for #7276.
Commits
-------
8e5537b [Validator] Simplified testing of violations
This PR was merged into the 2.3 branch.
Discussion
----------
[Form] Fixed ValidatorTypeGuesser to guess properties without constraints not to be required
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6645
| License | MIT
| Doc PR | -
Consider the following entity:
```php
class Author
{
/**
* @Assert\NotBlank
*/
private $name;
private $age;
}
```
Right now, the "required" HTML attribute is set for both fields (since the default value of the "required" option is true). IMO this is wrong.
With this fix, the ValidatorTypeGuesser guesses `false` for the "required" option unless a NotNull/NotBlank constraint is present.
Commits
-------
fd77b09 [Form] Fixed ValidatorTypeGuesser to guess properties without constraints not to be required
This PR was squashed before being merged into the 2.3 branch (closes#11340).
Discussion
----------
[2.3] Add missing development dependencies
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
I've also added a run of the test suite in every component scope.
Commits
-------
3b02af9 [2.3] Add missing development dependencies
This PR was merged into the 2.3 branch.
Discussion
----------
[Form][Validator] All index items after children are to be considered grand-children when resolving ViolationPath
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | unsure, see note below
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #11458
| License | MIT
| Doc PR | -
#### Possible BC Break
The old behavior had unit test cases specifically testing the case of a grand-children form. However, this behavior is not documented anywhere and the fix seems to have no adverse effects on form validation. `Symfony\Component\Form\FormInterface` implements `ArrayAccess`, therefore, semantically speaking, `children[direct_child].children[grand_children]` and `children[direct_child][grand_children]` are equivalent. `offsetGet` is expected to fetch an element from `children`. I do not see why both were not considered equivalent when resolving the ViolationPath.
This commit will indeed change how some errors are mapped. However since the old mapping is (in my opinion) a bug...
Commits
-------
c64a75f [Form][Validator] All index items after children are to be considered grand-children when resolving ViolationPath (fixes#11458)
This PR was merged into the 2.3 branch.
Discussion
----------
fix some docblocks
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Commits
-------
1775da5 fix some docblocks
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
