Timeline for Is there a way to add / remove items from an unlimited cardinality field in form alter / after build?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 2, 2023 at 17:44 | vote | accept | brad.bulger | ||
| Dec 29, 2022 at 19:38 | comment | added | 4uk4 | As said, you don't have to worry. For the form logic this is not relevant, only if you do other things not connected to the form. | |
| Dec 29, 2022 at 18:16 | comment | added | brad.bulger | Right, the ajax action is a new request. So it's the form being cached that is making the difference, OK. In the ajax call of the prepare hook, the form state has input values that match what was on the form, so I can use that to distinguish the two calls. | |
| Dec 29, 2022 at 18:00 | comment | added | 4uk4 | You don't have to worry about that, it's true that Drupal starts with caching Ajax forms only after the first Ajax action. Until then any code you write preparing and altering the entity form is executed at least two times, and has to produce every time the same result. After that the form object including the entity object is cached and modified on each submit. | |
| Dec 29, 2022 at 17:29 | comment | added | brad.bulger | Yes, this is interesting. The doc says "It is invoked just once when first building the entity form. Rebuilds will not trigger a new invocation." Apparently the entity form does get reconstructed if not officially "rebuilding" on the first ajax action (like the Add another button or an onChange event), but not thereafter. That's exactly the times when it is resetting the field items count from the entity, though, so changing the entity beforehand seems like it should solve that. | |
| Dec 29, 2022 at 7:30 | history | answered | 4uk4 | CC BY-SA 4.0 |