• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Weird bug with radio button - and repeat groups

Bauer

Well-Known Member
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.
 

Attachments

  • test_form.PNG
    test_form.PNG
    32.3 KB · Views: 528
  • add_with_radio.PNG
    add_with_radio.PNG
    39.7 KB · Views: 540
  • add_without_radio.PNG
    add_without_radio.PNG
    34 KB · Views: 533
  • js_radio_error.PNG
    js_radio_error.PNG
    31.8 KB · Views: 508
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:
        // 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:
        // 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.
 
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?
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top