Expanded taxonomy module URL capabilities

The attached patch allows two new taxonomy searches:

The first is by vocabulary id. For example, to view all nodes with terms in vocabularies 1,2 or 7, you can go to:
taxonomy/vocab/or/1,2,7

Or, conversely, to view all nodes that have terms in vocabularies 1,2 and 7, you can go to:
taxonomy/vocab/and/1,2,7

The second new search is recursive, specify a term id and it will return nodes comprised of that term and all its children:
taxonomy/children/or/8

See earlier in this thread for more detail.

How it works:
if 'vocab', builds list of all tids in that vocab, then passes list to existing display logic.
if 'children', builds list of all children tids, then passes list to existing display logic.

+1

My only request would be to use 'vocabulary' rather than 'vocab'. Nothing else (taxonomy, children, etc.) is abbreviated. Let's be consistent.

> taxonomy/vocab/or/1,2,7

why not use full name eg

taxonomy/vocabulary/or/1,2,7

you do not use "taxo", don't you? :)

Thanks Jeremy!

There was a very recent thread where someone was looking for this feature. I'd like to see it implemented as well. I'll try it out when I get home.

recent thread

Updated patch.
- fixed bug which caused error if entered invalid vid
- renamed 'vocab' to 'vocabulary'

When implementing my patch on KernelTrap.org I realized that 'taxonomy/children' only displays immediate children, not all descendants.

In other words, take the following example vocabulary:

- a (1)
-- a1 (2)
--- a1a (4)
--- a1b (5)
-- a2 (3)
--- a2a (6)
--- a2b (7)

Using the new children option to display a and its children:
taxonomy/children/or/1
Is currently synonymous with:
taxonomy/page/or/1,2,3

I'll submit another patch to fix this as soon as I have time, which will make the earlier 'children' query synonymous with:
taxonomy/page/or/1,2,3,4,5,6,7
The fix is simple, just recursively finding all children's nids.

I don't know why I didn't discover this conversation earlier; I wrote a patch for this ages ago which might be of interest.

http://lists.drupal.org/archives/drupal-devel/2003-06/msg00623.html

Also see Al Maw's version of the patch:

http://cvs.drupal.org/viewcvs/contributions/sandbox/almaw/for_review/005...

Your patch appears to provide an alternative way to do a similar thing. ie, you extend 'or' and 'and' with 'below'. So if I understand correctly, to list all children of the term with a tid of 4:

taxonomy/page/below/4

The two things missing then compared to my patch would appear to be:
1) the ability to 'and'/'or' the children
2) the ability to list an entire vocabulary

I hope to have time to add the formentioned missing recursion to my patch, probably later today. (BTW: At first glance, it appears your patch also only list immediate descendants?)

This could be handled by adding a depth option, defaulting to all children.

For example:

- a (1)
-- a1 (2)
--- a1a (4)
--- a1b (5)
---- a1b1 (8 )
---- a1b2 (9)
----- a1b2a (10)
----- a1b2b (11)
-- a2 (3)
--- a2a (6)
--- a2b (7)

taxonomy/children/or/1/1 would result in a, a1, a2
(the 1 at the end saying only return 1 level of children)

taxonomy/children/or/1/2 would result in a, a1, a2, a1a, a1b, a2a, a2b
(the 2 at the end saying only return 2 levels of children)

taxonomy/children/or/1/3 would result in a, a1, a2, a1a, a1b, a2a, a2b, a1b1, a1b2
(the 3 at the end saying only return 3 levels of children)

taxonomy/children/or/1 would result in 'a' and all decendants.

(no depth specified, so go to maximum depth)

If anyone has an idea for a better way to specify depth, please let me know.

The attached patch introduces the following two queries, fully described earlier in this thread:

  taxonomy/children/
  taxonomy/vocabulary/

Both queries can be used with 'and' or 'or', followed by the ids you're looking for. Such as:

  taxonomy/children/or/12,23,7
  taxonomy/vocabulary/and/1,2

