Let's make taxonomies great again

[aerni]

Taxonomies are broken. There, I said it. I'm rooting for a complete taxonomy overhaul for Statamic 4. There are so many broken pieces, bugs, missing features, and conceptual issues about it. Taxonomies are so frustrating to work with that I wish they didn't exist. I've talked to lots of folks that share this view, like our beloved @robdekort and @mikemartin. We are all happy to contribute to making taxonomies the beauty they should be.

[jackmcdade]

I agree with you. Let's do it.

[jasonvarga]

Yes, I hate taxonomies. Drop your suggestions!

[robdekort]

Custom routes like collections!
Multisite fixes (will look up issues later)

[jasonvarga]

I'm more interested in what you think a "complete overhaul" looks like and what the "conceptual issues" are.

Features and bugs can just be added/fixed.

[aerni]

I'd remove all that automatic routing stuff. This only causes issues, and it's quite confusing. One biggy is that you currently can't add any data to a taxonomy's index page, which is an issue for SEO. Maybe we can make taxonomies mountable like collections. This way you can make any page a taxonomy index page, and you can add data as you please.

Another biggy is custom routes like Rob mentioned. This is very vital, especially when dealing with multi-sites.

I also dislike how localizations work with taxonomies. Currently, each term is published for all sites. There is no way to only have a term be available to a specific site.

Taxonomies just feel like a stripped-down version of collections. Less powerful with some automatic stuff. If you remove the automatic routing, add the missing features, and fix some bugs, what will the real difference between collections and taxonomies be? There's so much overlap.

Maybe collections and taxonomies should be merged into one shared content pool? You could then add a config option to mark a collection as a taxonomy to break it out into its own space in the CP. Just thinking out loud. Might be a terrible idea.

[robdekort]

Agree with Michael 100%. That would be very nice. If they'd basically work as collections they'd be much easier to work with.

[jasonvarga]

Maybe collections and taxonomies should be merged into one shared content pool?

I've often thought about this. Taxonomies are almost just Collections Lite™.

[jackmcdade]

Whatever we re-imagine, it definitely needs to take hierarchy (e.g. /categories/subcategories) into mind.

[aerni]

Totally Collections Lite™. We already got hierarchy in collections too. Collections and taxonomies are like identical twins. The same but still not the same.

[jackmcdade]

Yeah, though the UI and UX of taxonomies is VERY different. 99% of your interactions with Taxonomy data happens inside an Entry. It should act like a fieldtype, but be more powerful.

[jasonvarga]

If we were to make them work like entries... the terms field could create an entry using your entered text as the title/slug just like we do with the terms now.

[jasonvarga]

And the ability to drop terms into the frontmatter of an entry is nice. But maybe the stache watcher can create entries on the fly or something.

[jackmcdade]

What if we leave them separate but just rip out all the automatic routing stuff and add the ability to have multiple routes for a collection based on any of the fields in your blueprints?

blog/{slug}
blog/tags/{tag.slug}
blog/category/{category.slug}

Then we could improve the UX of the fieldtype itself a little bit and have a nested mode so you can create and organize the terms in a tree.

The only breaking change would be routing, and we could even have an update script create the previous style explicitly for you for backwards compatibility.

[jacksleight]

Built in sorting (inc. drag and drop) would also be great. Clients regularly ask how to sort taxonomies.

[aerni]

Yeah, though the UI and UX of taxonomies is VERY different. 99% of your interactions with Taxonomy data happens inside an Entry. It should act like a fieldtype, but be more powerful.

How is it different, though? You can create a term like you can create an entry. And you can attach terms to entries with the terms fieldtype the same way you can attach entries to an entry with the entries fieldtype. The only real-life difference for me is that I create terms on the fly through the fieldtype more than I would do with entries.

[jesseleite]

Also have to think of Term:: and Taxonomy:: facade usages, and how this overhaul will affect existing sites and addons too.

Or how if we merged into entries, how Entry:: and Collection:: could end up returning more things on people.

Or how {{ collection from="*" }} tag with from="*" outputs from all collections, etc.

Or how 'Colours' item might now show up under 'Collections' instead of 'Taxonomies' in the left CP nav.

etc.

...I would assume people often still want some kind of separation between 'entries' and 'terms', semantically speaking.

[jackmcdade]

How is it different, though?

It's probably more different in my head because what I dreamed and what we actually built weren't the same 😂

[jonassiewertsen]

I never used Taxonomies, as Collections always offered what I needed and are soooooo flexible.

This idea might sound bold, but I wanna drop it anyways:
Why not remove Taxonomies, if they only try to act like collections? Collections can do everything that is wanted, as far as I used them.

In my personal case, a customizable navigation for the CP would offer everything I could wish for and would have been much more helpful instead of trying to rebuild collection functionality in Taxonomies.

[andjsch]

I totally agree. Working with taxonomies is quite frustrating. While I wouldn't necessarily remove them completely for organizational purposes, I would love to see taxonomies working just like collections.

[jonassiewertsen]

Would a customizable CP Navigation give you enough organizational options, if your taxonomies would be collections and could be sorted as needed inside the CP navigation @AndreasSchantl ?

[andjsch]

Definitely. If there was some sort of toggle I could hit at creation marking them as a taxonomy would be plenty enough.

Other things to note that would make up for perfect taxonomies:

• Remove the terrible automatic routes
• Create new ones on the fly by using the "taxonomy" fieldtype

[mikemartin]

The simple taxonomy toggle sounds intuitive but I also like the organisational options that @jonassiewertsen suggested.

What if there were Collection Groups with Collections and Taxonomies as the default options. That would allow you to quickly move any Collection under the Taxonomy header in the CP nav.

You could then extend it further by adding your own custom Collection Groups options (ie. "Variants", "Courses"), and organise your collections in anyway you like.

[jacksleight]

I really like the idea of being able to have more control over how the collection nav is organised/grouped.

Something that's bugged me in the past is that if I have say a "Products" collection and a "Product Categories" taxonomy they appear in different places, despite being tightly related to one another. A separate group makes sense for global taxonomies but not ones that only apply to one collection.

I'd love it if "Product Categories" could appear as a sub item under the "Products" nav item. That way it's right there when you're in that collection and it doesn't clutter up the list when you're elsewhere.

[aerni]

In my personal case, a customizable navigation for the CP would offer everything I could wish for and would have been much more helpful instead of trying to rebuild collection functionality in Taxonomies.

I like this idea of @jonassiewertsen. Which is in line with my initial suggestion. More powerful CP navigation could solve the organizational part. At least from a CP user perspective.

@jackmcdade From a fieldtype point of view. The only difference between the entries and terms fieldtype is that you can't create entries with the dropdown and typeahead mode like you can with terms. This would be an easy addition to the entries fieldtype making both fieldtypes pretty much identical …

[jasonvarga]

I have a tendency to get excited about a big refactor, and need to be talked off the ledge. Jack and Jesse usually do a great job of this. 😂

But without really giving this a ton of thought, removing taxonomies in favor of collections seems like a great idea to me.

What are the differences between a taxonomy and a collection?

1. They are separated in the control panel nav.
   • We could have better control over the nav to just separate them out however makes sense in the project.
     See Navigation Improvements #74
   • We could have a "taxonomy" option on the collection to just mark it as a taxonomy.
2. They have the automatic routing.
   • Apparently people hate that.
   • Collections have the routing sorted. If a taxonomy was a collection, the work is already done.
3. You can "tag" content with them
   • If they were entries, you could probably just craft a smarter query. "Find entries where the tags field contains rad".
   • Right now if you land on a taxonomy term's page, you can use the {{ entries }} tag pair to loop over entries "tagged" with that term. We could probably keep this functionality around somehow, but even if not, you could just use a collection tag and do the above query.
4. You can pop terms right into the yaml of an entry
   • We could probably get around this by having the stache watcher create corresponding entries on the fly somehow.
   • Maybe that's not even a feature we care about? Maybe you could still do that, but they don't become full blown taxonomy terms. You could easily create a collection listing with that same query above. "find entries where the tags field contains rad".

