🇨🇴Colombia @fabiansierra5191

jasonglisson → credited fabiansierra5191 → .

Looks like the patch fix the warning. thanks!

Hi Allan, I'm just a bit frustrated but thanks for the new release.. I'll update the module.

I can confirm that patch #4 fixed the issue and was committed to the 8.x-2.x branch but it's not part of the last release so I'd say this issue should be Open or Reviewed by the community but the fixed status is not the right one.

Look like this was resolved.

fabiansierra5191 → created an issue.

I had to uninstall this module and I got the same issue.
I tried patch #4 🐛 Unable to uninstall RTBC and works for me.

Moved to RTBC.

The patch #14 worked for me as well. Move this to RTBC.

I tested this in the string or plain text fields.
Thanks!

Thanks!

Fix available on release 1.1.1, thanks!

are other modules enabled to have this behavior? On Drupal fresh installation without multilingual feature works.

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

Fixed on version 2.1.1, thanks for the patch and the tests!

Fixed on version 2.1.1

fabiansierra5191 → created an issue.

I changed my mind in terms of a new Drupal 10 release, the attached tasks are something we have to resolve for a new version of the module but I'd suggest creating a Drupal 10 release with the minimum Drupal 10 changes and having it available.

Drupal 10 compatibility included on release 2.1.0

Included on release 2.1.0

FYI, I started to work on version 2.X, for now, the changes include:
- Use Drupal Constraints for validation
- Plugin system to create/add custom fields to the validation

So, I take this ticket to follow up and communicate things regarding the new version

I checked the Drupal 10 compatibility and open an MR with minor fixes, with that the 3.X is ready for Drupal 10 but before a D10 release I'd suggest fixing the following items to have a good release:

https://www.drupal.org/project/unique_field_ajax/issues/3334220 📌 [3.x] Use plugins Active
https://www.drupal.org/project/unique_field_ajax/issues/3334219 📌 [3.x] Support all core fields Active

Yes, if you set the term name as Unique, the module validates that the term name is going to be unique for the vocabulary, so you could use only this one.
Both modules provided the same validation and error messages configurations but the "Taxonomy Unique" only does for the Taxonomy entity, this module also works on Nodes and fields (See module's description for more details)

I checked this as well and now it pointing to the proper config page

I opened an MR with the whole Drupal 10 compatibility fixes and hope for the maintainers to create a new D10 release.

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

Following the path of this ticket was not easy, the previous one has a lot of comments and some perspectives but after research, I can say that the changes made on this ticket look like the best based on some Drupal documentation and considering the discussion of why "URL" should be capitalized this way in code documentation:

• https://www.drupal.org/docs/develop/standards/php/api-documentation-and-... → All documentation and comments should form proper sentences, use proper grammar and punctuation, and generally follow the same style guidelines as Drupal.org content: http://drupal.org/style-guide/content and in the page itself the references to "URL" are capitalized
• https://www.drupal.org/drupalorg/style-guide/content#relatedwords: → URL, not url
• Something the ticket already has but it's important to mention is that MR only covers the "url" to "URL"

Wrong file, so ticket moved to previous status

As the latest test results mention the accessCheck() function is not required here https://www.drupal.org/node/3201242 → , so about the last changes I remove this but kept the comment for BlockMachineNameGenerator class

fabiansierra5191 → created an issue.

Thanks @alexpott for the feedback!

I addressed your points by changing the comment for BlockMachineNameGenerator class and setting the accessCheck() method.

Hope this one is the one!

Thanks @xjm for the feedback,
I did all changes suggested except for the bullet 11 on the comment #71 test_theme variable is been using to replace the new theme in various places and I think we can keep it.