The attached fix wants to add a new feature to taxonomy.module: the ability to filter data also on node types.

This is a need when you have to share one vocabulary between multiple node types.
One example is the vocabulary 'Geography', containing all Cities and Regions. You could have events, stories and other custom made node types, sharing this vocabulary.
The need arises when you want to see only events of a certain region; if you filter only on region, you'll see also stories and the other custom node types.

The new syntax is the following:

taxonomy/term/term1,term2,term3(nodetype1,nodetype2)/........

to filter based on three terms (in OR each others) and on two different node types

or

taxonomy/term/term1+term2+term3(nodetype1,nodetype2)/........

to filter based on three terms (in AND each others) and on two different node types

The rest of the syntax for taxonomy/term remains the same, and the patch works also for taxonomy feed.

Node types are tested for validity. You can specify one or more node types; if you omit node types, normal term filtering is issued.

Feedbacks and help testing this patch is needed; personally, I think this would improve temendously taxonomy functionalities, and hope this will be committed to Drupal core.

Feel free to contact me by mail: m dot ferrari at tiscali dot it

Matteo

CommentFileSizeAuthor
#31 my_taxonomy_select_nodes.phps2.55 KBBèr Kessels
#8 taxonomy_nodetype_CVS.patch4.05 KBmatteo
#5 taxonomy_nodetype_452.patch4.43 KBmatteo
taxonomy_nodetype_filter.patch5.46 KBmatteo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

see http://drupal.org/node/5040

matteo’s picture

matteo CreditAttribution: matteo commented

I agree with you that this is an old story, but nothing has been committed to 4.5, that introduced also a new taxonomy syntax.

My patch has also some pluses:
- it is specific for 4.5 and takes care of the new taxonomy syntax
- it lets you specify multiple node types
- syntax is clean

Matteo

robclay’s picture

robclay CreditAttribution: robclay commented

Will this work with 4.5.2?

If so - I am looking for exactly this funcionality!

matteo’s picture

matteo CreditAttribution: matteo commented

I'll work on a port for 4.5.2 hopefully next week...
I'll keep you informed.
Matteo

matteo’s picture

matteo CreditAttribution: matteo commented
FileSize
taxonomy_nodetype_452.patch4.43 KB

Here is the patch that adds nodetype filtering capabilities to 4.5.2 taxonomy module.
Syntax is backwards compatible, so if you plan not to use node type filtering, syntax does not change at all.
(see previous postings in this thread)

I would need extensive testing and feedback... and hope this functionality will be included into Drupal core.

Matteo

Steven’s picture

Steven CreditAttribution: Steven commented

New features only get added to the HEAD branch... you'll have to update your patch.

matteo’s picture

matteo CreditAttribution: matteo commented

Ok, Steven,
I'll rewrite the patch also for CVS....
Thanks

Matteo

matteo’s picture

matteo CreditAttribution: matteo commented
FileSize
taxonomy_nodetype_CVS.patch4.05 KB

Here is the patch for Drupal CVS.
I noticed the great addition of node_rewrite_sql... very powerful...
I'm starting extensive testing on the patch, and I really woul like it to be added to core taxonomy, because it becomes a must for several sites...
Matteo

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

I'd rather see this done universally (not just for taxonomy urls) using the new sql rewrite capability. specifically, some code will implement the rewrite_sql hook and look for a querystring param &ntype=blog,story and then inject the proper WHERE clause. this will be very useful for tracker, home page, taxonomy urls, etc.

Dries’s picture

Dries CreditAttribution: Dries commented

Before looking at the code (which violates Drupal's coding style), what do people think about the proposed URL scheme?

Can anyone tell me why we use 'taxonomy/term/$foo' and not just 'taxonomy/$foo'?

How about we change that to:

taxonomy/all/$foo (or taxonomy/$foo)
taxonomy/forum/$foo
taxonomy/forum,book/$foo

... instead of the proposed URL scheme? It looks slightly more readable to me.

(Does anyone know what 'synonyms' are for, and whether they could solve this problem? Really, I have no idea what these are for, even after having read the documentation.)

jvandyk’s picture

jvandyk CreditAttribution: jvandyk commented

Synonyms are useful for things like organisms, which have both a common name and a scientific name. That's the idea of synonyms, not necessarily the Drupal implementation of synonyms, which we plan to use but are not yet using.

Steven’s picture

Steven CreditAttribution: Steven commented

Can anyone tell me why we use 'taxonomy/term/$foo' and not just 'taxonomy/$foo'?

I believe this is because when the URL changes were discussed, there was talk of a 'taxonomy/vocabulary' page which would display an overview of a vocabulary. But I think that role has already been filled by a contributions module.

Prometheus6’s picture

Prometheus6 CreditAttribution: Prometheus6 commented

If

taxonomy/$foo

retrieves all node types then I think

taxonomy/$foo/forum
taxonomy/$foo/forum,book

is the cleanest looking way to be specific. Give it a fixed position because it will always be there whereas the node type may or may not be.

Steven’s picture

Steven CreditAttribution: Steven commented

This could be hard to implement as $foo is a multi-var path. e.g. "taxonomy/terms/1" "taxonomy/terms/1/1" "taxonomy/terms/1/0/feed" etc.

Prometheus6’s picture

Prometheus6 CreditAttribution: Prometheus6 commented

How about:

taxonomy/$foo,$bar
taxonomy/$foo,$bar/forum
taxonomy/$foo,$bar/forum,book
taxonomy/$foo,$bar/forum/feed

matteo’s picture

matteo CreditAttribution: matteo commented

Personally, the proposed syntax is not important, but the functionality is VERY important, so, the actual code for this patch can be revised to adapt to a different syntax.
I chose that syntax since now the syntax is:

taxonomy/term/term_ids/level

so if you want to add node types to that syntax, level must be explicitly set, while now it is not mandatory:

taxonomy/term/term_ids/level/nodetypes

As you can see from the code, it is very simple, but powerful, and compatible with the actual syntax.

Once we decide for the syntax, I'm available, if you need, to write some code for it.

Matteo

Steven’s picture

Steven CreditAttribution: Steven commented

Neither of your suggestions would work actually. The comma is already used as a term id separator, while matteo is forgetting about the /feed op ;).

