Add a dedicated tag widget

[erquhart]

- Do you want to request a feature or report a bug?

feature

- What is the current behavior?

Tagging can be manually implemented, but it requires work for the implementation

- What is the expected behavior?

Tagging should be a built-in feature. It should include out of the box (updated with suggestions from below):

• Autocompletion
• Viewing and editing of tags as a separate entity
• A distinct widget
• Allow tags to be limited to a list in config (maybe the only route initially)
• Each collection has it's own tags

All of that said, tagging should still be a plugin feature that can be swapped out, that makes use of existing widget functionality as much as possible.

[Benaiah]

Additionally, there's some details we should hash out:

• Do we want to allow any tags, or specify a list in the config.yml? The first option is obviously a better UX but it'd complicate autocompletion a bit, as we'd have to collect and cache all previously used tags (scanning all posts on keypress sounds untenable).
• Are tags specific to one collection, or are they shared across collections? Both sound useful in different contexts, but each has its own implementation considerations wrt autocomplete and tag viewing.
• Should we support viewing the entries in a collection with a specific tag initially, or should we wait on that?

I'm sure there'll be more to discuss, but those are my initial thoughts.

[willwade]

My comments!
Firstly - yes please!!

1. Specify a list.
2. Tags should be per collection. One extra request. Either a "tags: one, two, three " or as "tags_file: some/file.csv" that way a user could use the same shared tag list for each collection (and in some site generators we can compile the list from the files)
3. Wait on that

[erquhart]

Limiting tags to a list may be a good route for the initial implementation if it proves to be simpler, but ideally, specifying them in the config would be optional. @Benaiah we can optimize metadata collection as discussed in the past to simplify autocompletion.

Tags per collection, and waiting for a filtered view, totally agree.

[erquhart]

@biilmann interested to hear your thoughts on this.

[erquhart]

Here's what I'm thinking for requirements:

Configuration

• Accepts a list of tags
• Accepts a reference to a field in an entry containing a list of tags - not certain if we support this
• Accepts a flag to disallow entering tags that are not in the list

Tag list editing

• Tags don't really belong in a normal entry, nor in settings, probably a third "meta" entry type
• The difference in entry type really only affects it's appearance in the UI
• The editing experience itself will be configurable just like any collection entry

Widget UI

• Autocomplete
• Optionally limited to autocomplete via config
• Pressing space or enter transforms the typed tag into a visual tag with an x for deleting
• Tags can also be removed via backspace

[danchristian]

What is the lastet on this issue?

[erquhart]

#1936 will more or less resolve this issue.

_{Sent with GitHawk}

[erquhart]

Actually this requires the relation widget to select values from a single entry rather than the current behavior of selecting the entire entry. There's an issue somewhere but I'm not seeing it atm. Also root level arrays in data files would also make sense with this.

_{Sent with GitHawk}

[erquhart]

Circling back - discussion in #1100 (comment) is probably still our best plan - handle the concept of selecting one or more values, whether from a list in the config or from other entries, with a single widget. The path forward would look something like:

1. combine select and relation widgets
2. allow relations to specific values within an entry

This means the tags aren't in a single source-of-truth file necessarily, but they can be.

collections:
  - name: posts
    folder: content/posts
    fields:
      - name: tags
        widget: select
        multiple: true
        create: true
        selectFrom:
          - collection: posts
            field: tags

The above example would result in a select field that can select from a list of unique values used across entries in the posts collection in the tags field (via path). The CMS would create the unique list and cache it, only updating it as necessary, so the relation wouldn't require searching across entries, just within the cached list, meaning selectFrom would essentially drive a form of indexing. The indexing concept may be a bit limited when it comes to large repos selecting from lengthy fields. Maybe internally impose a max size limit and perf just sucks a little b/c there's no index.

I'd expect the above behavior to be pretty standard (selecting from the same field in other entries of the current collection), so selectFrom: true will probably be shorthand for this configuration.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[willwade]

Did this ever get done?

[erquhart]

Sort of - multi select is now supported for the select widget, so you can use that for a static list of tags defined in the config. More robust support is still forthcoming, so this should remain open.

_{Sent with GitHawk}

[erquhart]

Remaining work for this issue will be covered under #1489.