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.