Enable Tagify in Admin UI recipe

This makes sense to me. As I'm just in the middle of a research for a customer project for the same requirement, I came across the Autocomplete Deluxe → module which seems to provide similar features. Maybe we can do a side-by-side comparisson?

Tagify sounds like a great choice! I'm maintaining the Autocomplete Deluxe module, but we're leaning towards switching from Autocomplete Deluxe to Tagify.

@rajab natshah glad you mentioned that now, that saves me some time researching this. We will of course go for tagify with our customer projects too, then ;-)

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.

Agree this sounds good, it was always on the list but just slipped! In addition to adding it to the admin_ui recipe, we also need to update any relevant field config to use the widget I think?

It would be great if, once installed, entity reference fields used the Tagify widget by default instead of the standard autocomplete. I've never looked into this but I assume it's possible? Similar to how the media library widget takes over the default for media if it is installed?

This is one thing I am always slightly concerned about when it comes to opting in to improvements, because any new fields created by the user will default to autocomplete, which is probably pretty confusing!

It would be great if, once installed, entity reference fields used the Tagify widget by default instead of the standard autocomplete.

In ✨ SEO Tools recipe should automatically reapply itself every time a content type is created Active we are talking about a recipe that leaves behind an ECA that can applies config actions. So instead of having to re-apply a recipe, to go the SEO fields on new content types in that example, on new content type creation, the ECA applies config actions LIKE a recipe would. If this proves to be possible, I assume it could be used any time a reference field was created.

I'm glad Pam is on board with this. I am too.

I think the module should be added to Admin UI for general availability, and drupal_cms_content_type_base since it would be used in all content types by default. Let's also update the form displays in the individual content type recipes.

IMHO, ensuring that Tagify is used for all new reference fields is something that we can do in a follow-up issue, once ✨ SEO Tools recipe should automatically reapply itself every time a content type is created Active is in and provides an example. Although, to be honest, my preference would be for Tagify itself to support this, maybe via a config flag if possible. It would be good enough for it to simply make itself the default widget for the field type(s) that it supports. Not 100% sure how to do that but I'm pretty sure there is a way.

So why don't we use this issue to add the module to our recipes, and open a second issue (postponed on this one) to use it by default on new fields.

Re-titling for clarity, and tagging to make clear that this will be in Drupal CMS 1.1.0, but not 1.0.x, since it is a feature addition.

Thanks, I agree that setting it to be the default should be handled separately. Also agree with @phenaproxima that this should be done by Tagify and not ECA. That approach makes sense for reapplying recipes but it seems a bit overcomplicated for this instance.

Okay so I just had a call with @gxleano and we agree that Tagify should support this out of the box so that DrupalCMS can use it without too much custom code, if any. What we agreed upon was this:

Tagify will provide a configuration form where for each target entity type, you can configure if a widget should automatically be set and specify the configuration for said widget. The default would be to not do anything, because we don't want to force a Tagify widget on a target entity type that might not make sense.

So you could configure any entity reference to a user to use the profile widget, while any entity reference to a taxonomy term would use a different widget.

Tagify will only apply this once to new fields so that people can still change the behavior if they want. New fields are:

1. Base and bundle fields of supported types whenever a new bundle entity is installed (e.g. new content type)
2. Manually created fields, i.e. a FieldConfig is saved

All of these settings will be exported to a single config object, so that DrupalCMS can opt into this feature by providing the necessary config file in a config/install or config/optional folder. DrupalCMS will then also need to make sure whatever config files it has for default content types and their fields are set to use Tagify as Tagify will not touch existing fields.

Finally, a bit of an afterthought but IMO still important. Instead of hard-coding the config schema of all widgets' settings, Tagify's new config object will use the schema notation to inherit the widget settings' schema so that the config object generated by Tagify can be fully validated.

The reason it's important we do not touch existing fields is that you'd end up frustrating users who want to opt out of Tagify and see it reapplied over and over after, say, every cache rebuild.

