I created a simple MR to fix this.
I would appreciate some feedback on it.
I had the same issue.
Applying the patch from the MR solved the issue.
I've addressed those problems in the attached patch.
I also changed the minimal core version to 9.3, as the extension.path.resolver service has been introduced there.
GRcwolf → created an issue. See original summary → .
I would propose to close the issue.
It appears that version 2.0.x of this module already requires at least version 1.3 of google/recaptcha.
See the composer.json
The version 1.x of this module version requires "^1.2" of google/recaptcha.
So that means that it already allows using version 1.3.x of google/recaptcha. Composer should therefore already be downloading version 1.3.0 at least as long as all its requirements are met, and no other packages require another version.
I noticed that I forgot to add my css file to the patch.
That's the only difference in this patch
Hi shobhit_juyal
I disagree. This issue targets the 1.x branch. Which I guess, isn't compatible with captcha version 2.x.
Therefore this most likely needs to stay that way. Changing that might also break backwards compatibility.
recaptcha_v3 version 2.x already requires captcha 2.x so this would more or less be obsolete anyway.
But that is just my humble opinion.
(I would agree that this issue can be closed)
I've created a simple patch for the 2.0.0 branch that would achieve this.
It seems to works but more extensive testing would be required. The labels/descriptions could probably also be better.
I decided against making the branding text configurable as Google seems to want/require this specific text.
This isn't a polished implementation of this feature but I hope it provides a good base to work from.
I've used the patch #43 and encountered an issue with it.
Setup
I have a D10.0.x site. It is multilingual (DE/FR).
I use the json api to get a filtered/sorted list of custom content entities.
The entity type has a translateable name and an untranslatable weight (number).
I request a list of the entities sorted by their weight (primary) and their name (secondary).
My requests look like this:
/LANGCODE/jsonapi/my_entity/my_entity?fields[my_entity--my_entity]=...&filter[status]=1&page[limit]=12&page[offset]=0&sort=field_weight,name
Problem
Not using the patch means that the name sorting doesn't work as expected for the French (non primary language) translations.
However, applying the patch causes a new issue for me.
Filtering by field_weight doesn't work anymore for French but it still works for German (primary/default language).
For French, I simply get a list sorted by name.
The cause appears to be the value in the langcode column of the my_entity__field_weight table.
I went into the database and changed the value to "und" this caused the sorting to also break for German. Updating the column again and setting the values back to 'de' fixed it again for German.
Thoughts
My issue is that the proposed solution seems to break sorting for untranslatable fields.
I guess this didn't happen before as the json api always used the default translation of the field for sorting.
I also guess that the json api is now always using the field value for the current language for sorting.
As the field has no specific value for French, it treats the field as if it where empty. The json api probably doesn't get that the field is not supposed to have a French value as it is not translatable.
Those are just my initial thoughts on this. I haven't had time to dive into the code of the json api and explore how sorting, etc. is implemented.
Please let me know if i understood something completely wrong and this is not unexpected behaviour.
I've missed that this issue was already reported and fixed in #3328694.
I created a patch for Drupal 10.0, if anybody else needs to patch this.
It's the same as #15 but without the tests.
I created a patch for the issue and tested it.
It works as intended for me.
Could this be closed as a duplicate of #3110671 → now?