[Resolved] Cred Conditional Groups Don't Seem to Work in Modals

[Author]

Posts

[Dave]

I am trying to:
Use an edit form to update post content. Part of that edit form is hidden by a conditional group that can be opened and closed using a checkbox.

Link to a page where the issue can be seen:
hidden link (Click on Edit link and then scroll down to Amenities)

I expected to see:
The fields were shown or hidden depending on the checkbox status.

Instead, I got:
The conditional group loaded in whatever state correlated to the stored checkbox status and changing it live has no affect.

It should be known that this conditional group works perfectly out of a modal.

[Jamal]

Hello and thank you for contacting Toolset support.

Well, the issue is not because the form is inside a modal. Otherwise, why does the modal for "New Gym" works!
It is because the view, the table layout, is loaded again through AJAX. In the first load, Toolset initializes correctly the forms. But, then they get overridden by the results of an AJAX request.

This will be apparent, once you activate AJAX search or AJAX pagination.

Currently, the Toolset forms code does not initialize correctly the forms that are not yet loaded(AJAX). And it does not have a proper JS API for archive pages.

We can only work around it with custom Javascript depending on each case. For this case, I come up with the following code that listens for the modal show event and makes sure that the conditional group will work as expected. However, that was not enough because we cannot tell when the AJAX reload of the table happens, so I am running the code in an interval of 2 seconds( 2* 1000)

// define our handler in the global scope.
function handleConditionalGroupDisplay(modal){
    var $modal = jQuery(modal);
    $modal.find('input[data-wpt-name="wpcf-gym-enable-amenities"]').off('change').on('change', function(){
      var checkbox = jQuery(this);
      var form = jQuery(this.form)
      var group = form.find('.cred-group')

      // reset forms styles
      group.find('.js-wpt-field-items').removeAttr('style');

      // test checkbox value
      if ( checkbox.is(':checked') ){
        // show the group
        group.removeClass('wpt-conditional-hidden').addClass('wpt-conditional-visible').show()
        // enable the checkboxes
        group.find('input').removeAttr('disabled')
      } else {
        // hide the group
        group.removeClass('wpt-conditional-visible').addClass('wpt-conditional-hidden').hide()
        // disable the checkboxes
        group.find('input').attr('disabled', "")
      }
    }).trigger('change')
  }

(function($){
  function handleModalShow(){
    $('.modal').off('show.bs.modal').on('show.bs.modal', function (e) {
      handleConditionalGroupDisplay(e.currentTarget);
    })
  }
  setInterval( handleModalShow, 2 * 1000)
})( jQuery )

I hope this helps. Let me know if you have any questions.

[Dave]

I totally missed that the New Gym form was working! For some reason I was convinced it wasn't, probably after staring at the issue for too long.

Ok, so please check me that I'm understanding you correctly here. Is the issue due to the View, the use of a table layout, or the fact that it is on an archive page? You kind of imply that it's all of them at different points in your answer. Obviously if the archive page is the main issue I can simply rebuild the same basic thing with a view on a normal page, but if it's the view or the table layout, that's a bigger issue in the long run.

That code does indeed work, thank you. But won't having that run so frequently impact browser performance? Also, what specifically would trigger an AJAX reload? Is it just when someone interacts with the results in some way or is it something that will be triggered behind the scenes and as such can't be tied to user interactions?

Two follow up questions as well please:

Is any of that jQuery using Toolset specific hooks, functions or calls etc? If so, is there a reference page for it like with all your PHP hooks?

If I could suggest something I've mentioned in another support thread, but I think has largely been ignored. There seems to be a lot of small issues and quirks to how modals work with Toolset. Most of the support tickets I've had to raise have been in relation to modals, such as this one. It would be a huge help and probably benefit a lot of users if you could compile a documentation page consisting of a user guide / best practises / limitations etc of using modals to help guide people through how they can and can't be implemented with Toolset. Might save a lot of support time in the long run, and give you a place to document issues like this one.

[Jamal]