The 'children' query can be further limited to a specified depth. For example, if only looking for immediate children of a term (and the term itself) then specify a depth of 1:

  taxonomy/children/or/12,23,7/1

Adding depth to 'children' was a logical extension of how the children list is built. Adding depth to 'vocabulary' is possible, but would require the addition of otherwise unused logic/complexity. Therefore, at this time I have not added the ability to specify the depth to 'taxonomy/vocabulary'.

What is required to get this merged into the core? It seems a very logical extension to taxonomy. If there are problems with the implementation, let me know.

I'll repeat my question:
"What is required to get this merged into the core? It seems a very logical extension to taxonomy. If there are problems with the implementation, let me know."

Does this patch also extend the capabilities of taxonomy RSS feeds? For example:

taxonomy/feed/children/or/12,23,7

Jeremy, something that might be of help for those looking for a better taxonomy browser:

http://drupal.org/node/view/8317
and source file at:
http://www.argo-navis.com/misc/index.html

Helmar
mail@argo-navis.com

With the proposed changes for tabs, urls have been changed as well:

old: node/view/[id]
new: node/[id]/view

For consistency's sake, it might be best to adopt a similar scheme for taxonomy:

taxonomy/[selector]/[operation]

It also makes sense in light of possible future permissions changes, where access can be taxonomy based. It would keep the code centralised:
1) Determine which taxonomy items the selector selects.
2) Determine access based on selected items.
3) Perform operation.

What bugs me about the selectors is that you use two different names for essentially the same thing: select only direct descendants (depth 0), children with an arbitrary depth, or the full depth.

Couldn't these be merged into a single depth parameter which would work like this:

* - full depth
0 - only nodes with these terms
1 - nodes with these terms, or their first-level children's terms
2 - nodes with these terms, or their first- or second-level children's terms
3 - ...

The way I see it, it maps like this between the proposed patch and my idea:

old:
taxonomy/page/or/1 (node listing, 0 depth, old drupal behaviour)
taxonomy/children/or/1/1 (node listing, 1 level deep)
taxonomy/children/or/1 (node listing, full depth)
taxonomy/children/and/1,2 (node listing, only nodes with at least 1 term descending from each of term 1 and term 2)
taxonomy/children/and/1,2/2 (node listing, only nodes with at least 1 term descending at most 2 levels deep from each of term 1 and term 2)
taxonomy/page/and/1,2 (node listing, only nodes with both terms 1 and 2)
taxonomy/feed/children/or/1/2 (RSS feed of nodes, 2 levels deep)

new:
> taxonomy/or/1/0/page
> taxonomy/or/1/1/page
> taxonomy/or/1/*/page
> taxonomy/and/1,2/0/page
> taxonomy/and/1,2/*/page
> taxonomy/and/1,2/2/page
> taxonomy/or/1/2/feed

This is for nodes.

You also added a somewhat unrelated change: the ability to show a vocabulary on a page (taxonomy/vocabulary). This is not really related to the function above, so it makes sense to separate it, as a selector 'vocabulary'. The 'and/or' selectors select nodes based on terms, the 'vocabulary' selector would select terms based on vocabulary.
You could even extend it with a similar depth parameter, and also follow it by an [operation], for e.g. showing a simple page of the vocabulary, to showing some XML format (OPML?) for taxonomies.
In this context, it makes sense to allow for an id '*' which means 'all vocabularies', and results in a listing/feed/whatever of all vocabularies (I don't think it's useful here to allow 'and' and 'or' for vocabularies).

