Thanks for your help and work @mortona2k, and sorry for the delay in replying. I hope the module works for you and I would appreciate if you have suggestions for improvements for it. Best regards!
Thank you for your review and your time @apaderno, I correct the errors you have reported and I am always open to suggestions that can improve performance and security.
Hi @mortona2k, Can you give me more information about the problem, I have three websites with the module in place, and I don't get the same error you describe, as I have the latest beta version.
If you need to check something, try to debug the SsoController.php, but the error you described above is fixed with the latest version, at least in my case.
Try to give me some more information so I can help you, thanks!
Hi @vishal.kadam, how is the process going, is it normal to take so long? Sorry for being insistent, this is the first time I apply for this review process.
Hi @mortona2k, I have checked the problem you report and there should no longer be a problem with synchronization disabled. I have also overwritten the behavior of the cookie provided by the core to avoid this error. I'm going to create a new beta3 tag, can you test if the problem is solved? Thank you.
I have retested the whole process. I have fixed and refined some parts of the synchronization code, now it will work even if the user does not exist in the SP. Can you try with beta2 tag. Thanx!
Hi, thanks @mortona2k, glad to hear it's working for you. Regarding the user synchronization, you should have the box checked in both IdP and SP, they are both checked and you still have that error?
Hi @mortona2k, I have made some changes that fix the problem, adding routing and fixing some user sync issues. Could you try with the beta1 tag and check if you can now use the module correctly?
cesarmsfelipe → made their first commit to this issue’s fork.
@apaderno Thanks for your review, I have changed the license using the drupalcode template for version 2.
Thank you both for the feedback, I have solved all the phpcs requirements, deleted wrong branches and fixed the standard comments. Let me know if there is something else to change or improve.
cesarmsfelipe → created an issue.
Thanks benabaird, I've tested the custom removal method as per the documentation you provided, and it worked correctly for me.
Attached is a patch that improves handling of Select2 elements when removing a specific active filter, rather than clearing all values. This patch specifically adjusts the behavior for 'select' type fields to check for Select2 data and properly filter out the value to be removed, maintaining the rest of the selections intact. This change aims to enhance the usability and functionality of the Active Filters module when used with Select2 elements provided by BEF.
I've tested the patch on 1.0.0-rc2, and it successfully allows individual active filters to be removed from Select2 fields without affecting other selected values.
I would appreciate further testing and review.
cesarmsfelipe → created an issue.
Hi everyone,
I encountered an issue where both the select2 and webform Drupal 9 modules required the same JavaScript library (jquery.select2), but it was only being fetched and stored for the webform module in web/libraries/jquery.select2. The select2 module, however, was expecting this library to be in web/libraries/select2, which led to a dependency resolution problem.
To solve this, I implemented a solution using a symbolic link, created by a script executed via Composer's event hooks. This approach ensures that the select2 module can correctly locate and use the jquery.select2 library without needing to duplicate the library files.
Here's the script that creates the symbolic link (scripts/fix_select2_dependency.php):
<?php
$source = __DIR__ . '/../web/libraries/jquery.select2';
$destination = __DIR__ . '/../web/libraries/select2';
// Check if the destination directory exists, create it if it doesn't
if (!file_exists(dirname($destination))) {
mkdir(dirname($destination), 0755, true);
}
// Create a symbolic link if it does not already exist
if (!is_link($destination)) {
symlink($source, $destination);
echo "Symbolic link created: $destination -> $source\n";
}
And these are the modifications to composer.json to invoke the script after install and update events:
"scripts": {
"post-install-cmd": [
"php scripts/fix_select2_dependency.php"
],
"post-update-cmd": [
"php scripts/fix_select2_dependency.php"
]
}
I hope this solution helps anyone facing a similar issue. Feel free to adjust the script paths according to your project's directory structure.
+1 Applying the patch from the MR solved the issue, please merge!
I strongly agree with @pdjohnson.
Also, incorporating a short survey to gauge user experience level and specific interests in Drupal could enrich the data collected, leading to better contribution opportunities.
This approach could encourage mentoring programs and contribution opportunities early on.
cesarmsfelipe → created an issue.
The patch works for me on Drupal 10.1.5, but I'm adding it using the mglaman/composer-drupal-lenient composer plugin.