PS: Please mind HTML usage next time. You didn't close a blockquote, which has messed up the theme. And we can't edit it, as there is no edit function for issues :(.

matteo’s picture

matteo CreditAttribution: matteo commented

I did not forget of /feed, in fact it is working fine with the actual syntax, as you can see testing the actual syntax.

What about a syntax like this ??

taxonomy/term/term1,term2,term3&ntype=nodetype1,nodetype2/........

to filter based on three terms (in OR each others) and on two different node types

or

taxonomy/term/term1+term2+term3&ntype=nodetype1,nodetype2/........

to filter based on three terms (in AND each others) and on two different node types

I also agree with Moshe about the possibility to inject the parm somewhere, but I think this would require longer times and testing.

Matteo

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

Dries, the /term/ part is included so that other schemes can be implemented, which are not based on term ids. Like term name support, or node type support or vocabulary support. The vocabulary list module mentioned by Steven was my contribution, since I felt the need (and even found a TODO comment in the taxonomy code, which said that this is to be implemented in core). I think vocabulary listing belongs to core by the way.

Steven’s picture

Steven CreditAttribution: Steven commented

I really don't like the look of "&ntype=...". Plus, the ampersand is likely to cause problems with non-clean URLs.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

The &ntype=x syntax would always be a querystring no matter if clean urls would be enabled or not. This is analogous to our pager and table sort links. I agree that this isn't especially pretty, but it lets us limit pages by node type for all sorts of pages (tracker, home page, taxonomy, ...) using a standard syntax. the 'clean url' way would make each module implement its own syntax for node type filtering.

Steven’s picture

Steven CreditAttribution: Steven commented

Doesn't that mean that you could not URL alias the resulting pages? This is a big disadvantage IMO...

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

No way. If that were true, you couldn't use a pager or a sortable table on an aliased page. The alias system only cares about $_GET['q']. All other querystring params are ignored.

Steven’s picture

Steven CreditAttribution: Steven commented

Err, what I meant is, you couldn't get rid of the ntype if you wanted to (e.g. if you want to alias a particular "taxonomy terms + node type" combo to a single, simple URL).

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

good point. I hadn't thought of that. maybe we could fid a way to allow aliasing of urls that have querystring params. whose the url aliasing guru these days? jonbob?

Anonymous’s picture

(not verified) CreditAttribution: commented

The filtering should be top-down:
'taxonomy > Taxonomy > Term(s) w. operator > Depth > listing type > node type(s)

listing type would be "teaser", or "feed" (new types like tables full-nodes etc can be introduced later)
node type, is the node type.

it would translate in a path like:
taxonomy/2/0/all/feed/blog,forum/ (will show all blogs and forums in vocabulary 2, in xml feed)
taxonomy/0/1,4,6/all/teaser/blog,forum/ (will show all blogs and forums in terms 1, 4 or six, as teaser-view)

Where 2 is the voc. id. (usefull, to call a complete vocabulary, in whic case the tids will be ignored)

That is my idea, disregarded any technical implementation: I only looked at consistancy and the most future-proof scheme.

Anonymous’s picture

(not verified) CreditAttribution: commented

that was me, forgot to log in :(

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented

GRR. some funny local cahce and cookie problem. It showed me logged on, but i was not. above two comments were mine. Sorry for the spam.

matteo’s picture

matteo CreditAttribution: matteo commented

I like your proposal, even if I would omit the vocabulary_id as a parameter, since it is less used in search.
That kind of syntax would be very simple to analyze and transform into a query.
At that point, any module like taxonomy_html, taxonomy_dhtml etc. could create URLs like that to help user in the navigation.

+1 for it...

matteo’s picture

matteo CreditAttribution: matteo commented

Hi all,
I appreciated very much this thread, since it seems that this need is 'hot', however, I absolutely need this feature now for my new Drupal site, so, since it is not clear to me when and how this feature will be added to Drupal core, I will go on with my Srupal 4.5.2 site with my patch applied to taxonomy, but I'll be ready to help or test any othe solution ttha will add this functionality.
Please let me have some feedback on thius matter...

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented
FileSize
my_taxonomy_select_nodes.phps2.55 KB

FWIW I had the attached snippet in my snippet library. Its an improved aPI for selecting nodes.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

tentatively marking as fixed. see see node_type_filter.module in Contrib. for 4.6 only.

Anonymous’s picture

(not verified) CreditAttribution: commented