-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] ChoiceType undefined index issue when using $resolver->setNormalizer('choices', #17270
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
Comments
Did this work for you with any patch version of the 2.7 release? |
I have the same issue with Symfony version 2.8.1 |
It only occurs if you also have a choice field define before your custom type which use the If you changed the order I guess it has something to do with this comment a few lines before in ChoiceType, because the fields have some dependencies on each other. // Don't pass the labels by reference. We do want to create a
// copy here so that every form has an own version of that
// variable (contrary to the $choiceLabels object shared by all
// forms)
|
What do you mean with that? |
Look at the DefaultController in the example. If you remove $builder->add('choice', 'choice', array(
'choices' => array(
'1' => '1',
'2' => '2',
'3' => '3',
'4' => '4',
'5' => '5'
)
)); It works also if you change the order like that. $builder->add('choiceTwo', new ExampleChoiceType(), array(
'show_all' => false
));
$builder->add('choice', 'choice', array(
'choices' => array(
'1' => '1',
'2' => '2',
'3' => '3',
'4' => '4',
'5' => '5'
)
)); Please remind that i didn't try that with Rattler3 example, but on my issue that works before. I only transfer that behaviour i found to this example. |
Maybe @Rattler3 can confirm that behaviour. |
@xabbuh This worked in the previous version (2.7.7) also not working when I tested in 2.8.0. I can also confirm what @gseidel is saying. This only happens if both choice fields are present and the choice field with the setNormalizer is the second item. This can be seen in the example controller |
…is replaced (paradajozsef) This PR was squashed before being merged into the 2.7 branch (closes #17406). Discussion ---------- [Form] ChoiceType: Fix a notice when 'choices' normalizer is replaced | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #17270 | License | MIT | Doc PR | - As @gseidel [mentioned](#17270 (comment)), the notice only occurs, when a custom choice field added after a choice field **and** the custom type is expanded, **and** the ```'choices'``` normalizer is replaced. The problem is that when ```'choices'``` option is replaced, the [default choiceNormalizer](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L262) is not invoked. This normalizer would [clear](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L264) the labels from previous invocation, but it's been replaced in the custom choice type. As a result [$choiceLabel](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L279) normalizer will get the wrong labels because it shares the same scope with [$choiceNormalizer](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php#L262). Resetting the label values after copy solves this problem. Commits ------- be056fd [Form] ChoiceType: Fix a notice when 'choices' normalizer is replaced
In 2.7.8 using setNormalizer to update 'choices' in a Form causes the below error:
A new fork has been created to show this issue. This can be found here.
The text was updated successfully, but these errors were encountered: