There seems to be a serous bug with the radio button element. Repeat groups in one of the forms in my project are pulling up values cloned from the last repeat group - rather than null/blank values. (There also seems to be an issue with ajax and editing the configuration lists in the admin backend... keep reading)
Just to assure it isn't 'just me' or some bugs I might have introduced with my javascript, template tweaks, or css - this morning I changed the template to use the standard Fabrik bootstrap template. Still - the same issues.
To explain - When I add a new group to a form with repeat groups this is what the new repeat group looked like...
field (text) - clones values of last group
databasejoin - clones values of last group
radio button - blank (doesn't show default)
checkbox - clones values of last group
text area - OK (blank as expected)
Out of the 5 different element types I am using in that form, only the 'textarea' element show as expected.
So I created a basic test form with test elements and a joined table allowing repeated joins. I had similar results. (See attachments)
However, in that test table, I had put the field(text) before the checkboxes, radiobuttons, and dbjoin elements - and noticed that in that case the field(text) element in the newly added repeat group was blank - yet the value of the textarea was a clone of the last repeqat group added. The reverse of the way it was in my form. Hmmm.
So I decided to move both text elements before the checkboxes, radiobuttons, and dbjoin element. (to touch on the other bug?) Initially no matter how many times I tried - using the Joomla drag/drop method to change the order - the changed element order was not reflected in the form even though it appeared in the order I wanted in the elements list on the backend. I had to edit the element itself and change the 'Order' in the Details section of the element configuration form before I finally got that to display in the order expected on the frontend. (Not sure if that's a Joomla bug or Fabrik- but the 'quirk' only seems to occur with edits to the Fabrik comoponent.)
Anyhow - after I did that, both the textarea and the field(text) element were behaving as expected - ie. blank when a new group was added.
So right away I figured it was something in one of those elements "in-between" the original order that was causing the bug.
So I added another text element after those suspect problem elements - just to prove the point. And sure enough that newly added field(text) element, when ordered after the radiobutton, was cloning the value from the previous group rather than appearing as blank. (see attachment add_with_radio.png)
Then I started going through all the 'suspects'. I first disabled the radio button (since that was the 1st one not 'behaving' properly - and again I had to edit the element and change the 'Published' option - because the changes made from the list to Unpublish did not 'take' (even though they apperaed correctly with a red X in the list).
Once I disabled the radio button - everything worked correctly. (See attachment - add_without_radio.png)
I have also included a screenshot of the javascript fatal error from firebug that shows when a radiobutton is included in a repeat group. (js_radio_error.png)
Going through that debugging proved myself wrong - I suspected all along it was the databasejoin element. So my recent trashing of the databasejoin element in this forum - insisting it is broken - may all be related to the use of a radio button in thoise forms ahead of the databsejoin element. And just maybe the datbasejoin element is not as 'broken' as I thought.
CONCLUSION: There is a bug in the radio button element plugin that will trash all elements following the use of it in any form that uses repeat groups.
Also, as I hit upon in my detailed explanation of my morning activities - there has been something 'goofy' going on with the ajax routine in Fabrik when editing any of the Fabrik options on the backend that (using the 'Joomla-style' list to select items to edit, reorder, 'display in list', publish/unpublish, etc.). Any changes made via any of those ajax-controlled settings do not take affect. You MUST edit the item in the list and change those values (order, published, show in list, etc.) from within the edit form - then save - then check-in the item before it actually takes.
Similar issues occur for me if using the inline-edit list plugin. The plugin seems to work fine - but the table is never really updated with changes made. I really have a feeling all these issues I've been reported are related to the same ajax issue.
I just got to thinking that I have always had issues with ajax in Fabrik. And some other people have similar complaints. Yet not everyone. I wonder if what those of us who have issues with ajax have in common is the fact that we updated Fabrik from 2.5 to 3.0? - even though the migration was not 'recomended' at the time. If any of the Fabrik development team reads this - do you think that could be part of my long-standing ajax/javascript problems? If so, do you think it can be fixed without doing a clean install of 3.x and starting my project from scratch. Because I'm about ready to give up on this project altogether.
Just to assure it isn't 'just me' or some bugs I might have introduced with my javascript, template tweaks, or css - this morning I changed the template to use the standard Fabrik bootstrap template. Still - the same issues.
To explain - When I add a new group to a form with repeat groups this is what the new repeat group looked like...
field (text) - clones values of last group
databasejoin - clones values of last group
radio button - blank (doesn't show default)
checkbox - clones values of last group
text area - OK (blank as expected)
Out of the 5 different element types I am using in that form, only the 'textarea' element show as expected.
So I created a basic test form with test elements and a joined table allowing repeated joins. I had similar results. (See attachments)
However, in that test table, I had put the field(text) before the checkboxes, radiobuttons, and dbjoin elements - and noticed that in that case the field(text) element in the newly added repeat group was blank - yet the value of the textarea was a clone of the last repeqat group added. The reverse of the way it was in my form. Hmmm.
So I decided to move both text elements before the checkboxes, radiobuttons, and dbjoin element. (to touch on the other bug?) Initially no matter how many times I tried - using the Joomla drag/drop method to change the order - the changed element order was not reflected in the form even though it appeared in the order I wanted in the elements list on the backend. I had to edit the element itself and change the 'Order' in the Details section of the element configuration form before I finally got that to display in the order expected on the frontend. (Not sure if that's a Joomla bug or Fabrik- but the 'quirk' only seems to occur with edits to the Fabrik comoponent.)
Anyhow - after I did that, both the textarea and the field(text) element were behaving as expected - ie. blank when a new group was added.
So right away I figured it was something in one of those elements "in-between" the original order that was causing the bug.
So I added another text element after those suspect problem elements - just to prove the point. And sure enough that newly added field(text) element, when ordered after the radiobutton, was cloning the value from the previous group rather than appearing as blank. (see attachment add_with_radio.png)
Then I started going through all the 'suspects'. I first disabled the radio button (since that was the 1st one not 'behaving' properly - and again I had to edit the element and change the 'Published' option - because the changes made from the list to Unpublish did not 'take' (even though they apperaed correctly with a red X in the list).
Once I disabled the radio button - everything worked correctly. (See attachment - add_without_radio.png)
I have also included a screenshot of the javascript fatal error from firebug that shows when a radiobutton is included in a repeat group. (js_radio_error.png)
Going through that debugging proved myself wrong - I suspected all along it was the databasejoin element. So my recent trashing of the databasejoin element in this forum - insisting it is broken - may all be related to the use of a radio button in thoise forms ahead of the databsejoin element. And just maybe the datbasejoin element is not as 'broken' as I thought.
CONCLUSION: There is a bug in the radio button element plugin that will trash all elements following the use of it in any form that uses repeat groups.
Also, as I hit upon in my detailed explanation of my morning activities - there has been something 'goofy' going on with the ajax routine in Fabrik when editing any of the Fabrik options on the backend that (using the 'Joomla-style' list to select items to edit, reorder, 'display in list', publish/unpublish, etc.). Any changes made via any of those ajax-controlled settings do not take affect. You MUST edit the item in the list and change those values (order, published, show in list, etc.) from within the edit form - then save - then check-in the item before it actually takes.
Similar issues occur for me if using the inline-edit list plugin. The plugin seems to work fine - but the table is never really updated with changes made. I really have a feeling all these issues I've been reported are related to the same ajax issue.
I just got to thinking that I have always had issues with ajax in Fabrik. And some other people have similar complaints. Yet not everyone. I wonder if what those of us who have issues with ajax have in common is the fact that we updated Fabrik from 2.5 to 3.0? - even though the migration was not 'recomended' at the time. If any of the Fabrik development team reads this - do you think that could be part of my long-standing ajax/javascript problems? If so, do you think it can be fixed without doing a clean install of 3.x and starting my project from scratch. Because I'm about ready to give up on this project altogether.