Neue Taxonomies

[jackmcdade]

We've all felt that taxonomies were always just not quite right somehow, but we've never been able to put our finger on it. I think that thing is that we glued the wrong edges together.

In v2, Taxonomies and their Terms were related to entries via their Fieldset, but the front-end had no idea what the fieldset was, so connecting the dots automatically was close to impossible. You could name the field whatever you wanted, which meant we needed to store the Taxonomy name along with the Term. Let's pull the pieces apart and put them back in a way that connects in a strong and consistent way instead of noodlely way. 🍝

1. Create Taxonomies as Collections*

This isn't new. Create a new taxonomy, give it a name, define a blueprint for custom fields, yada yada. For all intents and purposes, they're essentially just Collections that are organized separately.

*They're not collections, but they totally are. Not actually, but basically.

2. Taxonomies come in two flavors.

Tags and Hierarchies. We'll use a wizard, just like the Collection builder.

Tags work pretty much like we have now. They're primarily defined on the fly whilst in an entry. At their most basic level, they're a slug you can store more data against: design, food, cocktails, etc. Usually you will have more than one tag set at a time.

Tags are stored on the entry level as as list of slugs.

tags:
  - design
  - food
  - cocktails

Hierarchies incorporate a parent/child structure into the mix. Instead of a slug, we'll store the segments in the entry. Most often you will only have one singular segment stored. Like a category.

category: /products/furniture/couches

3. Taxonomies and Terms are connected to Entries through their Collection.

You choose which Taxonomies are available in a Collection in your Collection settings area. The Taxonomy fields are automatically added to your Collection's Blueprint(s). There is no customizing the field name of your taxonomy fields. They are simply the name of the taxonomy, and you cannot remove them from the Blueprint(s), but you can configure their settings. Required, max_items, and so on.

Because this relationship is strict, we don't need to store the Taxonomy name in the data (e.g. tags/foo). We can connect the relationship with the field name and the Collection's config.

4. Taxonomies can be shared across Collections, but Terms are global.

Any additional data stored in each Term will be available in all Collections that implement that Taxonomy. If that doesn't work for you, create another Taxonomy (e.g. tags vs product_tags).

5. When in the context of a Collection, we only care about its own Terms.

In other words, when we're designing the tags and parameters, you will only see the terms that exist inside that Collection unless you explicitly say otherwise.

6. Term permanence comes from inside the Entries

We still need to be able to simply slap some tags into your YAML and call it a day. We should not require a user to duplicate work and define a Term in another YAML file elsewhere.

With that in mind, we should create Term records much like we do unique ids - as we encounter them. Obviously in the CP we can do both at once.

7. Routes are automatically created on the Collection and can be manually defined on the Taxonomy

Filtering routes are automatically registered on the Collection, and templates for each (index and show) can be set in the Collection config.

# Autogenerated route, appended to the end of the Collection's main route
/{collection_route}/{taxonomy_name}/{slug?}

When on /blog/tags, you'll have access to {{ tags }} pre-scoped to the Blog's tags, in order to see all the tags available.

When on /blog/tags/cocktails, you'll have access to {{ entries }} pre-scoped inside the cocktails term, inside blog. This lets you see all blog posts tagged "design", for example.

An optional "global" route can be defined on the Taxonomy. By defining a base index route, we can automatically create the show route. These routes will let you list and filter all your Collection entries by Taxonomy.

/{taxonomy_name}: things.index
/all-muh-taygs: tags.index

Hierarchy routes are basically the same, but will use the {segments} variable to represent the multiple segments any particular Term may represent.

If you're inside a Heirarchy route (e.g. /products/furniture), your {{ entries }} pair will be pre-scoped to those entries inside or deeper (children), like a nav. We'll need to support a depth param here, just like the Nav tag.

8. Create Terms on the fly, edit in stacks.

Tags and Hierarchies will have different UIs. The former will be a pretty typical v2 style tag/balloon style input, while the latter will need something more like the Structures/Nav builder, but more contained and text-focused (less chrome-ui bits).

9. Everything should be as automagic as possible

Let's take the pain out of taxonomies. By making routes automatic, fieldnames fixed, and tags pre-scoped, things should Just Work™. Optimize for the common use case, which is very simple to understand. The URL is merely filtering content down.

[jackmcdade]

Updated issue with my notes from Basecamp so the @statamic/alpha team can review our intentions at their leisure. 😎

[jasonvarga]

Closing this in favor of smaller, more focused issues.