Tax Query: Allow querying for all posts with any term of a given taxonomy
Please refer to the Trac ticket for details.
TODO:
- [x] Add rewrite rule to map
/taxto?tax(somewhere around here?)- Some relevant documentation here.
- [ ] Make sure correct template is used (i.e.
taxonomy-$taxonomy,taxonomy,archive, andindex). - [ ] Add test coverage.
- [ ] Consider adding an argument to
register_taxonomyto individually enable or disable "root" taxonomy archives.
Testing instructions
-
For now, go to Settings > Permalinks, and select "Plain" there (and don't forget to "Save changes" -- the button is at the bottom).
-
Add the following code (e.g. to your theme's
functions.php). Create a number of new posts, and use the "Project Types" panel in the block inspector to create a number of "Project Type" terms and assign them to each given post.
Code
function register_taxonomies() {
/**
* Taxonomy: Project Types.
*/
$labels = array(
'name' => __( 'Project Types' ),
'singular_name' => __( 'Project Type' ),
'add_new_item' => __( 'Add Project Type' ),
'new_item_name' => __( 'New Project Type' ),
);
$args = array(
'label' => __( 'Project Types' ),
'labels' => $labels,
'public' => true,
'publicly_queryable' => true,
'hierarchical' => false,
'show_ui' => true,
'show_in_menu' => true,
'show_in_nav_menus' => true,
'query_var' => true,
'show_admin_column' => false,
'show_in_rest' => true,
'show_tagcloud' => false,
'rest_base' => 'projects',
'rest_controller_class' => 'WP_REST_Terms_Controller',
'rest_namespace' => 'wp/v2',
'show_in_quick_edit' => false,
'show_in_graphql' => false,
);
register_taxonomy( 'projects', array( 'post' ), $args );
}
add_action( 'init', 'register_taxonomies', 0 );
- Manually navigate to
/?projects. It should show an archive of all posts that have at least one term from theprojectstaxonomy assigned.
(You can compare this behavior to trunk, where /?projects will 404.)
Trac ticket: https://core.trac.wordpress.org/ticket/61957
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.
Test using WordPress Playground
The changes in this pull request can previewed and tested using a WordPress Playground instance.
WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.
Some things to be aware of
- The Plugin and Theme Directories cannot be accessed within Playground.
- All changes will be lost when closing a tab with a Playground instance.
- All changes will be lost when refreshing the page.
- A fresh instance is created each time the link below is clicked.
- Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance, it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.
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.
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:
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.