Enable Tagify in the admin_ui and content_type_base recipes, and use it on all reference fields defined by our content types

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 ;-)

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 #3501759: The fields from the SEO Tools recipe should automatically be added to new content types when they are created after the SEO Tools recipe is applied we are talking about a recipe that leaves behind an ECA that can apply config actions. So instead of having to re-apply a recipe, to add 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 to change the form widget 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 #3501759: The fields from the SEO Tools recipe should automatically be added to new content types when they are created after the SEO Tools recipe is applied 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 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)

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! I think that makes a great choice for inclusion in Drupal CMS. Really pleased with how quickly this came together.

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

Yowza! Merged into 1.x. Thanks all!

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.