Taxonomies: Allow querying for all posts with any term of a given taxonomy

[Bernhard Reiter]

Consider an example taxonomy, e.g. projects, with possible terms film, tv, etc.

Upon registering such a taxonomy -- and creating those terms -- WordPress provides us with routes, such as /projects/film and /projects/tv, which will display all posts that have those respective terms assigned.

However, there's no straight-forward way to show all posts that have any term from the projects taxonomy assigned (in this example: all film and tv projects at once). Instead, depending on the chosen permalink structure, the /projects route will be typically understood by WP as the slug of a page or post; and if no page or post with such a slug exists, it will 404.

I believe that there might be a need to support such a "root taxonomy route" -- for lack of a better word. In terms of ​template resolution, that route should use all the matching taxonomy related templates (i.e. taxonomy-$taxonomy, taxonomy, archive, and index). This applies to both Classic Themes, and Block Themes.

Permalinks in WordPress are, of course, not the canonical representation of routes; query strings are. For example, /projects/film translates to ?projects=film. Fortunately, while syntax like ?projects= (with no value assigned) or simply ?projects is currently not supported by WP, they ​aren't strictly disallowed by the URI RFC.

[Bernhard Reiter]

With a feature like this, we could have a taxonomy-$taxonomy template that contains, among other things, a ​block that lists and links to all terms in the given taxonomy. That way, users arriving at /projects will be able to easily filter for films (/projects/film) or TV works (/projects/tv).

This could then be refined further by using the Query Loop block's support of client-side navigation -- meaning that the page at /projects would allow for client-side filtering by existing terms.

WIP, Details to follow.

TODO:

• [ ] Add rewrite rule to map /tax to ?tax.

Trac ticket: https://core.trac.wordpress.org/ticket/61957

The ​Query Monitor plugin has come in _very_ handy while working on this.

Noting here that if we don't want to implement this kind of behavior universally for all taxonomies, we could add an argument to register_taxonomy to control it.

[dmsnell]

Is there any concern about using this top-level naming and potential clashes between taxonomies? Can someone create a category and a tag of the same name, or a taxonomy named post?

[SergeyBiryukov]

Related: #13816, #16832, #57933.

[Bernhard Reiter]

Ah, thank you very much, @SergeyBiryukov! I tried searching for existing issues but must’ve used all the wrong keywords.

My takeaway from #13816 and #57933 is that people seem to be divided over having that route point to an archive of all posts that have any term from the taxonomy assigned (as I was thinking of), or to a list of all terms in the taxonomy. I’m probably biased since the latter hadn’t even occurred to me. I’d argue that is is somewhat of a separate problem from making the route work in the first place, but I’ll think about it for a bit and will add my thoughts here or on the PR.

[Bernhard Reiter]

@dmsnell Yeah, collisions can be an issue, but I don’t think they pose a whole new class of problems in this case; collisions between nested page routes and taxonomy term archive routes are documented already (e.g. in #16832, which was referenced by Sergey). Typically, these are solved either by order of precedence of rules, or by helpers such as ​wp_unique_post_slug.

FWIW, there’s exhaustive unit test coverage of route patterns and what they’re translated to, and my WIP PR doesn’t break any of them, so I’m cautiously optimistic that we can make this work. I’ll start adding some unit test coverage for the patterns that my code is meant to support to see if those will unearth any type of collisions I didn’t think of.

To allow using just one template to render both that root taxonomy route (/projects), as well as the taxonomy archives for each of the terms in that taxonomy (e.g. /projects/film, /projects/tv, etc).

The recent proposal from @youknowriad about architectural changes to how templates get linked with themes might resolve this issue because we would finally be able to have 1 template file applicable in multiple scenarios:

• ​https://github.com/WordPress/gutenberg/issues/66950

To allow using just one template to render both that root taxonomy route (/projects), as well as the taxonomy archives for each of the terms in that taxonomy (e.g. /projects/film, /projects/tv, etc).

The recent proposal from @youknowriad about architectural changes to how templates get linked with themes might resolve this issue because we would finally be able to have 1 template file applicable in multiple scenarios:

• ​Block Themes and site editor: Refactoring templates gutenberg#66950

AFAIU that proposal would allow the user to assign custom templates to any template "entity" in the template hierarchy (i.e. to any red, green, or blue box ​in this diagram). This means that it'd be still somewhat coupled to the template hierarchy, as opposed to allowing assigning a custom template to any given _route_.

As a consequence, I think we'd still need to extend the template hierarchy to contain a template "entity" that's shared between existing taxonomy archive template entities (i.e. taxonomy-$taxonomy-$term, taxonomy-$taxonomy, and taxonomy), _and_ the root taxonomy route we're seeking to implement in this PR 🙂

BTW as discussed on our call the other day, extending the template hierarchy isn't particularly complex, but very cumbersome, and there are a few different ways to do that. I started implementing that as part of this PR but have now removed the relevant commits. I'd rather tackle that in a separate PR so that this one can solely focus on enabling the root taxonomy _routes_, without involving the template hierarchy yet.

I'll update the PR description accordingly.

The ​Query Monitor plugin has come in _very_ handy while working on this.