ideas
ideas copied to clipboard
statamic
Let's make taxonomies great again
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.
Custom routes like collections! Multisite fixes (will look up issues later)
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.
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.
Agree with Michael 100%. That would be very nice. If they'd basically work as collections they'd be much easier to work with.
Maybe collections and taxonomies should be merged into one shared content pool?
I've often thought about this. Taxonomies are almost just Collections Liteâ„¢.
Whatever we re-imagine, it definitely needs to take hierarchy (e.g. /categories/subcategories) into mind.
Totally Collections Liteâ„¢. We already got hierarchy in collections too. Collections and taxonomies are like identical twins. The same but still not the same.
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.
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.
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.
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.
Built in sorting (inc. drag and drop) would also be great. Clients regularly ask how to sort taxonomies.
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.
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.
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 đŸ˜‚
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.
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.
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 ?
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
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.
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.
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 …
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?
-
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 https://github.com/statamic/ideas/issues/74
- We could have a "taxonomy" option on the collection to just mark it as a taxonomy.
-
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.
-
You can "tag" content with them
- If they were entries, you could probably just craft a smarter query. "Find entries where the
tagsfield containsrad". - 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.
- If they were entries, you could probably just craft a smarter query. "Find entries where the
-
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:
- It's probably way easier to get hierarchical taxonomies working. Collections can already be structured.
- Think of all those deleted lines of code. Less maintenance. đŸ¤¤
Some cons:
- 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.
- I'm sure there's plenty I'm not thinking about right this second.
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.
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!
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.
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.
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"?
