🇪🇸Spain @gxleano

gxleano → changed the visibility of the branch 3516622-the-styles-in to hidden.

gxleano → created an issue.

Thanks to report @drupatz!

I have not been able to reproduce the problem in Google Chrome or Firefox.

What I have fixed is the error/warning message alignment, which is now properly aligned to the middle.

gxleano → changed the visibility of the branch 3516428-library-css-overrides to active.

gxleano → changed the visibility of the branch 3516428-library-css-overrides to hidden.

Hi @loze!

First of all, thank you very much to report the issue.

I've been trying to reproduce on my side (clean installation), but I was not able to do it. Maybe there is something in your end which is making it fail.

Checking the attached error which you are reporting, seems like something is wrong with the handler_settings in the field where you are trying to use Tagify widget.

We could add a validation there in order to avoid NULL handler_settings, but it is quite strange, so I will need more information from your side:

Which version of Drupal are you using?
Which version of the module?
Are you using a custom handler in the field where you are trying to set Tagify as default widget?

The Iconify Icons → module already includes a submodule, the Iconify Icons Provider, which is fully integrated with the new Icon API. It provides a wide range of icon sets, making it a great opportunity to offer similar flexibility to XB users.

Update documentation

Update:

Seems like this is not working yet with the new navigation.

I've been testing, but the custom icon using UI Icons Menu and Iconify Icons Provider is not visible.

Navigation leverage icon core API 📌 Navigation leverage icon core API Needs work

Hi @nathanhealea!

You could add custom icon by installing the next modules:

Provide the way to add the icons to the menu:
- UI Icons →
- - UI Icons Menu (UI Icons submodule)

Provide several icon sets to use with UI Icons:
- Iconify Icons →
- - Iconify Icons Provider (Iconify Icons submodule)

For more details, see: https://www.drupal.org/node/3490350 →

It will be included in release 1.2.37

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

Thanks @thejimbirch, it was also a suggestions by @plopesc, so I will update it.

I will finish this today @phenaproxima.

Now I see!

It totally makes sense.

Thanks Jurgen.

Thanks Jurgen for the quick feedback!

The goal is to set set_default_widget to TRUE in Drupal CMS, which will be implemented through this issue. Given this, I don’t see the need for the hook.

In the Tagify module itself, I would keep the option set to FALSE, allowing users to decide whether to enable it as the default.

But, maybe I'm not seeing something.

gxleano → created an issue.

It will be part of release 1.2.36

#6 ✨ Add a setting form where Tagify widget can be set as default when a supported field is created Active I did not consider the test coverage at the begining of this implementation, but it makes a tons of sense.

gxleano → created an issue.

A new settings form has been added, allowing users to suggest the Tagify widget as the default for supported entity reference types.

By default, the Reference section is hidden. It becomes visible when the user selects Suggest Tagify widget as default. In this section, users can modify which widget will be the default for each supported entity reference type. This feature enables users to even set Tagify User List as the default widget for the User entity reference type and Tagify for Taxonomy terms.

Once configured, any newly created entity reference field will automatically use the selected widget as the default.

Thanks to report @r_h-l, but this is already fixed in 1.0.x

I will create a new release soon.

It will be included in release 1.2.36

Thanks Dieter for the quick feedback!

Thanks to report it Dieter!

I've been testing the changes, but it seems to be breaking the summary information when Tagify User List widget is used in the Authored by field.

See evidences:

Thank you to everyone involved in making this happen and moving it forward! 🚀

Todos

• Adjusts tests so that they pass (this will be needed; we are checking which widget is used for each field)

I think that we would need to decide if authored by (uid) field should also use the tagify widget by default or the tagify_user_list provided by Tagify User List submodule.

From now, I will add it just for tags field.

gxleano → created an issue.

Thanks @kristiaanvandeneynde for summarising.

Yep, you are right @phenaproxima, maybe we are overcomplicating things here. I see your suggestions as an achievable options. We can just add a new option in Tagify settings to enable/disable it as default widget for every supported field type when it is created, but it is up to the user to use it or not.

As suggested by @phenaproxima in #8 ✨ Enable Tagify in Admin UI recipe Active , I will create the follow up issue in Tagify in order to work on the default solution, and we can just use this issue to enable the module in the Admin UI recipe.

Thanks for the quick feedback @jurgenhaas and @rajab natshah for the kind words, I really appreciate it!

Autocomplete Deluxe is a great and solid module that improves the tag styles and autocomplete experience a lot. However, Tagify goes beyond just improving tag styles and autocomplete, it provides a set of features that make it a more versatile choice. One of the most useful features is the "Info Label", which allows you to add extra information to tags for better clarity and usability. You can take a look to the full documentation here: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → , and more details for the info label available here https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → .

Info label example with icons

Tagify also includes features to improve:

- Select widget
- Hierarchical taxonomy terms

- User entity reference fields

Would be great if we can provide this features to the users also in Drupal CMS, I think that it would improve a lot the user experience.

gxleano → created an issue.

Thanks Anna!

It was not included in 1.0.4, my bad.

Already included in 1.0.5, so the module is ready for Drupal 11.

Thanks @stmh to report the issue!

It will be included in release 1.2.35

gxleano → created an issue.

It will be included in release 1.2.34

gxleano → created an issue.

It will be included in release 1.2.34

Closing this issue.

It won't be fixed from now.

gxleano → created an issue.

It will be part of release 1.2.33

gxleano → created an issue.

It will be added to 1.0.4 release.

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

@monaw

This is clearly described here:

Installation
Install this module like any other Drupal module. Because this module uses both the Ajax and the JavaScript states API in forms, the patch from the Drupal.org issue Display Bug when using #states (Forms API) with Ajax Request 🐛 Display Bug when using #states (Forms API) with Ajax Request Needs work is required for the form to behave correctly.

Problem/Motivation

Deprecated: Creation of dynamic property Drupal\json_ld_schema_ui\Schemaorg\SchemaData::$descendantPaths is deprecated in /var/www/html/web/modules/contrib/json_ld_schema_ui/src/Schemaorg/SchemaData.php on line 141

Steps to reproduce

• Update To Drupal 10.2 with PHP 8.1
• Go to /admin/structure/types/manage/[CONTENT TYPE]/json_ld_schema

Proposed resolution

Declare $descendantPaths properties in the SchemaData class.

It will be included in release 1.0.4

Thanks @priti197 for the fix and @monaw for testing it.

@monaw

If you tried the patch and it fixed the problem, the issue should be moved to RTBC.

This may relate to the issue at https://www.drupal.org/project/tagify/issues/3452136 🐛 Entity reference widget only works if you type slowly Active , but based on my understanding, we should focus on improving the user experience. As it stands, it’s not functioning perfectly.

gxleano → created an issue.

gxleano → created an issue.