symfony: Symfony : composer update 4.4.19 > 4.4.20 occures "The value array is not valid" when submitting form with entitytype.
Symfony version(s) affected: 4.4.2
Description After updating Symfony 4.4.19 to 4.4.20, some forms using Entitytype class - populated with json - give the following error when handling request :
The value array is not valid. | recipients | Caused by:
Symfony\Component\Form\Exception\TransformationFailedException {#6790 ▼
-invalidMessage: null
-invalidMessageParameters: []
#message: "The choices "XXXX" do not exist in the choice list."
#code: 0
#file: "/project/vendor/symfony/form/Extension/Core/Type/ChoiceType.php"
#line: 183
trace: {▼
/project/vendor/symfony/form/Extension/Core/Type/ChoiceType.php:183 {▶}
/project/vendor/symfony/event-dispatcher/EventDispatcher.php:264 {▶}
/project/vendor/symfony/event-dispatcher/EventDispatcher.php:239 {▶}
/project/vendor/symfony/event-dispatcher/EventDispatcher.php:73 {▶}
/project/vendor/symfony/event-dispatcher/ImmutableEventDispatcher.php:44 {▶}
/project/vendor/symfony/form/Form.php:671 {▶}
/project/vendor/symfony/form/Form.php:579 {▶}
/project/vendor/symfony/form/Extension/HttpFoundation/HttpFoundationRequestHandler.php:109 {▶}
/project/vendor/symfony/form/Form.php:493 {▶}
...
It works perfectly with SF 4.4.19.
Regards,
How to reproduce
- Juste create a simple form with an empty choice list:
$form = $this->createFormBuilder()
->add('recipients', EntityType::class, [
'class' => MyEntity::class,
'translation_domain' => 'mytranslation_domain',
'choice_label' => 'choice_label',
'label' => 'em.texts.to',
'multiple' => true,
'mapped' => true,
'choices' => $mychoices
]);
-
print in a twig using select2 lib
-
populate with a json request, make a choice and submit
Possible Solution Patching src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php ?
Additional context
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 38 (18 by maintainers)
I’ve been having the same issue for a while, so my 2 cents for the discussion (and why I think this issue can be closed).
The behaviour before 4.4.20 was quite convenient as it helped to extend
ChoiceTypeto build, for instance, an AJAX picker (what I was doing). In that way the #39659 bugfix, caused quite a mess in my project (and I would guess many - I suspect many issues, such as #41356, are related).In the end, I believe it is correct for
ChoiceTypeto validate that selected choices are indeed part ofchoices.So, I think there’s nothing to fix here anymore, though I can see that making a more flexible
ChoiceTypewould be great (maybe something that would also help with #39165, dynamic choices and options all the way).So here’s a detailed workaround for whoever have the issue, to make a custom form type work :
ChoiceTypeanymore (butFormTypeor nothing at all) - doing so, you will have to handle a bit more logic (code snippet below)compoundoption (cf. snippet P1)buildView()you have to copy a bit of code (cf. snippet P2)choice_widgetfor instance)multipleandplaceholderoptions to the view (cf. snippet P3)ArrayCollectionon top of arrays, you have to addMergeCollectionListener(cf. snippet P4)With those tweaks, the rest of you custom code should work with Symfony 5.2.4+ (or 4.4.20+)
The snippet:
that’s why I said the
PRE_SUBMITof the parent, where you can still replace the child with a new field using the ChoiceType (with different options.@xabbuh Ok i do it soon