Some additional pros to making them collections:

1. It's probably way easier to get hierarchical taxonomies working. Collections can already be structured.
2. Think of all those deleted lines of code. Less maintenance. 🤤

Some cons:

1. We'd most likely start dealing with IDs everywhere instead of term slugs. I don't know how big of a deal that really is though.
2. I'm sure there's plenty I'm not thinking about right this second.

[aerni]

Great thoughts! Another thing I hate about taxonomies is how the files are structured. Especially in a multi-site. I like collections and globals much more. Cleaner to have different sites extracted to their own folders and set an origin on localizations. Taxonomies are the only content type that is stored this way.

[jackmcdade]

All I ever wanted was to just be able to do this and have everything work:

title: Applesauce is on sale!
tags:
  - applesauce
  - sale
  - frugal
 ---
Hey everyone, there's a big sale at Publix this week!

[K3CK]

I totally support getting rid of taxonomies as of how they are implemented now. I found myself often in the situation that I thought "hm, this taxonomy could have been a collection", especially when the taxonomy needed an extended blueprint. After realizing this I often even had a hard time to decide if I should create a collection or taxonomy for certain data. And the multi-site issues with taxonomies also irritated me from time to time (different file structure, localization issues when trying to use localized term slugs in URLs, etc.).

I'm well aware that I might miss here something, as I'm not as experienced with Statamic as all of you, but from the perspective of a relatively new Statamic developer and user (~2 years) getting rid of taxonomies makes sense.

[lokmanm]

We are in the same boat as most of you. In a lot of cases where we needed a more powerful taxonomy we just went with collections for ex category/sub-category/sub-category.

The idea of merging the two is interesting and I am pretty sure they could become quite powerful.

[mscruse]

Being able link to Taxonomy Terms in the nav (easily) link you can with Entries would be great.

Forgive my ignorance, but if Taxonomies were removed what would the alternative be for the concept of "tags"?

[brendanfalkowski]

Be me:

1. Finish removing custom taxonomy routes in four sites to use the v3 automatic routes.
2. It's all simpler now. I like it.
3. Learn everyone hates automatic routes.

https://media.giphy.com/media/IgAay7r5YOBTYXqgBq/giphy.gif

[jackmcdade]

@brendanfalkowski i feel that. Nothing is happening yet, just collecting all the feedback we can!

[jasonvarga]

Forgive my ignorance, but if Taxonomies were removed what would the alternative be for the concept of "tags"?
– @mscruse

You'd use entries instead. Like if you used to have a "tags" taxonomy, you'd have a "tags" collection.

As you can see from some of the responses, there are people that do this already anyway.

[martyf]

Forgive my ignorance, but if Taxonomies were removed what would the alternative be for the concept of "tags"?
– @mscruse

You'd use entries instead. Like if you used to have a "tags" taxonomy, you'd have a "tags" collection.

As you can see from some of the responses, there are people that do this already anyway.

The issue I see with this is if a site has multiple what-is-currently-a Collection, and multiple what-is-currently-a Taxonomy, then the Collections list becomes rather lengthy - may not be the best for an author UX.

I feel the idea of separating them conceptually makes more logical sense - but agree functionality as discussed in the above comments can be improved and grown.

[jasonvarga]

The list is already long for some people as it is. There should probably be something done to navigation in the CP, regardless.

[ryanmitchell]

I would be in favour of removing them entirely. We rarely use them instead using collections.

The automatic routing is sometimes useful - news categories, blog categories etc, but the inability to change the taxonomy slug in the url often sends us down a different approach.

If the consensus is dropping in favour of collections then it would be important to allow multiple collections to be mounted on the same entry as this is a use case we often have.

[gizburdt]

Would be cool if you could assign a primary term to an entry, so the url could be something like this: /blog/{category_slug}/{entry_slug}

[tao]

I also ditched the automatic taxonomy routing and made my own custom pages to get it working for my site.

And never link the taxonomy on the collection editing page itself, rather I always create a custom Taxonomy Terms field on each blueprint I want to associate with the taxonomy.

