🇫🇷France @berramou

You are welcome, glad that i helped!
Test the hook update too that migrate the old config to new structure.

Now each field has its own spam words.
The module adds a configuration for each field of type (Text field, Textarea, and Text format) to check if other field types will need spam words too.

I moved the development I did in this merge request https://git.drupalcode.org/project/webform_spam_words/-/merge_requests/13 here, but it seems to me that it's not exactly the same feature.

What I did was move the configuration to the webform level, so each webform should have its own spam words. However, the feature requested here is at the field level—for example, the message field could have some spam words, while the subject field could have different ones.

I'm not sure what the best way to proceed is: should I update the issue description to cover both features, or should I move the "Moving config to webform level" feature to a separate issue?

berramou → created an issue.

Yes, you are right. The two fixes, "Moving configuration to webform level" and "partial word matching," are out of the scope of this issue.
I will create an issue for the partial word matching returning false positives and will move the development I did here to that issue:
Configure spam words per field on a webform → .

As for the tests, I would love to help out with them. If you can add me as a maintainer,.

And another thing the check used
if (strpos($value, mb_strtolower(trim($word))) !== FALSE)
blocks words even if they are just part of another word. For example, if "SEO" is in my configuration, the word "Seoul" also gets blocked, which is not good.

Hello @briantschu,

Thank you for your contribution! It's good to do a quick fix release. However, in my opinion, the configuration should be at the webform level. As I mentioned in the description, in some cases, users may need to block spam words on certain webforms but not on others.

For example, in my case, I have two webforms: one for contact inquiries, where I want to block SEO-related words, and another for service information requests, where I don’t want to block SEO words, as they could be relevant to my client’s inquiry.

Apologies for the mix-up in the issue—it is a bug, but it also fixes something else.

Maybe we could create a related issue to add this as a feature?

I fixed the two first points

• 2.2.3 Stable release <<< KEEP THIS ONE
• 2.1.3 Stable release <<< REMOVE THIS ONE FROM PROJECT PAG

The third one need someone that can change branch settings access to make the 2.2.x as default branch.

Yes i remember i have fixed it in another issue, it was caused by JS error that blocks some maps.
And about the branches, i'm a co-maintainer but i don't have right to branch settings.
The branch 2.2.x should be set as default branch.
I guess we need to ask other maintainer to do that.

You are welcome, thank you for your report and details.

I can't reproduce this bug with the last version on Drupal 11
Look at the screen recording, @ressa can you give more details and steps to reproduce please

at the end i went with option 2 i added the support of group module.
Thank you @alvarom for your contribution.

It's the module group who delete the user groups

https://git.drupalcode.org/project/group/-/blob/3.3.x/group.module?ref_t...

The Group module implements hook_user_cancel and assigns all group entities of the deleted user to superuser.
I am unsure which approach is more pertinent:

1. Avoiding interference with the logic of this module and allowing the Group module's implementation to handle the process, or
2. Implementing the group assignment logic within this module as well, which, in my opinion, falls outside its scope.

Ah i see thank you for those details, i will check this out!

Can you please provide steps to reproduce and it will great if they are on drupal fresh install.

Hello @ alvarom
I can't reproduce this issue, i just tested with two users user1 and user2 belong to the same group.
user1 create an article in group, then i delete it and assign it's content to user2 that works perfectly see the screenshoots.

Maybe some custom code or users don't have the right permissions.

Thank you @will_frank for the testing.
Glad that this module is helpful for your projects!

Hello @will_frank,
I created the release 2.1.6 that contain this issue fix.
and yes i tested it on Drupal 10.3 too it works perfectly like @terao3, but i didn't test other versions of Drupal 10.
If the version 2.1.6 didn't work for you you can install previous version they had the datepicker library 1.9.0 that work with old jqurey versions.

berramou → created an issue.

Thank you @terao3 for the report and the patch!

Thank you for your contribution,
i'm sorry it seems my MR has more than the bug fix and my issue not a bug, maybe we can change this issue to feature request ?

berramou → created an issue.

Hello, thank you for your contribution!
We need a Drupal 11 release. If you need help fixing issues and releasing the Drupal 11 version, feel free to add me as a maintainer.

+1 for Drupal 11 release.

Result after the fix!

Hello,
Thank you @gillesbailleux for your report.
Yes you are right opentopomap doesn't support tiles with this form $zxy = '{z}/{x}/{y}{r}.png';
By checking the official website opentopomap https://opentopomap.org/#map=5/49.023/10.020 now they are using simple form $simple_zxy = '{z}/{x}/{y}.png';

I will commit the fix it will be part of the next release.

TODO:

Delete the annotation class src/Annotation/Sitemap.php once annotations are no longer supported.
Add a note for developers to update their plugins after the change to use the attribute instead of the annotation.

berramou → created an issue.

Hello @spuky any update about this improvement ?

I will close this issue since a lot of changes has been to this module and i can't reproduce it anymore !

@petr illek can you please test release 2.0.0-alpha4 !

Thank you @drupalfan2 for the report
Can you please test and tell us if you still have this issue with the version 2.0.0-alpha4!

I just pushed the code with the widget setting instead of the storage setting.
I don't think we need a hook update to migrate old configurations to the new one because I kept the same name.
However, we need to test the scenario where the field is reused across multiple bundles, as saving the last display form might overwrite the configuration for the field in other places.
Thank you @mandclu for this issue.

Since we gonna change the implementation it's better to work on #3167013: Use widget setting instead of storage setting? →
I guess it's time @mandclu

Hello @petr illek, and thank you for the report.
Yes you are right this module not working with Drupal 10 because the module using hook_field_widget_multivalue_form_alter which has been replaced by hook_field_widget_complete_form_alter see https://www.drupal.org/node/3180429 →
I'm working on it to adapt the module code to new hook.

It seems good idea @spuky !

I will close this issue, since no one can reproduce it.
@e5sego feel free to create another issue if this occurred again.

Thank you @olivierh65, for the report and the MR
I want to test it but, i couldn't manage to get an API key, can you please give us steps how we can get an API key.
And it will be great if we could add a link to page documentation or steps in the api key description in the module.

Ah i don't have this error,
I guess it's better to create a new issue and make it a follow up to this one, and describe what Block Visibility Groups you have.

Where do you want to add this params ? can you give a link to a documentation how to add region to google maps ?

The version 2.2.2 working perfect for me using custom MAP.

Can you please provide steps to reproduce this issue ?
Anyone else facing this issue ?

I close this issue as fixed, since now the module propose a hook that let developers add their maps ✨ Add hook to give custom modules possibility to add other maps to default list. Fixed

Fixed in 2.2.2 →

Thank you @ankitv18 fro your contribution!

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

Here is a patch needs reviews, the idea is to filter out the contexts without value before passing them to applyContextMapping.

Here is how to reproduce this error:

1. Create a Visibility Group with at least two condition one Request Path and another one with Content type
2. Apply this group to a block
3. Go to any pages that's not a node page or page listed in request path condition

You will have this error, it seems that the node (maybe any other entity type) it's required in the context, it seems that module evaluate the condition even if the context don't have value.

this line of code who throw the exception
$this->contextHandler->applyContextMapping($condition, $contexts);

because the $contexts will have ["@node.node_route_context:node" => "contextValue":protected]=> NULL ]

I'm getting the same error

Closing this issue as won't fix, because this module will not be needed for Drupal 11, the issue ✨ Image entities/fields embedded using Entity Embed cannot be linked in CKEditor Fixed has been fixed.