Hoi
Today, the tag input type uses the property path to find suggestions from other content types with the tag input type. But I need to place the tag input type in different paths. Would it be possible to make the tags find suggestions by input type name instead?
And would it be possible to define a pre-existing list of tags?
Thanks
Hmm… Have you considered just using a “tag” content type instead? Then you can pre-define, manage them and just use a filtered content selector instead?
Yes, my plan b is to make a content type called “tags”. But for the content I am making now, the easy way of creating and retrieving tags is the most elegant solution. Creating a content type that holds a single word, that must be fetched by a method with an id, check if it is published, etc. feels kinda overkill.
If the suggestions for tags is based on other tag-inputs with the same name instead of path, it would make the tag-input really useful for us.
We are implementing a new feature where content selector will have a “+” button to the right, allowing you to immediately create new tags in this case. That will simplify process of creating new tags a bit at least.
Using “same name” is a bit unclear to me also, do you mean all instances of the “Tag” input type?
In a content type, all input types has a name, and depending on where in the xml structure the input type is placed, a path. If the tag input is placed inside an item set named stuff, and the tag input type is named category. The path to the input type is /stuff/category.
The tag input has an unique feature in the content studio, where when you start to type, it shows previously added tags. But only from tags input with the same paths.
I have two different content types, where I want to share the same tags. But since the tag input fields are placed differently, they have different paths. And therefore can’t share the same tag pool.
By using the input name to identify the tag pool, I can place the tag input where I need, and still get the same suggestions.
So, you basically want to be able to customize which property paths should be included in the tag autocompletion search? This makes sense.
I guess it would be smart to limit such a filter to specific content types as well - in order to avoid results from non-tag fields?
FYI: Generally, I would recommend that tags are implemented using x-data. Then you can have the same field across different content types, and inject the tag feature across content types where needed.