[afonic]

After about 2 years of using Stamatic, we use taxonomies in various sites with a variable level of success. Certainly they are dorky and weird, but they work well enough for what we need.

I'd definitely:

• Make the routing custom and not automatically. Sometimes we need it, sometimes we don't and quite often we need it but not the automated one, so we end up creating custom routes.
• Make them orderable!
• Add better multisite support.

About dropping them in favour of Collections, I think this will inevitably lead to a complete overhaul of Collections:

• I'd definitely decouple Collections from Blueprints as this creates a few problems and duplication already. Instead, Blueprints should be available to all Collections and saved at Entry level.
• Collections should have Blueprints of their own, so that you can add extra information besides the config (and of course multisite support)
• They should be multi level and orderable.
• About the CP UX: I'd probably disable listing all Collections on the side as default and / or make it configurable.

[Lenitr]

Interesting points in this issue, below some of the issues we've ran into after working on a couple of Statamic projects. Some of them are already mentioned, but they do seem like recurring things after reading all the posts in this issue.

• It's not possible to mount a taxonomy to an entry. This makes it difficult to edit the content for the taxonomy itself, plus it gives less control over the url structure (unless you do it manually in your frontend)
• Related to this, if it's possible to mount, it should be possible to assign a template as well.
• Taxonomies are not sortable

I read that the idea is floated to kind of turn Taxonomies into Collections. This seems pretty logical, but there's 1 thing about the Taxonomies that make them really handy to work with (especially in headless setups):
You can filter Taxonomies by their slug. Currently entries can only be filtered by their entry ID. Would it be possible to support both? It seems reasonable to assume that the slugs should be unique per collection, so what exactly is the reason that i cannot filter by the slug?
The only reason I could think of is maybe if there's a field that's being used that could contain entries of multiple collections, is that the reason for that limitation perhaps?

Whenever we have a filter in a website and that filter is the entry of a collection, we want to display the filter in the url of the page, like /products?color=blue. If color is a taxonomy, we can use the value of the url directly in the filter query send through graphql to statamic. If color is a collection, we first need to have the entry ID of the entry, so we need to fetch the entry by it's slug and then use the Entry ID in another call for the filtering. (We've made a solution for this in the frontend framework we use, but it's far from ideal).

Thanks for having this discussion here in public, it's interesting to see some of the issues/solutions others have.

[el-schneider]

I'll chip in with my two cents. I recently looked at a lot of different CMS for different projects. Almost all of them, like: payloadcms.com, keystonejs.com, sanity.io and probably all of the other headless cloud-CMS don't bother with differentiating conceptually between something like a tag and an collection entry. Probably Statamic shoudn't too, at least not "under the hood". Compared to all the mentioned CMS, however Statamic has the advantage of offering a slightly tweaked editing experience, that's more adequate for tagging. I think this touches the core of what Statamic as a CMS is. It's not only oriented towards the developers (like most other modern CMS) but also towards their editors. And I think it should stay that way. So when you rip out taxonomies, don't forget to leave your users with a comparable editing experience.

[jackmcdade]

IF we rip out taxonomies. If all people want is collections, just use em. We already have em :)On Oct 8, 2022, at 5:02 PM, el-schneider ***@***.***> wrote: I'll chip in with my two cents. I recently looked at a lot of different CMS for different projects. Almost all of them, like: payloadcms.com, keystonejs.com, sanity.io and probably all of the other headless cloud-CMS don't bother with differentiating conceptually between something like a tag and an collection entry. Probably Statamic shoudn't too, at least not "under the hood". Compared to all the mentioned CMS, however Statamic has the advantage of offering a slightly tweaked editing experience, that's more adequate for tagging. I think this touches the core of what Statamic as a CMS is. It's not only oriented towards the developers (like most other modern CMS) but also towards their editors. And I think it should stay that way. So when you rip out taxonomies, don't forget to leave your users with a comparable editing experience. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[mikemartin]

Could someone document a simple example of using a collection as a taxonomy? How the routing and frontend tags would work.

[jackmcdade]

