1. Fabrik 3.8.1 has been released. It is mostly bug fixes and feature enhancements, but does include two new plugins (push notifications, and the sequence element). As usual we strongly recommend testing the new release on a sandbox if your application is mission critical, and always do an Akeeba backup before updating.
    Dismiss Notice

Weird bug with radio button - and repeat groups

Discussion in 'Community' started by Bauer, Apr 13, 2014.

  1. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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.
     

    Attached Files:

  2. Bauer

    Bauer Well-Known Member

    Level: Supporter
    Ok - since I don't give up easy - I looked further into this...

    The problem lies in the plugins/fabrik_element/radiobutton/radiobutton-min.js file (as that error in the screen shot I provided indicates) There was some recent code added at line 84 (of the non-minified version) to handle Protostar in J3.2

    However a radio button is not created using bootstrap classes unless the radio button element was configured as such (via the 'Button group' Yes/No selector at the bottom of the element's 'Details' section in the configuration form). That is what causes the error. The js code is now trying to add/change the bootstrap classes without first checking to see if the element has been configured as a (graphical) button group.

    Now that I've done the legwork on debugging this issue, this is a simple easy fix - if someone would please make the change and commits for me at Github I'd appreciate it. It's just a matter of wrapping an 'if (label)' condition around the code that changes the bootstrap classes used when 'Button group' is set to Yes.

    I.e. Change this section beginning at line 84 in radiobutton.js from...

    Code (Text):
            // Protostar in J3.2 adds its own btn-group js code - need to thus apply this section even after input has been unchecked
            if (!input.get('checked') || fabchecked === 1) {
              label.getParent('.btn-group').getElements('label').removeClass('active').removeClass('btn-success').removeClass('btn-danger').removeClass('btn-primary');
              if (v === '') {
                  label.addClass('active btn-primary');
              } else if (v.toInt() === 0) {
                  label.addClass('active btn-danger');
              } else {
                  label.addClass('active btn-success');
              }
                input.set('checked', true);
         
                if (typeOf(fabchecked) === 'null') {
                    input.set('fabchecked', 1);
                }
            }
    to...

    Code (Text):
            // Protostar in J3.2 adds its own btn-group js code - need to thus apply this section even after input has been unchecked
            if (!input.get('checked') || fabchecked === 1) {
                if (label){        
                    label.getParent('.btn-group').getElements('label').removeClass('active').removeClass('btn-success').removeClass('btn-danger').removeClass('btn-primary');
                    if (v === '') {
                        label.addClass('active btn-primary');
                    } else if (v.toInt() === 0) {
                        label.addClass('active btn-danger');
                    } else {
                        label.addClass('active btn-success');
                    }
                }
                input.set('checked', true);
     
                if (typeOf(fabchecked) === 'null') {
                    input.set('fabchecked', 1);
                }
            }
    I've already tested the change - and now everything works fine - including the default being marked as 'checked'. And because the javascript no longer farts out with a fatal error at that point, my form is being generated as expected.

    So, until someone can fix this - I just renamed the radiobutton-min.js file to radiobutton-min.js.SAV
    then renamed the radiobutton.js file to radiobutton-min.js and edited the file with the change code as shown above.

    Thank You in advance - to whoever fixes this.
     
    troester likes this.
  3. troester

    troester Administrator Staff Member

    Level: Community
    I can confirm: after modifying the code it's working on my site, too.
     
  4. Sophist

    Sophist Well-Known Member

    Level: Community
    Well done mate. I knew you could do it!!
     
  5. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
  6. Bauer

    Bauer Well-Known Member

    Level: Supporter
    Thanks for the kudos, guys. No problem sharing my finds.
    But now I'm not so sure things are 100% kosher - and just not sure yet if it's from the latest update or something I'm doing in javascript, or because of my custom form template.

    Now - when I add a new repeat group - the only part of the HTML that reflects the new index# (after the ajax refresh) is the one for the 'input' id tag of the element itself. All the rest of the class names (that have the index# appended on to the end of the class name) are just cloning the index# from the last group. Once the form is submitted and re-edited the correct index# is shown in both the input id and the surrounding DIV containers in the HTML.

    BUT, upon re-edit of the form the index number for the last added group always becomes zero - and the older groups index is incremented. So the display of the joined groups has moved from the last added group at the bottom to the last added group on top. Not sure if this is a change made with Fabrik - or if it should be considered a feature or a bug. I do know that Excel does a similar thing when adding a new sheet to workbook. The new worksheet index is always zero - and the existing sheet indexes get 'bumped up' one.

    Can anyone tell me if this was an intended change - or if the same thing is happening for them?
     

Share This Page