• Fabrik V4.4.1 is now available.

    This version corrects the Admin issue introduced by V4.4. V4.4.1 is available through the Joomla Updater or for download through your My Downloads area of our website.

    Turns out a code change intended for our 5.0dev branch inadvertantly got pushed to the 4.x branch (by me, duh!). The javascript structure in 5.0 will change considerably and part of that change took effect with the inadvertant code change.

    We have reverted the code change and released 4.4.1. V4.4 has been retracted.

    Sorry for any inconvenience.

  • A new version of Full Calendar is now available.

    See the details here

Fixed Cascading Dropdown on Edit

davez

Member
I have a cascading dropdown which is not loading the saved data on edit. Is anyone else having this trouble?

I recreated the element just in case. Watch elements are set properly. It works fine on a new form.

Was working prior to my recent upgrade to Fabrik/Joomla 4.
 
Is the stored value a valid option on form load (i.e. the watched element showing the "correct" value)?
Any JS errors?
 
JS - All I'm getting is a Gantry error, but it's on the new form also:
main.js?65eb9b69:1 [Deprecation] Listener added for a synchronous 'DOMSubtreeModified' DOM Mutation Event...\
Watched values are correct.

When the edit form loads, the loading spinner does not initiate. If I rselect the watched element and re-select the set watched option, the cascadingDD element does show the list of items.
 
Tried Cassiopeia. Still not loading. It's as if the JS isn't firing that loads the cascading element. But I'm not sure where to dig for that.
 
I found another clue. The failed one is a menu form which sets the user_id by setting the row_id to -1.

The CDD is working on Edit if you try to edit from the list itself.
 
Found a crazy work around. Essentially, I wrote a form plugin that does the job of the "setting the user id by setting the row id to -1" feature of the menu form.

Does seem like there is a CDD bug within forms loaded by setting the row id to -1 (for users).
 
Yes have the same issue.
A bunch of CCD's which on Edit the row in the List view loose their saved value (in the frontend only)
I have to retrigger the watch elements to get them to repopulate.
Same issue when swapping template to Cassiopeia.
Data holds fine in the backend.
@davez would you mind sharing your form plugin code to see if it will fix my issue.
 
See if this helps. This is a form plugin.

Before the form is loaded (onLoad)

Code:
$db =  Joomla\CMS\Factory::getContainer()->get('DatabaseDriver');
$app = Joomla\CMS\Factory::getApplication();
$user = $app->getIdentity();
$user_id = $user->get('id');
$user_id_form = '{wic_users___user_id}';
if (! is_numeric($user_id_form)){// blank form
  if ($user_id != $user_id_form){// user is logged in then load the form id based on the user   
    $query = "SELECT id FROM wic_users where user_id = '".$user->get('id')."'";
    $db->setQuery($query);
    $id = $db->loadResult();
    if ($id) {
      $link = '/my-profile/form/12/'.$id.".html";
     $app->redirect($link);
    }
  }
}

//form not blank, just edit as normal.
 
Thanks for the code. nicely done.
I ended up using a work around by allowing the user to load a list with a prefilter where a userid col equals {$my->id} , when they edit their row the CCD populates with no issues.
 
Unfortunately that didn't work for me. However, it gave me an idea of the exact cause:

CDD's are updated when the element-to-be-watched changes (onChange event).
If, however, the form is loaded with the Row = -1 menu option all elements are preloaded with the user's record.
This causes the element-to-be-watched to already have the correct data, so it essentially never changes unless the user manually changes it (and changes it back) but that would cause the CDD's to have their initial values. Therefore the onChange event is never fired on page load.

I think the solution might be to trigger those updates not only on a change of the to be watched element, but also on page load. Unfortunately I have no idea what JavaScript routine is getting fired off on element change.
 
Can you please test
in plugins\fabrik_element\cascadingdropdown\cascadingdropdown.php
change line 216 from $rowId = $this->app->input... to
$rowId = $this->form->rowId;

(In case of menu rowid=-1 there's no rowid input parameter)
 
Can you please test
in plugins\fabrik_element\cascadingdropdown\cascadingdropdown.php
change line 216 from $rowId = $this->app->input... to
$rowId = $this->form->rowId;

(In case of menu rowid=-1 there's no rowid input parameter)
That worked wonders!

Tested with both a new record and an existing record, in a form that has a regular dropdown (databasejoin) and two cascading dropdowns with filtered information based on the former ones:

[databasejoin] --> level 1
[cascadingdropdown] --> level 2
[cascadingdropdown] --> level 3

If there is an existing record, all elements contain the stored values.

This works as expected now.

Thanks a lot! You made my life a lot easier today :)
 
[databasejoin] --> level 1
[cascadingdropdown] --> level 2
[cascadingdropdown] --> level 3
I attempted the fix, but unfortunately, it didn’t work for me. When I applied it, nothing happened. The second cascading dropdown doesn’t load, and the list displays ‘No records’ on both the frontend and backend. The data is intact in the backend. After 20-30 minutes, the records display correctly, but filtering them causes the issue to reoccur.

Joomla! Version 5.1.4
PHP Version 8.2.23
Fabrik Base V4.3.1
 
I think I made a mistake replying it here. Not a CDD. My issue here is actually a dropdown in the search filter.
 
After 20-30 minutes, the records display correctly
Make sure to disable the Joomla caching in the system settings. I encountered the same frustration of not seeing what I was expecting from the changes I made.
 
@pakeydev
For all stuff using ajax etc (CDD, dynamic filters, ajaxfied lists/forms...) you must make sure to have no error messages/warnings/notices or J! System debug messages which may break JSON responses.
So check your browser console for JS errors and/or wrong network responses and reduce the system error level and set J!System debug off.
 
Back
Top