🇺🇾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?

Here are the key changes and improvements made:

1. Fixed dependencies to handle cases when the Comment module is disabled but referenced in configuration
2. Added functional tests to verify module behavior and core functionality
3. Implemented Kernel tests to validate filtering logic, with room for future test expansion
4. Ensured Drupal 11 compatibility by removing deprecated function calls
5. Configured GitLab CI pipeline for automated test execution

The code is now ready for review and integration into the main codebase.

gonzalo2683 → created an issue.

Thank you for your response. I noticed that, although this issue was resolved in another ticket, the change never made it into the 4.0.0-beta1 branch. I’m currently using that branch, which is why I’m still encountering the deprecation issue, but I see that it has been fixed with beta 2.

gonzalo2683 → created an issue.

Hi Jonathan(@jonathanshaw), how are you? I've been facing a similar issue. I implemented a custom handler with checkboxes, but when saving the node for the first time, the values aren't stored in the database. However, if I edit the node and save again, the checkboxes are saved correctly.

I haven't found a solution yet. I saw your comment #67, but what you mentioned didn't work for me.

Do you know any way to address this issue? I would really appreciate any help.

Best regards.

Hello,

I've been using module and would like to discuss the inclusion of an additional `hook_update_N()` that runs during module updates. I have specific concerns regarding the performance impact this additional process might have, especially on sites with a large number of nodes.

Including an update process that also triggers a permissions rebuild concerns me, as sites which may not need this update are forced to undergo a potentially costly process across a large number of nodes.

My questions and concerns are as follows:

1. What is the justification behind the inclusion of the additional `hook_update_N()`, aside from the install and uninstall processes? I understand there may be valid reasons, but I would like to better understand the context and necessity from the development team's perspective.

2. Has the performance impact of this additional process been considered, especially since the primary updates seem intended for installation and uninstallation scenarios? Recommendations for mitigating impacts on sites that may not directly benefit from this update would be highly appreciated.

Thank you for your time, and I'm open to further discussion on this topic.

Best regards,

Gonzalo2683 → made their first commit to this issue’s fork.

Gonzalo2683 → made their first commit to this issue’s fork.

mlncn → credited Gonzalo2683 → .