Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a "richer" taxonomy configuration #5520

Open
bep opened this issue Dec 13, 2018 · 12 comments
Open

Add a "richer" taxonomy configuration #5520

bep opened this issue Dec 13, 2018 · 12 comments
Labels
Milestone

Comments

@bep
Copy link
Member

bep commented Dec 13, 2018

See #5513 -- I will fix that issue so it works as described there, but looking at that issue I realize that many taxonomy related workarounds (and also limitations on what we can do) is rooted in the litle bit to limited configuration options.

In the above issue, @randallmlough was creative and created a taxonomy configuration like the one below:

[taxonomies]
"news-tag" = "news/tags"
"news-category" = "news/categories"

I have made the above a little simpler to wrap my head around it.

The term in the source code used about a taxonomy configuration definition is that the key (news-tag is the singular form and the value is plural. The plural is what you define in front matter and that is used to construct the taxonomy URLs (e.g. news/categories/index.html).

The above works nicely, but you get a tight coupling between content and taxonomy URLs and possibly miss out on other features that is now hard to implement.

I suggest that we as an alternative to the string plural allows a more "complex object":

[taxonomies]
[taxonomies.news-categories]
path = "news/categories"
title = "This is the news"
weight = 30

The above is quickly jotted down, but the thought is that it is the name that defines the front matter key (note that this will default to path which is the same as plural in the "old" way).

This would also make the content less coupled to the URL config:

+++
title = "foo"
news-tags = ["a", "b", "c"]
+++

Content.

/cc @regisphilibert @kaushalmodi @digitalcraftsman @onedrawingperday and gang

@bep bep added the Proposal label Dec 13, 2018
@bep bep added this to the v0.54 milestone Dec 13, 2018
@regisphilibert
Copy link
Member

I suggest that we as an alternative to the string plural allows a more "complex object":

If the key/value pairs allowed is not limited, this would also be a cleaner way of adding Front Matter to taxonomies (without having to create a content/my-taxo/_index.md).

"path" = "news/categories"

Why path and not URL? Will this parameter also influence the template lookup logic?

@onedrawingperday
Copy link
Contributor

onedrawingperday commented Dec 13, 2018

[taxonomies]
[taxonomies.news-tag]
"name" = "news-tags"
"path" = "news/categories"
title = "This is the news"
weight = 30

Hm... I like the above A LOT. It would also eliminate the need to replicate a taxonomy URL as a folder PATH so that we can insert meta data to the list page (exactly as @regisphilibert said above)

@bep I am 100% in favor of what you propose here.

@bep
Copy link
Member Author

bep commented Dec 13, 2018

Why path and not URL?

It's not a URL. It's used to construct the URLs and the filepaths (news/categories/index.html etc.), but it does not represent "something complete".

This is not related to templates/layouts (not now, anyway).

@regisphilibert
Copy link
Member

regisphilibert commented Dec 13, 2018

I suppose this will also influence the filepaths and URLs of its terms:
/news/categories/politics

Also, let's say the user needs to have a bundle or some Front Matter outside of their config file.
With path set to news/categories will the content dir for this taxonomy (and its terms) still be at the root:

content/news-tags/_index.md
content/news-tags/politics/_index.md

Or under the path value:

content/news/categories/_index.md
content/news/categories/politics/_index.md

I'm asking a lot about this path key because I don't think I ever saw it for other page Kinds.

@bep
Copy link
Member Author

bep commented Dec 13, 2018

I'm asking a lot about this path key because I don't think I ever saw it for other page Kinds.

Because this is a "new thing". We could call it ... section if that is familiar, but that would probably be even more confusing. But ... path is the same "thing" as the right side of the current taxonomy config. Exactly the same thing. Only more excplicit and more clear (to me, at least).

@regisphilibert
Copy link
Member

Ok I understand. As a user, for me the right side of the taxonomy config was just the plural. I never thought passed that.

@bep
Copy link
Member Author

bep commented Dec 13, 2018

for me the right side of the taxonomy config was just the plural.

I guess the word "plural" is used in the documentation, which I think is fairly confusing. But I guess it creates a convention (categories, tags). We currently only use the "plural" string (that is used in both front matter and as a path element for taxonomies list and terms).

@moorereason moorereason pinned this issue Dec 13, 2018
@moorereason moorereason unpinned this issue Dec 13, 2018
@moorereason
Copy link
Contributor

I like where you're headed here. One comment:

[taxonomies.news-categories]
name = "news-categories"

The name key/value pair is redundant. We can use the table name as the taxonomy name.

@bep
Copy link
Member Author

bep commented Dec 14, 2018

Why path and not URL?

I notice that we do use url in the front matter for a "similar thing" -- so even if it may not be totally accurate, maybe it is better to be consistent.

@bep bep modified the milestones: v0.54, v0.55 Dec 26, 2018
@bep bep modified the milestones: v0.55, v0.56 Feb 1, 2019
@stale
Copy link

stale bot commented Jun 1, 2019

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

@stale stale bot added the Stale label Jun 1, 2019
@bep bep modified the milestones: v0.56, v0.57 Jun 14, 2019
@stale stale bot removed Stale labels Jun 14, 2019
@bep bep modified the milestones: v0.56, v0.57 Jun 14, 2019
@randallmlough
Copy link

Has there been any more thinking about this? This would really help sites that provide a lot of different content types

@bep bep modified the milestones: v0.57, v0.58 Jul 31, 2019
@bep bep removed this from the v0.58 milestone Aug 13, 2019
@bep bep modified the milestones: v0.114.0, v0.115.0 Jun 13, 2023
@bep bep modified the milestones: v0.115.0, v0.116.0 Jun 30, 2023
@bep bep modified the milestones: v0.116.0, v0.117.0 Aug 1, 2023
@bep bep modified the milestones: v0.117.0, v0.118.0 Aug 30, 2023
@bep bep modified the milestones: v0.118.0, v0.119.0 Sep 15, 2023
@bep bep modified the milestones: v0.119.0, v0.120.0 Oct 4, 2023
@bep bep modified the milestones: v0.120.0, v0.121.0 Oct 31, 2023
@bep bep modified the milestones: v0.121.0, v0.122.0 Dec 6, 2023
@bep bep modified the milestones: v0.122.0, v0.123.0, v0.124.0 Jan 27, 2024
@bep bep modified the milestones: v0.124.0, v0.125.0 Mar 4, 2024
@bep bep modified the milestones: v0.125.0, v0.126.0 Apr 23, 2024
@bep bep modified the milestones: v0.126.0, v0.127.0 May 15, 2024
@bep bep modified the milestones: v0.127.0, v0.128.0 Jun 8, 2024
@bep bep modified the milestones: v0.128.0, v0.129.0 Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants