Disable native creation of collection based on tags

[sielay]

Is your feature request related to a problem? Please describe.

Currently tags works as reserved field in the frontmatter that assigns the page to the collections matching a tag name. For values tags: [ hello, World ] it will populate following collections:

{% for collection in collections | keys %}
  - {{ collection }}
{% endfor %}

  - all
  - hello
  - World

It does not hurt much with different approaches to taxonomy but pollutes collections dictionary. For instance, I have a blog with a few hundred posts and about a hundred tags. I chose to approach that instead of polluting collections dictionary nests taxonomies in the following way:

  - [taxonomy-name]
    - [taxonomy-value]
      - pages

i.e.

  - all
  - tags
    - hello
    - World
  - categories
    - blog
    - project
  - calendar
    - 2020
    - 2019

If we keep existing behaviour mixing both approaches results in messy collection like:

  - all
  - tags
    - hello
    - World
    - ...100 other tags
  - categories
    - blog
    - project
    ... many other categories
  - calendar
    - 2020
    - 2019
    ... more dates
  - hello
  - World
  - ...100 other tags

Describe the solution you'd like

I'd like to provide to the config toggle that prevents eleventy from populating collections based on tags field.

Adding such function would allow also to provide predefined taxonomy strategies as npx runnable zero-config libraries (in the same way we do npx @11ty/eleventy

Describe alternatives you've considered

I considered keeping the existing state. Anyhow, I find it limited and too opinionated for generic use of a library like eleventy.

Additional context

• plugin I develop to manage taxonomies in extensible way https://github.com/sielay/eleventy-plugin-blog
• not fully ready yet blog that will use features of that plugin in full of its power https://github.com/sielay/sielay.com/blob/master/.eleventy.js
• I will work on PR for the problem.

[edwardhorsford]

I've long wondered whether the auto-tags collections should really be collected under collections.tags.[] rather than on the parent collections namespace - tags would still be reserved, but it wouldn't add so many things to the collections.

There may have been a thread on this before, but I couldn't find it.

[sielay]

You can take that approach or you can keep 11ty less opinionated and leave it to plugins/users.

[vwkd]

Would be nice if "tags" could simply be renamed by the user in the .eleventy.js config. This would allow for a broader use case, since it also supports people who want to use "tags" for their own fields but also use the collections functionality just under a different name.

[zachleat]

@sielay I think I’m agreeing with @vwkd here that an option to rename would be better (with a permalink style false to disable).

I’d start by adding a keys entry for this and then a Configuration API method to override it

keys are here https://github.com/11ty/eleventy/blob/master/src/defaultConfig.js#L41

[sielay]

Happy to make PR for it

[sielay]

Though I think we speak here about two separate features. One thing is moving tags aside, another thing is that tags themselves pollute the collections.

[edwardhorsford]

I might even say three things!

1. Ability to disable the feature entirely
2. Ability to move the output so it doesn't pollute collections
3. To rename the frontmatter tag used

[sielay]

Hm. Alright. Just need bit more coffee. On it.

[sielay]

I updated #1255

1. Ability to disable the feature entirely - an easy one
2. Ability to move the output so it doesn't pollute collections - I'm not sure about this one. If I want to move the output of tags why I wouldn't use just addCollection? Actually, code is doing exactly that (which requires extra checks for --serve mode)
3. To rename the frontmatter tag used - done, more difficult, required loads of tests to be added

[sielay]

@zachleat @edwardhorsford @vwkd thoughts?

[xplosionmind]

Hi there, I am dropping in after one year wondering wether @sielay PR is ever going to be merged.

For what my opinion can be worth, I have just begun to work with Eleventy and I think that AFAIK it is the only software using the tags keyword in such a way.

I cannot wrap my head around the motivation for not using a way simpler solution, that I consider to be straightforward and intuitive:

• Collections should be defined by the collections property/keyword
• Sets of pages defined by tags should not be intertwined to collections, and, as @edwardhorsford suggests, they should only be a standalone collection with sub-collections based on the tag name.

I believe using this approach would be optimal and much less painful for anyone using other software incompatible with this interpretation of tags (Obsidian, to name one) or transitioning from another SSG (such as Jekyll).

Allow me to take the opportunity to thank you for your work and for the great software you are building, I am loving it! (except for this itchy tags matter ahah)

[boehs]

I highly support this:

PROS: An issue without a good resolution is resolved

CONS: People need to click on the search tab in vscode, enter collections and replace with collections.tags

Proposed solution: Show warning for 3 months when people don't use collections.tags, but still allow building. For these months, gate this feature behind a newCollections: true config flag

[cbirdsong]

For what my opinion can be worth, I have just begun to work with Eleventy and I think that AFAIK it is the only software using the tags keyword in such a way.

I agree with this. I ran into issues in this area when dealing with exported content that had a ton of tags containing oddball Unicode characters¹, which were really tripping 11ty up. I eventually normalized everything through trial and error, but ability to just disable it would’ve been super helpful.

It would've also been handy to be able to opt other pieces of front matter into the automatic collection generator, since the exported content also had 20 or so categories like "News", "Opinion", etc, which I wanted to make collections for.

Proposed solution: Show warning for 3 months when people don't use collections.tags, but still allow building. For these months, gate this feature behind a newCollections: true config flag

I think an config option to change this would make a lot of sense, but this feels inelegant. Maybe something like automaticCollections, which can accept false or a string/array?

A string would do the same thing as the current behavior, but with a different YAML key. automaticCollections: "category" would build top-level collections for every category value (collections.<value>), ignoring tags. The default config could be automaticCollections: "tags", avoiding making a breaking change.

An array of keys would generate nested collections like collections.<key>.<value>, as described in the OP. automaticCollections: [ "category", "tags" ] would generate collections for every tag and category value, but nested under collections.category.<value> and collections.tags.<value>.

This would also allow the use of a collections key as proposed by @xplosionmind. Example projects could have a default config like automaticCollections: [ "collections", "tags" ] and use collections for stuff like post and page and tags for the stuff that tags are usually used for on blog posts, getting rid of weird one-off stuff like having to exclude all and other non-user facing tags like post when generating tag pages, as seen in eleventy-base-blog.

---

Edit after posting: I see @boehs has already proposed a similar idea at #1255, including maintaining the current behavior as the default config. Consider this a comment in support of that!

Footnotes

1. Stuff like left/right quote marks and soft hyphens. Resolving that when creating collections might be a separate issue. ↩

[bennypowers]

Apropos unicode: Using the 11ty base blog template, adding a new post with

tags:
  - עיברית
  - English

fails:

[11ty] Output conflict: multiple input files are writing to `_site/tags/index.html`. Use distinct `permalink` values to resolve this conflict.
[11ty]   1. ./tags.njk
[11ty]   2. ./tags-list.njk
[11ty]   3. ./tags.njk (via DuplicatePermalinkOutputError)

but this builds:

tags:
  - English

[uncenter]

@zachleat can we revisit this for v3? I'm not sure if @sielay is still up for doing the PR but I think this is an important (breaking) change to make.

[uncenter]

@zachleat apologies for the second ping! Any chance this can make it onto the Eleventy 3.0.0 milestone?