Hi,
I had an issue for gin 3.0.0-alpha37 where I had a content-type that contained 2 select boxes. The options of the second select box were populated based on the selected value of the first box. This was done via ajax, however it seemed that selecting an option in the first select box would generate a new form-id which broke the usage of an ‘external’ submit button that was located outside of the form.
I managed to fix this by storing the ‘previous’ form ID in the ginEditForm behaviour’s attach function. The next time the attach function was called, when my form’s current id would no longer match the previous form id, I would update the id on the external submit button.
Below I provided the patch that fixed this issue for me.
I do recognise that this might not be an issue in gin as I can not properly replicate this with a fresh setup, but I am still creating this in case it is of help to someone or someone can shed more light on this.
I’ll try to put more time into finding the exact issue here and replicating it, but for now all I can do is provide a patch and an issue summary.
TODO
'I managed to fix this by storing the ‘previous’ form ID in the ginEditForm behaviour’s attach function. The next time the attach function was called, when my form’s current id would no longer match the previous form id, I would update the id on the external submit button.'
Replicate this issue.
Closed: duplicate
3.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Can you check if this 🐛 Ajax behaviour on entity edit form action buttons can break Needs work actually solves this issue as well?
Closing this in favor of 🐛 Ajax behaviour on entity edit form action buttons can break Needs work