Would if I could. I can’t think of a clean way to do it. That’s why we have taxonomies :)On Oct 8, 2022, at 8:11 PM, Mike Martin ***@***.***> wrote: Could someone document a simple example of using a collection as a taxonomy? How the routing and frontend tags would work. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[j3ll3yfi5h]

It looks like Craft CMS is planning something similar like removing taxonomies and using collections for everything:
https://craftcms.com/blog/entrification

[hmw-anthonyc]

So when you rip out taxonomies, don't forget to leave your users with a comparable editing experience.

All this talk of replacing taxonomies with collections just makes me think "Ah... how the heck is that going to be understood by non-technical site admins who have to maintain this website?" Statamic is already (dare I say it?) too geeky for lots of non-technical admins to get their heads around.

If this is how Statamic is going to develop, please consider the UX for the admin and have it just make sense for laypersons without requiring a two-hour tutorial and a 300-page manual when handing over a site to the client. When "Collections" has a page, a post, a tag, a category... all sat next to each other in one bucket, it just doesn't make any sense to someone who isn't a developer.

@gizburdt said > Would be cool if you could assign a primary term to an entry, so the url could be something like this: /blog/{category_slug}/{entry_slug}

This would not just be cool... this is really important for SEO. Search ranking is greatly helped by allowing a search engine spider to crawl a site's pages hierarchically, and they derive meaning from human-readable URLs. They interpret the words in those URLs to understand what pages and structures mean. Humans do too. So, Google loves that. Using question marks, IDs, etc, in your URLs does not work in any way for people or search engines. It may be nice from a dev simplicity view, but, if you make Statamic all about developer-friendliness over user-friendliness, it's not going to be as successful as some other CMSs that should not be that successful. There's a reason that WordPress keeps on chugging even though it's a cluster of old and messy code garbage. It's not just all the free and easy plugins. Users matter and WordPress can be user-friendly (though, don't get me started on Gutenberg) and it's great for SEO in many ways that are pertinent to this particular discussion – i.e. crawlable page and URL hierarchies.

[jackmcdade]

@hmw-anthonyc Please keep in mind this is a community opened request. There definitely isn't a when we rip out taxonomies, that's a big if. Personally, I love taxonomies. I'm even happy with how they are right now. Someone would have to make a hugely compelling argument for ripping them out, and I haven't seen one yet.

Of course, we're always doing our best to improve everything we can. The idea that Statamic is "too geeky" doesn't sit very well with me. I mean, it's never going to be WordPress with the one-click-everything-including-security-disasters, but there are many things we can do to make the Control Panel more intuitive, the docs better, and round out features that people need — like hierarchal taxonomies and/or nested collections (which definitely are coming, just not in the immediate future).

Those things present huge additional complexities, which is why we don't take them lightly, don't change them quickly, and allow a lot of time for feedback and thoughts to come in so we can truly understand our audience and make sure we do well by them in stewarding this product.

As for assigning terms to entries with URLs like /blog/{category_slug}/{entry_slug}, that's exactly how they work right now. We don't put IDs in the URLs — we strive for maximum SEO friendliness.

Thanks for all the feedback, and hang in there. Great stuff is right around the corner. Just look at the good stuff coming in 4.0 in a few weeks — or checkout the #v4 channel in Discord where I've been posting screenshots of all the UI/UX improvements over the last month or two.

[hmw-anthonyc]

The idea that Statamic is "too geeky" doesn't sit very well with me...

Thanks, Jack. I don't mean to sound like an ass taking potshots from the sidelines. We've put considerable time into making a page builder for Statamic (https://github.com/HandmadeWeb/buildamic) that has some way to go but is intended to make it a bit easier for dummies who edit and maintain the websites after devs aren't there to hold their hand.

As for hierarchical taxonomies, I guess we'll keep trying to be creative when we use Statamic – we've yet to find a client (of scale) who doesn't need this. It just feels like we're hacking it. So we're always on the lookout for resources on how others have managed it.

[P4KM4N]

+1 for hierarchical taxonomy! It would help migration of WordPress to Statamic.

[jasonvarga]

statamic/cms#8877