Re #11: That sounds quite a bit more complicated than I was envisioning. I need to do a little research about it, but I was envisioning that there would simply be a single boolean flag somewhere (tagify.settings:suggest_as_default or whatever) which, if enabled, makes Tagify the default widget suggested whenever a supported field is created, but otherwise imposes no opinion or requirement to use it. I imagine that'd be relatively easy to do and wouldn't require a detailed settings object with entity type-specific settings.

Thoughts?

I have no strong opinion on what Tagify does here, to be clear -- that is up to you as maintainers. But as far as Drupal CMS is concerned, this would probably cover our use nicely.

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 reply @phenaproxima. I agree that a simple solution could indeed be nice here and move things forward far quicker.

The only thing I see your suggested approach not covering, is base fields. E.g.: If I were to create a new content type, the author field would not use Tagify because we never saw any field configuration form. The, admittedly, more complex solution did cover that part.

Either way, nothing that can't be solved manually and the added UX of not having to choose a widget but get Tagify suggested as the default is already a big win IMO. Maybe we don't need to babysit our users to such extreme lengths as I suggested in #11.

With Adam and Kristiaan
1. Have config in the module ( That will be so nice )
2. Custom config action in the module ( That will help a lot )
3. Basic recipe for fields, and Views's filters

I'm in favor of having a new mechanism with recipes that automatically apply a recipe (as a default template) for form views and fields in Drupal sites.
Something like this
node.type.CONTENT_TYPE.bit.yml
core.entity_form_display.node.CONTENT_TYPE.default.bit.yml
with ConfigEvents::SAVE example
This default template of recipes could be part of Drupal CMS or function as an automatic config action triggered by specific event subscriptions.

Re #15: I think we might want to handle base fields separately, since they can specify whether or not their form display is even configurable to begin with. Truth is, for Drupal CMS's purposes, having Tagify on the Tags field is probably the most important case to cover, so if we need to deal with adding to base fields (like uid later), that's probably fine to do in a follow-up.

Re #16: That sounds useful later, but let's start small. For now, no need for a custom config action or automatic reapply. We could create a simple MR right this minute which brings in Tagify and uses it on the existing Tags fields. Later on we can add the more dynamic stuff.

So let's start with an MR that does the following:

• Adds the module to admin_ui and content_type_base
• Uses the widget, on the Tags field only, for the content types that we ship with Drupal CMS
• Adjusts tests so that they pass (this will be needed; we are checking which widget is used for each field)

This looks like a good start but the other points in #18 still need to be done. Quoting for convenience:

• Adds the module to admin_ui and content_type_base
• Uses the widget, on the Tags field only, for the content types that we ship with Drupal CMS
• 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.

Todos

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

Wow, amazing progress on this in one day :)

I agree that a simpler approach would be ideal, at least initially, and that base fields are less of a concern. FWIW my intention was pretty much what @phenaproxima described in #13: just that this widget is the default when a new field is added, but not 'enforced' or imposed beyond that. It should definitely be configurable per instance still as needed.

So anyway, yes let's use this issue to update the existing config to use the widget, and worry about the default stuff separately in the module itself.

And thank you @kristiaanvandeneynde @gxleano and @rajab natshah for your rapid collaboration on this!

Code looks good, tests are green and the UX of autocomplete widgets is much better now.

Screenshot of the Blog Post form:

I think it covers the agreed objectives for this initial issue. I would mark it as RTBC, but I'd rather to have a second pair of eyes more familiar with the issue actual scope.

This looks pretty close to perfect, but there are a few things we need to fix. We're missing the dependency in drupal_cms_content_type_base, and the test changes, while fine, don't actually give us anything new -- so we can revert them for now, I think.

I have nothing to complain about here from a code perspective! I think if someone can give it a quick manual test to confirm everything looks as it should, I'm good to merge it.

Gave this a quick manual test and it pretty much works as advertised. It's much more in line with what you'd expect from a modern CMS!

Since I didn't really write any code here, I'm calling it.

Yowza! Merged into 1.x. Thanks all!

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

Needs a change record pre-release.

Created the change record in the other issue; we'll just get it written over there.

Change record updated and published.

Automatically closed - issue fixed for 2 weeks with no activity.