old:
taxonomy/vocabulary/3 (display page showing the vocabulary's terms)
taxonomy/vocabulary/3/2 (display page showing the vocabulary's terms, up to 2 terms deep)

new:
> taxonomy/vocabulary/3/*/page
> taxonomy/vocabulary/3/2/page
> taxonomy/vocabulary/*/*/page (show global taxonomy 'sitemap')
> taxonomy/vocabulary/*/0/page (show top level terms of vocabularies)
> taxonomy/vocabulary/3/0/feed (XML feed of the vocabulary structure, only top level terms)

The whole thing can be summarized like this:

taxonomy / [select type]/[id]/[depth] / [operation]

When [select type] = 'and' 'or': select nodes based on terms [id,id,id] up to depth [depth] (with logical AND/OR). Perform [operation] on nodes (e.g. 'page': list nodes, 'feed': give RSS feed of selected nodes, ...).

When [select type] = 'vocabulary': select all terms from vocabulary [id] up to depth [depth]. Perform [operation] on terms (e.g. 'page': show HTML page with vocabulary hierarchy, 'feed': show OPML feed of the vocabulary and its terms, ...). [id] can be '*' which selects all vocabularies.

[depth] is either a non-negative integer (0 = no descendant terms, 1 = first level children, 2 = second level children, ...) or '*' (meaning 'all children').

This system gives all taxonomy URLs a uniform format and on the plus-side, it always keeps the arguments in the same position regardless of the function. It also has a more correct "module > data > operation" flow rather than "module > operation > data".

On the downside, I realize my proposed scheme does reduce URL readability a bit, but I don't like the inconsistencies and redundancies in the current proposed patch: maybe you guys can spot some possible simplifications.

By the way, I'm changing version back to CVS: this really is a new feature which doesn't belong in the 4.4 trunk IMO.

I discussed the changes with JobBob and we agreed with the following simplifications:

- Instead of and/or as selectors, we should incorporate this in the separator used for id's. So "5+6+7" would be OR, "5,6,7" would be AND. Instead of 'and/or' we'd replace this with "terms", which fits better with the "vocabulary" selector idea. This also removes the redundancy between "or/5" and "and/5" which do the same thing.

- Instead of "*" we should use the more readable "all".

- By defining default values for 'depth' and 'operation', we can simplify the most used URLs:
* taxonomy/terms/5 would be the same as taxonomy/terms/5/0/page
* taxonomy/terms/5/all would be the same as taxonomy/terms/5/all/page
* For feeds, you'd have to use the full URL: taxonomy/terms/5/0/feed

- For depth, we can argue whether to use depth 0 or depth 1 for no children. IMO depth implies searching deeper, so depth 0 would be no children. If we use the approach of leaving out defaults, this issue becomes less important though.

Here's an updated summary:
taxonomy / [select type]/[id]/[depth] / [operation]

When [select type] = 'terms': select nodes based on terms [id] up to depth [depth]. [id] can be a list of id's: in that case, the separator determines the logical operation. "5+6+7" is OR, "5,6,7" is AND. Perform [operation] on nodes (e.g. 'page': list nodes, 'feed': give RSS feed of selected nodes, ...).

When [select type] = 'vocabulary': select all terms from vocabulary [id] up to depth [depth]. Perform [operation] on terms (e.g. 'page': show HTML page with vocabulary hierarchy, 'feed': show OPML feed of the vocabulary and its terms, ...). [id] can be '*' which selects all vocabularies.

[depth] is either a non-negative integer (0 = no descendant terms, 1 = first level children, 2 = second level children, ...) or 'all' (meaning 'all children').

When [depth] is omittted, it means "0" (no depth). When [operation] is omitted, the "page" functionality is used (show an HTML page: listing of nodes, tree of vocabulary, ...).

Removing my name from the assignment -- this issue is growing farther and farther from my initial interest/focus.

looks very well thought out to me. nice work.

I'm OK with Steven's suggestion.

Please note this feature request/task, which could (probably) be done at the same time:
http://drupal.org/node/view/4857

I will play with this and try to come up with a solid implementation.

Okay, here's a first step. Not setting to "patch" because it isn't complete. There are a couple of open issues.

The SQL to do an AND query is complicated, and I don't know how best to extend it to accommodate a depth (it becomes an AND of ORs). Any SQL gurus wish to contribute a solution?

The vocabulary pages need to be written. I stalled on this when I realized the earlier iterations of the issue had them displaying nodes, while the later asked for a term listing. What do we want? How should it be presented? The same goes with the feed; how can I find an appropriate format?

Also with regard to the vocabulary pages, an AND here doesn't seem to make sense unless we are selecting nodes. If it is to be a term listing, should we treat both separators the same way?

Some of the functionality discussed here is available in taxonomy_context.module, namely the display of taxonomy descriptions. For an example, see the home page at http://www.gworks.ca. The first five listings ("About Us", "Get Involved", etc.) are the top-level terms in a given vocabulary. I would see vocabulary display working similarly. When viewing a vocabulary, I'd like to see:

Vocabulary description

First-level term name 1

First-level term description 1 teaser

First-level term name 2

First-level term description 2 teaser

...etc.

I'd be interested in working on integrating taxonomy_context functionality into these taxonomy.module changes. Suggestions for where I'd start?

Okay, I've resolved most of the issues by postponing them. :-)

This patch cleans up the existing taxonomy paths and adds the "depth" possibility, but does not address the "vocabulary" function. We need consensus on that before proceeding; this patch opens the door to add such a function in the future, but is complete without it.

As discussed before, the path "taxonomy/page/or/1,2" becomes "taxonomy/term/1+2" and the path "taxonomy/page/and/1,2" becomes "taxonomy/term/1,2". The most common case of listing nodes attached to a single term becomes simpler, since it doesn't require a meaningless "or" or "and". A depth of "0" is assumed, but a positive integer or "all" can be used. Feeds are available at "taxonomy/term/1+2/all/feed" and the like.

This iteration of the patch also changes the structure of taxonomy_select_nodes(), since it was not following Drupal conventions. A handful of contrib modules call this function, and will need to be updated. Instead of passing in a $taxonomy object containing parameters for the function, the parameters are passed independently. This simplifies the code quite a bit. The queries were changed to only return node IDs for speed; all results from this function are passed through node_load() anyway, so the extra information returned was discarded. The AND query was also changed to avoid the strange trick and remove an extra query, at the expense of a table join per root term in the AND. This cleans up the code substantially while at the same time enabling the use of AND with a depth parameter.

Help text has been updated to match. Setting status to "patch", because I believe this is ready now.

Small nit (I haven't looked at the patch yet, neither do I maintain a module that is affected) but '1+2' reads as '1 and 2', where '1,2' reads as '1 or 2'. You explanation suggests that you've done it the other way around.

You're right Dries, and that's the point. The previous 'and' terminology was quite confusing as well. Does 1 and 2 mean all the nodes that have AND term 1 and term 2? Or does it mean the nodes that have term 1 and the nodes that have term 2?

The reasoning behind this scheme is that /1+2+3 displays the sum of /1 /2 and /3, which makes sense I think.

UnConeD: you're rationale makes sense too -- it didn't occur to me to look at it like that.

Another factor to consider is that I'm removing use of the words "and" and "or" in this context altogether. The new help text reads:

To build a Taxonomy URL start with "taxonomy/term/". Then list the term IDs, separated by "+" to choose nodes tagged with any of the given term IDs, or separated by "," to choose nodes tagged with all of the given term IDs. In other words, "+" is less specific than ",".

Please try to avoid the words 'node' and 'nodes' inside the help texts. Instead of that use 'post' and 'posts'..

My 0.02:

-maybe a stupid question/idea but why are we using the words 'taxonomy' and 'terms'? If I'm right a 'taxonomy' is a 'category' and a 'term' is a 'subject' which is part of the 'category'..
- In the help-text we use 'taxonomy' and 'vocabulary' through each other, the same with 'terms' and 'subjectw'.. Can't we unify these to?

I must agree with Dries's original "small nit." Using "+" for OR and "," for AND seems completely backwards and counterintuitive to me. I understand the "sum" argument, but it is still confusing. Personally, I would rather see the "/and" and "/or" stay than putting it in this way. At least that way it is explicit as to what is being requested. I like the other stuff in this patch, I just find the "+" vs. "," thing confusing. :) I think your everyday users will too.

I don't think there is an easy syntax which conveys both 'and' and 'or' meaningfully. A lot of people will think of 'and' differently than a purely logical 'and'.

You go to the store and start filling your trolley. You buy apples, soda and cookies. Your trolley now contains the union of apples, soda and cookies (i.e. logical OR). With this 'and' <-> 'or' confusion in mind, I think the 'sum' idea and syntax makes a lot of sense. It avoids using the word 'and' in an ambiguous context.

For the logical AND, I think it would be best if we could use '&' as an argument separator. However this is bound to cause problems with query arguments, so the old comma was used instead.

I don't expect everyone to agree, but I think it's best if we just pick one system and stick with it. The help text explains the separators, without using the words 'and' or 'or' (instead of using 'any' and 'all'). If people get the usage wrong, they use the other separator.

I do think this solution (selecting by separator rather than keyword) is better than the old one because it avoids the redundant URLs for selecting a single term.

A new patch incorporating some of the help text suggestions. I did not switch the operators at this point.

...and "Choose File" is too close to "Submit", it seems.

I like the proposed patch but I'm putting it on hold for a couple more days so people get to try and comment on it some more. If anything, the new URLs are a lot prettier. ;-)

From JonBobs-patch (several times):
+ $links[] = l($term->name, 'taxonomy/term/'. $term->tid, $term->description ? array ('title' => $term->description) : array());

I would suggest something else here, like: "categories/$term->tid" or "category/$term->tid".. The word 'taxonomy' is to most people not very self-explaining and is imo tech-talk.. "category"/"categories" gives a better view to the new user(s) of what could be expected..

Stefan, I don't think that's really needed. The point of this patch is not to make taxonomy URLs pretty, it's to make them more consistent, while adding depth functionality. We take the approach of naming URLs after the module names and functions everywhere in Drupal, while leaving friendlier text to the UI.

If you want readable URLs, you should probably use URL aliasing and go the whole way (e.g. 'categories/term name' for 'taxonomy/term/X').

Committed to HEAD. Some contribution modules will need to be udpated.

OK, so what is the latest patch for the taxonmoy? Why is it not available in 4.5? Help!?

So, this works on 4.5.2?
What's the current status of this.
Is there any other ways to list a vocabulary and its terms, not just the content on those terms, other than with sitemap, sitemenu and dhtml_taxonomy, which are all great but of no help if you just want to list all terms (not the articles) of a vocabulary in a page?

Interested in what this seems to be suggesting - taxonomy vocabulary, and child terms listed without node content - I stumbled in cvs repositories something that user Mathias is working on for 4.6 called Directory http://cvs.drupal.org/viewcvs/drupal/contributions/modules/directory/ which seems that it would do the job BUT it's not working or workable for 4.5 at present. For me, I so need this functionality NOW! :)

I can't seem to get the directory module working for 4.6 either. I was hoping I could just install it and get some functionality. However, I must be missing something... the site that implemented this directory module looked dang good, so I know it works somehow. I might just have to wait until mathias is done with all the img_assist stuff-- then maybe the module will get some documentation on how to use it. Looking forward to it...

Has any more work went on for this in relation to 4.6.x?

Is it possible in with this patch to combine the logical 'and' and the logical 'or' in one taxonomy URL? What I want is to filter all posts that have one term, combined with term 2 'or' term 3.
Something like /taxonomy/term/(1,2)+(1,3) i.e. /taxonomy/term/1,(2+3)

Is anything like this possible without having subcathegories in my taxonomy (all my vocabularies have depth '0')??? And I want to take care of this with terms from different vocabularies....

Please has anyone suggestions, how to handle this?

Mugel

What happened to adding node types to the taxonomy url constraint syntax?

The patch has been part of core for a long time and certainly won't be backported to 4.5 by now :)
This thread is long, and the patch that had been debated almost to the end has been committed, so I am marking as fixed.

With regard to #52: if this feature is still wanted, open a new issue. I wonder though if this functionality is not already possible with 4.7 with views.module.

I meant #51.