This patch removes support for URLs like taxonomy/term/1,2,3 and taxonomy/term/1+2+3 plus the depth argument from taxonomy module.

Reasons for doing so:

# We have load of special casing in taxonomy term rendering. If we want to show fields on these pages properly and be able to render taxonomy/term/% pages through a template, then we need to be able to have taxonomy-term.tpl.php and taxonomy-term-$vocabulary.tpl.php - for that we need predictable input.

# Those paths are barely documented anywhere and only exist by magic.

# Views 2 can recreate those paths, and also comes with default views which provide the same functionality - and it does so in a much more generic way.

# taxonomy_term_page can now be split into the actual page callback and a separate callback for the feed, and they're generally a bit less spaghetti.

CommentFileSizeAuthor
#3 taxonomy_term.patch9.94 KBcatch
taxonomy_term.patch9.95 KBcatch
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

This is the right thing to do. This hampers progress with fields. But it does sadden me a bit. Its a really cool feature.

tic2000’s picture

// Build breadcrumb based on first hierarchy of first term:
Period at the end. It's the only term, no need to say it's the first one.

Everything looks OK code style wise and it works as it should too :).

catch’s picture

FileSize
9.94 KB

It is a cool feature, and it's one we should bring back into core along with views (even if not switched on by default), but I don't think it's one taxonomy module should maintain by itself without a proper query builder in core, and/or at the expense of other things like templates.

Fixed the comment tic2000 noticed.

chx’s picture

Status: Needs review » Reviewed & tested by the community

*hugs* <3 yay dance party champagne!

Dries’s picture

In general, I support this but some scattered thoughts:

1. Is there an issue for the first bullet item (template files) that I can peek at or not yet?

2. What is more likely? People theming a taxonomy term listing or people to fiddle with the (magic) URLs?

3. I'm surprised that there is no documentation to update. Were these truly magic?

4. In addition to Views, Apache Solr and other modules do faceted search/navigation, allows you to create similar-ish lists. It sounds fair to leave this to specialized modules as they can probably do a better job at it anyway.

5. This might indicate a short-coming in the menu/router system, but I'm not sure I want to complicate it -- it is already difficult as is.

robertDouglass’s picture

Yes! I fully support removing special case rendering from core wherever possible.

David Strauss’s picture

I support the removal of these special paths. They're entirely unscalable, and I've never used them for any project, professional or volunteer.

Anonymous’s picture

It's a really compelling feature, but this is for the best. It's just not up to date.

It won't be hard to build a bridge to this feature in contrib.

rcross’s picture

hmm, i haven't used it all the time, but when i have, it was a necessity that made life so much easier. Makes sense, and I agree about not having special case rendering (that isn't easy to override with templates) but hope this feature stays in core through some other mechanism.

If nothing else, using it on d.o has been helpful sometimes.

Dave Reid’s picture

Yes please. I am sick to death of the mysterious /0 depth on taxonomy URLs. Let contrib shine where contrib should be shining.

catch’s picture

@Dries

1. Is there an issue for the first bullet item (template files) that I can peek at or not yet?

No not yet, but there was discussion in the 'fieldable terms' issue. It's pretty much impossible to even think about adding a template to taxonomy_term_page() without this patch though. I'm not really planning to work on a template, but I'd like to clear the way.

2. What is more likely? People theming a taxonomy term listing or people to fiddle with the (magic) URLs?

I think it's more likely people want to theme it - given taxonomy redirect, views and panels overrrides and modules like directory it's already very common to alter what that page looks like - and pretty much all those options only work with a single term (apart from Views, which is the only reason we can consider removing this at all anyway).

3. I'm surprised that there is no documentation to update. Were these truly magic?

I can't find any mention in taxonomy_help() whatsoever.

4. In addition to Views, Apache Solr and other modules do faceted search/navigation, allows you to create similar-ish lists. It sounds fair to leave this to specialized modules as they can probably do a better job at it anyway.

Yep.

5. This might indicate a short-coming in the menu/router system, but I'm not sure I want to complicate it -- it is already difficult as is.

It certainly simplifies the router handling. Again, views handles paths like this generically, and afaik not just for terms - I'm not sure we need to add anything to the menu system to support stuff like this more cleanly.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD! Thanks.

WorldFallz’s picture

Status: Fixed » Needs work

Not sure if it belongs here or in a separate documentation issue-- but the http://drupal.org/handbook/modules/taxonomy page, which does document this behavior, will need to be updated.

How do we handle handbook page updates for major releases anyway?

catch’s picture

Status: Needs work » Fixed

That should probably be a separate documentation issue, not sure what the process is for major version upgrades of core docs.

However I added a note to the d6/7 upgrade guide about removal of this feature in case any contrib modules are relying on it.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

caw67’s picture

and how can i now save a menu item with more than one term ids as argument? i cant!!!!