WordPress.org

Make WordPress Core

Opened 9 years ago

Last modified 5 months ago

#13816 new feature request

There should be built-in index pages for taxonomies

Reported by: frankieroberto Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: needs-patch dev-feedback
Focuses: template Cc:
PR Number:

Description

By default, if you enable 'pretty' permalinks, you get URLs like this for categories and tags: /category/slug, /tag/slug. The same pattern is used when adding custom taxonomy types.

These URLs often suggest to people that it should be possible to go 'up' one level, and access index pages at /category and /tag which list all of the available categories or tags (or maybe just the top x most popular ones for tags).

I'd suggest that we add a new template type of is_archive_index() which uses, in order of preference, taxononmyname-index.php (eg category-index.php), archive-index.php.

Within these templates, the 'loop' should return taxonomy items rather than posts.

This is all possible already using custom templates and get_terms(), but it'd be handy if it was built-in.

Change History (23)

#1 @uglyrobot
9 years ago

  • Milestone changed from Unassigned to 3.1

+1
I always wondered why there was no index page.

#2 @nacin
9 years ago

  • Milestone changed from 3.1 to Future Release

#3 @scribu
9 years ago

Since this is already possible with the current theme system, I think we should leave it out.

What if I wanted to display all posts that have associated any term in that taxonomy on said index page?

#4 follow-ups: @frankieroberto
9 years ago

@scribu I'm not sure what you mean? Surely the most obvious thing to display at /category or /tag is a list (or tag cloud) of the categories/tags that you use (perhaps in order of popularity).

I'm not saying that this template type should necessarily be included within the default themes, but it would make it a lot easier for theme designers and developers if they could create these pages by simply naming them category-index.php or tag-index.php (or whatever).

#5 in reply to: ↑ 4 @scribu
9 years ago

Replying to frankieroberto:

@scribu I'm not sure what you mean? Surely the most obvious thing to display at /category or /tag is a list (or tag cloud) of the categories/tags that you use (perhaps in order of popularity).

Nevermind, I was thinking of a post type index.

I'm not saying that this template type should necessarily be included within the default themes, but it would make it a lot easier for theme designers and developers if they could create these pages by simply naming them category-index.php or tag-index.php (or whatever).

I agree that it wouldn't hurt. Now we just need someone to come up with a patch. :)

#6 @frankieroberto
9 years ago

  • Component changed from General to Taxonomy

#7 @louyx
9 years ago

  • Cc louyx added

#8 @mikeschinkel
9 years ago

  • Cc mikeschinkel@… added

#9 @deepak.seth
9 years ago

  • Cc deepak.seth added

#10 @WraithKenny
9 years ago

  • Cc Ken@… added

#11 in reply to: ↑ 4 @janfabry
9 years ago

Replying to frankieroberto:

@scribu I'm not sure what you mean? Surely the most obvious thing to display at /category or /tag is a list (or tag cloud) of the categories/tags that you use (perhaps in order of popularity).

I don't know what would be most obvious, I have seen multiple requests for this, and they don't always ask for a list of terms, but instead want the posts linked to these terms.

It would also cause serious compatibility problems for themes that don't have this template. We probably fall back on archive.php or index.php, but these loops expect posts, not terms, and thus most template tags won't work.

Maybe we should implement both ways, and make both of them optional? Add a has_archive argument that would add a post index, and a has_terms_archive argument that would add a terms index. Make them exclude each other or accept a rewrite prefix so they can exist at different locations.

#12 @jazbek
7 years ago

  • Cc j.yzbek@… added

#13 @knutsp
7 years ago

  • Cc knut@… added

#14 @rmccue
7 years ago

+1, I've had to work around the lack of support for this with somewhat hacky code.

#15 @LucasMS
6 years ago

  • Cc ch4cal@… added

#16 @tomdxw
6 years ago

  • Cc tom@… added

#17 @wonderboymusic
6 years ago

  • Keywords needs-patch added

#18 @stevenkword
6 years ago

  • Cc stevenword@… added

#19 @nofearinc
5 years ago

+1 for something that I've needed quite a few times.

Not sure what's the right priority of loading though, given different use cases in #16832 or even #5305 and using post titles that resolve to a year archive. If we decide on the proper priority for the rewrite rules, this would be awesome.

This ticket was mentioned in Slack in #core by sippis. View the logs.


5 years ago

#21 @rileypaulsen
5 years ago

I'm of the opinion that this should bring back posts within [any of the terms in] the taxonomy. All other auto-generated templates like this bring back posts, not hierarchy levels—i.e. different levels of date templates (month, year) query posts within said grouping... they don't return the days in a month or the months in a year.

This ticket was mentioned in Slack in #core by sergey. View the logs.


16 months ago

#23 @tomauger
5 months ago

  • Focuses template added
  • Keywords dev-feedback added

I'd love to revive this conversation as the use case is clear and is something that we have all been working around for years and years: the need for an archive of taxonomy terms, supported as a first-class citizen in the template hierarchy and the rewrite rules.

I still need to review @SergeyBiryukov 's comment in Slack (having a bit of access issues at the moment) to see if there's any additional context, but the main issues I think that need to be settled are:

  1. Is this a taxonomy term archive or a post archive?
  2. What is the nomenclature of the template file name within the template hierarchy?

To sum up: if someone types the following URL: https://mysite.com/taxonomy-name/term-slug, we send them to a taxonomy term archive (taxonomy-$taxonomy-$term.php etc...); if they type https://mysite.com/taxonomy-name/ we 404.

The issue with (1) appears to be (based on comments in this ticket and elsewhere) does mysite.com/taxonomy-name take users to an archive of terms (i.e.: a listing of all the terms within taxonomy-name) or is take users to a listing of all the posts that have at least one term in that taxonomy.

To me, the first option has the most common use cases, and should be the right answer here. https://my-movie-db.org/genres/ should be a listing of all the genres (the taxonomy terms) that have been added to that taxonomy. Presumably, the UX would then allow users to drill down to the individual term archive pages, such as https://my-movie-db/genres/horror/, which is already supported in the current hierarchy.

However, as @rileypaulsen points out, all other templates list posts not taxonomy terms, so there's a bit of a paradigm-bending shift here. Personally, I don't see it as a major issue, but this could be one reason we haven't seen this implemented in core yet.

The second issue is a bit stickier - the naming convention within the template hierarchy, because taxonomy-$taxonomyname.php is already in the hierarchy and is the term-agnostic taxonomy-term archive template (the less specific fallback to taxonomy-$taxonomyname-$termslug.php template). This would have been the most intuitive naming convention.

I think the issues in the preceding paragraphs can be mostly resolved with the following naming convention: taxonomy-terms-$taxonomyname.php and taxonomy-terms.php. The only outstanding issue is that this couldn't logically roll up to archive.php, since that's exclusively for posts. We would probably need to add a top-level term-archive.php template, and I wonder whether this is the reason this ticket has never made it to a patch or a core feature list.

I'm willing to work up a patch, but would love to hear from a core committer, whether this is a non-starter before I invest the time.

Note: See TracTickets for help on using tickets.