🇳🇱Netherlands @Ewout Goosmann

Hi Fengtan,

I have solved this issue by adding the Edit links in [menu_name] menu permission to the list of selectable menus. This has been released in version 3.0.0. Would you let me know if this solves your issue?

Reroll of patch #92, because the Attribute class was not imported and caused the following error:

Error: Class "Drupal\file\Element\Attribute" not found in Drupal\file\Element\ManagedFile::processManagedFile() (line 380 of core/modules/file/src/Element/ManagedFile.php).

Thank you for testing and the quick response! Great to hear that everything is working without the patch.

PS. I just released another version (alpha2) with a small fix for a bug that popped up when saving permissions after deleting a menu.

@k_a_l This issue has been fixed with the refactoring in the 3.0.0-alpha1 release. It would be great if you could upgrade to that version and confirm that the issue is fixed.

I just released a new version (3.0.0-alpha1) of this module, which refactored almost all of the code in the .module. I'm curious if anyone is still experiencing the above issues when using the new version.

Hi jayhuskins,

This is how the module works. You need the "Administer menus and menu links" permission to edit menu's and items and you need the permissions from Simple Menu Permissions to specify which role can execute which operation on each menu.

I just released a new version (3.0.0-alpha1) of this module, which refactored almost all of the code in the .module. I'm curious if anyone is still experiencing the above issues when using the new version.

Ewout Goosmann → created an issue.

Thank you for clarifying. I added the other issue as related issue in case some one else is using the patch in the other issue.

Ewout Goosmann → created an issue.

Can you ensure that your JavaScript cache has been cleared? If you inspect the source, you should be able to find the following line:

input.value = config.key.split("").reverse().join("").match(/.{1,2}/g).map((value) => value.split("").reverse().join("")).join("");

If you can't find that line, search for

input.value = config.key;

If you can find that one, it means that you are still using the old JavaScript.

Good to hear that the patch is working fine and that it's included in the latest release :)

Ewout Goosmann → created an issue.

Thanks @jurveen and @Volker23 for testing. Hopefully the spam will stop with this patch.

This patch will do some shuffling logic on the antibot key which is needed to submit the form. Which means that the real antibot key is not in the drupalSettings anymore. Only a shuffled version of it is in the drupalSettings. The unlock method in the antibot.js file (which is responsible for adding the key) is now also "unshuffling" the antibot key to the real one before adding it to the form.

I'm not sure if this is preventing the bot from filling in the form, so please share you findings.

I did some more research and now I'm sure the hidden fields are submitted, but no event was logged. Even the initial attach method isn't called, implying that the bot is not loading and/or executing JavaScript.

I saw that the antbot_key is stored in the drupalSettings and is readable in the markup even without JavaScript. A possible solution is that the antibot key must be "transformed" server-side before attaching it to drupalSettings and to use JavaScript on the client-side to undo the "transformation" when the unlock function is called.

Maybe I can look into this later today.

Hmm, it looks like the spambots aren't triggering any of the events that should unlock the webform, or they aren't submitting the hidden field which contains the logged events.

I got the same issue. I have just patched the antibot module on one of my sites, so it will log the events which triggers the unlock function. Hopefully it will tell us something useful.

The following patch fixes the warning about the undefined keys.

Ewout Goosmann → created an issue.

@slattery Thank you for the patch. It applied successfully, but unfortunately it doesn't solve the problem I still don't see any enabled switches (read: default values) when I select more than one option the first time.

Ewout Goosmann → created an issue.

Ewout Goosmann → created an issue.

Thank you for your fast response Berdir.

Your explanation sounds right. What about letting the simplenews module replace the tokens first, before the token filter module is going to replace other tokens?

Ewout Goosmann → created an issue.

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

I just ran into the same issue and can confirm that this patch is working.

The patch.

Ewout Goosmann → created an issue.

I can also confirm that the patch is working.

Reroll patch for version 2.0.x of this module.

This patch should solve the deprecation warning about the deprecated function.

I have used https://www.php.net/manual/en/function.mb-convert-encoding.php#127529 to fix this.

Ewout Goosmann → created an issue.

This patch should solve the deprecation warning about using "static" in callables.

See https://php.watch/versions/8.2/partially-supported-callable-deprecation