Implement Tags

[agriffard]

The goal is to create a TagsPart that you can associate to a Content type.

It will allow you to add multiple tags in an enhanced input.

Without this, a basic way to have tags is to add a TextField in which you enter them separated by a special character (ex: a comma) and then split them when you render the content.

If we want to make them unique and indexed and be able to get a count of the contents associated to a tag in order to display them in a list with these numbers or a tag cloud, we need to go further, even if we have to use a query in the end.

An admin UI to see all the tags, edit them and display the associated contents would be needed.

[wedge206]

I'm willing to give this a try.
Is there any particular Tag Implementation out there that we want to use as a model to base this on?

[psijkof]

@AidosMarcos Made a ContentPart module to enter tags. It's a beginning, there is no querying yet, but the tags are stored and retrieved and displayed in a nice way. You can find it in the sample project where we use OC in decoupled way here ModernBusiness with OC and Razor Pages The tag entered, get added after entering a comma and a space.

He made a little demo (with LICEcap):

Things to do:

• Prevent duplicates
• Query existing tags for the contenttype of the items that is being edited and autocomplete/dropdown those values
• Store tag values as array of strings, instead of one string, comma delimited . …

[sebastienros]

Ideally it should be a special mode/editor for taxonomies.

The only advantage I see with tags vs. taxonomies is that its use would be simpler in terms of querying/filtering and perf.

[sebastienros]

I change my mind on this every odd days ;)

[surfmuggle]

Aren't taxonomies intended to create a hierarchical structure - for example "/bikes/racebikes/men". And aren't tags intended to add attributes to a thing - for example "disc-brakes", "splash guard", "bicycle rack" "red".
Having both would be good.

[sebastienros]

Having one would be good too

[sebastienros]

I change my mind on this every odd days ;)

I think I changed my mind

[Piedone]

In O1 we kept Tags, I think mainly for historical reasons, since that was there first, and migration would have been additional work. But as long as we have the UI capability for Taxonomies to add them as tags (i.e. auto-complete textbox under the given content item) then I don't see why we'd need a separate module.

Taxonomies are hierarchical, yes, but you don't need to have a multi-level hierarchy for a given Taxonomy, a Taxonomy containing tags could be just flat.

[sebastienros]

But I already changed my mind ;) Tags implementation will be easier than open taxonomy (in order to support multiple editors for instance). And in terms of ease of usage (templates) and performance using Tags will still make sense if that's all what is needed. Genericity is good, but sometimes perf and experience is more important.

[Piedone]

Why would tags have better performance?

[bleroy]

Yeah, that sounds fishy to me as well. Taxonomies are fancy in the way they are managed and relate to each other, but it seems like once applied to a content item, it should be 100% equivalent. But what do I know?

[sebastienros]

It's all about storage. The content item contains the tags, there is no other lookup. With Taxonomies you have a content item reference. You need to load the taxonomy content item then look up for it.

But right now nothing prevents from have a custom taxonomy editor that will behave a tags. However rendering them will also be harder than just iterating over a string[] tags property.

[sebastienros]

But what do I know?

Me: But what do I know?

[bleroy]

Couldn't there be some amount of redundancy, where for example the term display text would get persisted on the target content item? It means some additional work to do when managing the terms, but it would enable everything tags can do, with the same performance where that matters, no?

[sebastienros]

Yes, that is a solution. But updating the terms properties, like the displayText, won't be applied automatically to all categorized content items. Tags are immutable, so this relationship doesn't exist.

[sebastienros]

There is some collision in the two features, I agree. But I think there are some valuable differences in their implementations. We could work something out with only taxonomies, but some specific scenarios would be harder to implement.

[bleroy]

My main beef with having them separated is that it's confusing for users to figure out which to use, and there's no clear migration paths (although there are scenarios for upgrading from tags to taxonomies). Updating items with the term they refer to is exactly what I meant when I said that implies additional work when managing the terms. It's doable, if inconvenient. You could also get away with it even easier if the term's id was its label. For flat taxonomies, they would effectively be completely equivalent. The difference is that what's stored on the content item is the term id (so still immutable, but you need id to be free form, like it is in Decent ;) )

[sebastienros]

Might work ... or not. We have limitations in the database for the length of the id, and ids are not localizable, that might be an issue later on.

[sebastienros]

I'll create an editor for taxonomies that will behave like Tags. That should work fine, and we can always come back on it if the need of a Tags module is really hitting us. It's easier than doing one now and regretting it later ;)