Well, I don't think the modal has anything to do with this issue. The issue will always happen with forms that are loaded through AJAX. Simply, because the Toolset Forms Javascript code will run on the first page load. Any for that gets loaded through AJAX will present such an issue.

Honestly, I don't know what is causing the AJAX reloading of the initial results. I suspect a combination of Archive+Sorted table. But, I can't tell if the table was created to be sorted by the table headers. The user interface cannot tell now. It's a feature that is offered when creating the layout for the first time. I searched our internal issues tracking tool for a similar case, but could not find anything.
You may consider rebuilding the archive template and use a table that has no frontend sorting.

I do agree, running the Javascript code at intervals will impact the browser performance. But, the code is not really heavy. I don't think anyone will notice this impact, unless it is, for example, an old mobile phone, with low memory.
You can also adapt the code so it is run when a modal is opened, instead of running it at intervals. I did not invest more time there because custom code is out of the scope of support. My code is rather an example of how to fix the issue, than a final solution.
https://toolset.com/toolset-support-policy/

Regarding your follow-up questions:
- We do have an article about AJAX views, but it is not relevant in the context of archive templates https://toolset.com/documentation/programmer-reference/adding-custom-javascript-code-to-views-that-use-ajax/
- As I don't think this issue is tightly linked with modals, there will be no need to invest any efforts about it. You can always ask for features or documentation on this form https://toolset.com/contact-us/suggest-a-new-feature-for-toolset/

This being said, I'll remain at your disposal for anything else(question, bug report).

[Dave]

The way you've answered my last post has honestly left me a bit confused and a little put out somewhat. I'll step through your response and highlight what I mean:

"Well, I don't think the modal has anything to do with this issue."

I did not mention modals in my response at all. You made it clear initially that the modal isn't the issue, it's an AJAX loading issue, which I could not possibly be aware of from it's behaviour and the lack of errors. We have established this, hence I asked which of the other three components you mentioned is the cause of the issue so I can try and learn from this.

"Honestly, I don't know what is causing the AJAX reloading of the initial results. I suspect a combination of Archive+Sorted table. But, I can't tell if the table was created to be sorted by the table headers."

These are not Toolset sorted tables, this should be clear from the lack of tags Toolset requires in the TR headers. The sorting is being handled by an seperate JS plugin called Footable, which has been mentioned and recommended in your forums and support threads numerous times. So, based on your list, all this is a problem with the table layout itself. How can this be the case? Surely this implies that the table layout is inherently broken in regards to AJAX? Either way, it's not performing as it realistically should, so that surely counts as a bug, even if the modal isn't the cause?

"I did not invest more time there because custom code is out of the scope of support. My code is rather an example of how to fix the issue, than a final solution."

I appreciate that this is only an example, but your support threads are full of supporters going to great lengths to help your customers. And whilst I'm not complaining that you didn't write a full solution to this problem, this does read as a pretty dismissive way of saying this. The 30 extra seconds it took you to write that, you could have just as easily said "oh, try tying it to this method or function to make it run when the modal loads". That would have been an infinitely better and more customer focused approach to take.

"- We do have an article about AJAX views, but it is not relevant in the context of archive templates"

As you say, it's not relevant and doesn't go into any information that is useful to this context at all, so why mention it? An example or list of front end events that are relevant to Archives would have been far more helpful. Or simply tell me that archives cannot achieve this and recommend I scrap it and use a View, as I previously asked if should be done.

"- As I don't think this issue is tightly linked with modals, there will be no need to invest any efforts about it"

Ok, we've established that the modal isn't directly the cause here, simply showing a symptom. But my point still stands that you get a lot of questions, tickets and issues surrounding modals and documentation concerning their usage would go a long way for a lot of users. Telling me there's "no need to invest any effort" in it is frankly verging on rude. Simply passing the feedback on would have been more than enough in this situation.

This all being said, you have answered the initial query and it is functional, so I will close the ticket. But I wanted to lay this out because a few simple changes would have gone a long way here.