- Issue created by @musa.thomas
- π³πΏNew Zealand quietone
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.
- πͺπ¬Egypt Ahmed Eldesoky
I can confirm this issue when placing the ajax callback within the same class that provides the options form
however a simple fix would be placing the ajax callback on your .module file
something like this/** * {@inheritdoc} */ public function buildOptionsForm(&$form, FormStateInterface $form_state) { parent::buildOptionsForm($original_form, $form_state); $form['test']=[ "#type" => "select", '#default_value' => "test", "#title" => t("Component"), "#options" => ['test'=>'test','test2'], '#ajax' => [ 'callback' => '_your_module_ajax_callback', 'wrapper' => 'test', 'effect' => 'fade', '#suffix' => '<div id="test"></div>' ], '#executes_submit_callback' => FALSE, '#required' => TRUE, ]; }
and in your .module file
function _your_module_ajax_callback($form,FormStateInterface $form_state ) { return ['#markup'=>'hello']; }
- πΊπΎUruguay gonzalo2683
I've been experiencing the same issue with AJAX in a Views filter plugin. I've implemented the recommendations mentioned in this thread (using static callbacks, storing the instance in form_state π¬ Strange problems with ajax in a custom views filter plugin Closed: outdated ), but I'm still encountering a problem during the first interaction.
Specifically, when I first add the filter and select an option that should trigger the AJAX to load checkboxes, it incorrectly reloads the entire filter form instead of just updating the specific element. Interestingly, if I close the modal and reopen the filter configuration, the AJAX works correctly on subsequent interactions.
This suggests there might be an issue with how the form is initially built or how the AJAX callback is locating the correct element to replace during that first interaction. Has anyone found a solution for this specific "first load" problem?