[Piedone]

That's the spirit!

I now see that for tags you don't mean an implementation like in O1 with tags attached to content items but rather storing tags in the content items in a denormalized way. While this would certainly be faster I can only think of disadvantages of this approach, one of the obvious ones being the question of what happens if you want to change a tag that's already on multiple items. Confluence uses this approach for example and there you simply can't change a tag...

[inhumator]

I tried implementing a custom tag-like editor for the Taxonomy field but I can't make it work, my new option from "TaxonomyField-Tagsinput.Option.chtml" does indeed show up in content type settings but my editor "TaxonomyField-Tagsinput.Edit.chtml" doesn't show. I did the same thing with custom HTMLBodyPart editor and it worked fine. I'm not sure what I'm missing. Is there a additional step to add a custom editor for Taxonomy?

[sebastienros]

All the same. Can you debug the code? Check the driver is called, and the view is not checking the wrong shape name for the option.

[inhumator]

Ok, Thank You. I'll check that as soon as I can.

[arkadiuszwojcik]

@sebastienros @inhumator so how is the progress with tag editor?

[inhumator]

I settled on text-field custom editor instead of taxonomy editor. Unfortunately I never found out what I was doing wrong.

[aderderian]

How are we looking on this item? Our team could use this on a site we're working on now. Should we pull this branch or start on a new one?

[sebastienros]

There is no branch for this right now. If you want to start working on it, just create a PR. The idea is to create a custom Editor for the taxonomy field. Take a look at the "PredefinedValue" editor for the TextField which shows an example.

[arkadiuszwojcik]

Implementation note: Vue multiselect have support for tags. It should be considered as editor for tags/taxonomies

[agriffard]

So, how do we support Tags in OC and what kind of editor would be used?

[johnrom]

@agriffard you can create a taxonomy using OrchardCore.Module.Taxonomies, manually add terms to the taxonomy, and attach the contentItemId of the new taxonomy to your content type. The editor discussed above is basically a dressing that makes this very easy to manage, but the functionality is basically possible without it (if you ignore the fact that tags can be hierarchical).

I'm getting to this soon in a project I'm working on, so I may get around to creating the custom field above.

I think, much like Taxonomies in WordPress, OC should support hierarchical / non-hierarchical taxonomies.

[sebastienros]

Not a custom field, a custom editor ... though a specific field might help for visibility, or maybe to store data differently such that the tag is store in the field instead. Might be some duplication of logic however when we want to index, or when we want to display tagged/categorized items. I am curious.

[johnrom]

@sebastienros I meant a custom editor. Because tags are often used as another view of the content type archive, I think that tags should act exactly the same as current taxonomies, but a taxonomy should have a setting like "IsHierarchical" to separate the concept of categories + tags. A custom editor would work very similarly to WordPress' taxonomy editors, which are proven and just work. We'd obviously use more modern tech underneath though. Here's a screenshot I found demonstrate how they work in WP. Notice that the two editors are slightly different.. I wonder if we'd want different editors as well, as one is more focused on free text and one is more focused on selecting existing terms, and the distinction definitely matters when editing.

https://themegrill.com/blog/using-wordpress-tags-and-categories-for-seo/

In addition to whether a user has permission to create tags or categories, the custom editor should have a setting in it when attached to a Content Type like "Allow Term Creation" because in some editing scenarios an editor should have the ability to generate whatever terms they want, and in some there are brand standards that should be managed centrally.

Disclaimer: I come from a WP background, so maybe I'm just biased to think this way. Therefore I'll add:

But what do I know?

[IamMarek]

I tried implementing a custom tag-like editor for the Taxonomy field but I can't make it work, my new option from "TaxonomyField-Tagsinput.Option.chtml" does indeed show up in content type settings but my editor "TaxonomyField-Tagsinput.Edit.chtml" doesn't show. I did the same thing with custom HTMLBodyPart editor and it worked fine. I'm not sure what I'm missing. Is there a additional step to add a custom editor for Taxonomy?

I've also tried to create a custom editor for the TaxonomyField but it does not work. I guess it is because the Initialize<EditTaxonomyFieldViewModel>("TaxonomyField_Edit" in TaxonomyFieldDisplayDriver. Is this a bug?

[deanmarcussen]

No bug, just waiting for https://github.com/OrchardCMS/OrchardCore/pull/4820 that will allow custom editors for taxonomy fields