Just closing the loop on this... I debugged this a lot further. The module and reCAPTCHA v3 is working as designed. It's just terrible at catching spam. I didn't realize this, but reCAPTCHA, doesn't actually look at form submissions, so the "clearly spam" submissions aren't being looked at from that perspective. I'm assuming the bot or whatever was smart enough to spoof reCAPTCHA. I did notice in the submissions, it switched IP after 2 submissions.
Anyways, for others reference, switched to Honeypot... that seems to be catching everything at the moment. I haven't used it in years, but seems like a great option.. maybe even in conjunction with reCAPTCHA v2 or something...
I was just evaluating this today... looks like by simply adding the Views handler to the entity would start to get this going.
in editor_note/src/Entity/EditorNote.php in the entity def.
* handlers = {
* "views_data" = "Drupal\views\EntityViewsData",
* }
If i end up going with this module, I may try and add a patch.
When taking a look at this, I tested with Mix 1.9.0. When creating a brand new menu link without children, seems there is an error with the mix module. I'm seeing this in the logs when trying to enable First Child menu link:
Error: Attempt to assign property "options" on null in mix_menu_link_content_form_entity_builder() (line 651 of /Users/peteinge/Sites/drupal10/web/modules/contrib/mix/mix.module).
At a quick glance there is no error checking or anything on the mix module's side. This should be addressed before we work on trying to make this compatible with another module.
After creating a menu structure, and trying to change a parent link, I'm seeing the issue as described above. Diving deeper, the mix module is wiping out all other options on a menu link item in _mix_build_menu_link_options(). I would consider this an issue for the mix module to fix, and merge other options that might be present. This module can't do anything if another module is wiping out the data.
I'd consider this a Mix module issue.
Not sure how supported this is but if you're looking into this, in `idattributesui.js` in the plugin, in the `_showForm()` method, just needs a better selector for the target. Right now it is only using a queryselector on a class, so it will always be the first one on the page.
I'm not a CKEditor plugin writer or anything but, I changed it to this, based on another plugin I was looking at. Places the label in the element you are adding the id to.
const view = this.editor.editing.view;
const viewDocument = view.document;
let target = null;
// Set a target position by converting view selection range to DOM.
target = () => view.domConverter.viewRangeToDom(
viewDocument.selection.getFirstRange()
);
For anyone else looking, the patch in #9 works great for the 1.5 branch of this module, and is only partially applied to the 1.6 branch but I am receiving errors. Currently a bit slammed, but will be looking into resolving this and rolling a new patch by the end of August as I need to work on getting a site D10 ready.
I'm currently using the latest dev release and the patch in #15 is not applying. the issue with "Notice: Undefined index: data in" was fixed in a different issue ✨ Preselect Views by administrative tags Needs review , and fixed differently.
Seems I can still use the patch in #12 though for this issue.
Looks like this might need a new patch against the development branch...
Yes thank you @cmlara! Ultimately ended up being a credentials issue but your feedback helped me track it all down.
Thank @cmlara, this give me a lot to run down!
@Rishi Kulshreshtha
Sounds great! Just confirming you manually did that in the config file and not through the admin UI?
I would need some more information to look into this further.
Not sure if this is still an issue... but in the d8+ version we are setting a link option. You can see this in the code in the module file, and menu_firstchild_menu_link_content_form_validate().
I would suggest creating migration filter that would check for the url in the source3 and sets that option on the destination Menu Link Item.
If this is still an Issue, please re-open.
Updated Project Documentation Page
Thanks Ludo.R for the patch! I'll be adding that in a created a D10 version shortly.
sleitner - the first two issues there seem to be false errors. I'm not entirely sure how drupal-check is checking that. I'll be creating a commit for those other 2 test issues shortly.
Assuming this was fixed since there was no follow up