Yeah good point. Fixed!

Thank you @Thorry84.

@Thorry84

Not sure how exactly, but this fix has crashed some functionality on my sites.
It now throws a Entity has to be managed or scheduled for removal for single computation error since entities loaded in the forms are no longer managed by ORM's Unit of Work.

It's not a bug report, just wanted to let you know it's a possible BC though.

Hmmm that's not good. I'm not sure how my changes could be a BC break.

However the previous implementation was inherently broken. As I pointed out the example given in the blog post was simply not possible. So in the past the functionality not working might have masked any issues with unmanaged entities.

As far as I can see I don't know of any way the ResizeFormListener could cause Entities to become unmanaged. I would suspect an issue with the wrong transformers being applied to the form fields?

If you have any code to share I would love to help you investigate the issue.

@Thorry84

It must have been because I used an unmanaged empty Doctrine entity as prototype data

        $builder->add('items', CollectionType::class, [
            'entry_type' => ItemType::class,
            'allow_add' => true,
            'by_reference' => true,
            'label' => false,
            'prototype' => true,
            'prototype_data' => new ItemEntity(),
        ]);

In 6.2.7, the empty detached entity was used only for prototyping. The ResizeFormListener's options looked like

array:1 [▼
  "block_name" => "entry"
]

But now, in 6.2.8, the $prototypeOptions used instead of $options, looks this way:

array:4 [▼
  "required" => true
  "label" => "__name__label__"
  "block_name" => "entry"
  "data" => App\Entity\ItemEntity
]

So the blank detached entity comes into play instead of being discarded as before.

In other words - does it make sense to use prototype data for populating new collection elements rather than only for prototyping? And even if so, it has not been used until 6.2.8, which seems to be an explicit BC.

That explains the error you've been getting.

In my opinion the previous behavior where all the options were discarded was incorrect. So passing along the options to the new fields is a bug fix and not a BC break.

However the prototype_data field is maybe an exception to this rule. Would someone expect new fields to be populated with data?

Discussions about this in the past I've been able to find point out the data is for initialization only and not on submit. However in the past when passing data to options this would be applied to new fields, which is incorrect in my opinion. Applying the prototype_data would make more sense than applying data.

So I'm not really sure if this would be considered a BC break or a bugfix? Either case sounds valid to me.
My 2 cents is that this is a bugfix.

In your code, why isn't the new data handled? If there are new entries in the form, there are new entities to be persisted?

In your code, why isn't the new data handled? If there are new entries in the form, there are new entities to be persisted?

The actual entities are loaded by ID from a repository first in a preSubmit hook, and only then updated.
So there's no need to persist them, since all the entities are existing, not new. I.e. the collection is used for updating records, not adding.

In my opinion the previous behavior where all the options were discarded was incorrect. So passing along the options to the new fields is a bug fix and not a BC break.

Ok, no problem, I just wanted you to be aware of that possible issue.
Anyway, thank you for adding new features!

Thanks for letting me know. Happy to help :)

If somebody comes across this issue from Google: It doesn't work for the use case stated in the blog and my fix didn't solve the issue fully for that use case.

The problem is, the prototype options are used for new fields, but only when creating new fields in the UI. So when you have a form, you can disable fields for existing data and have new fields available. This part now works with my fix, but whenever there is a validation error in the form, the submitted data is seen as "old" data and the fields are now disabled. This means the user can't even fix the validation errors and is in a sense soft-locked.

So even though the fix did technically fix the functionality, the supposed use-case simply isn't possible using only this feature. YMMV

Tagging @javiereguiluz to maybe edit the blog post to point this out.