[drupal-devel] [feature] Taxonomy rewrite

stefan nagtegaal drupal-devel at drupal.org
Sun Apr 3 19:54:27 UTC 2005


Issue status update for http://drupal.org/node/16452

 Project:      Drupal
 Version:      cvs
 Component:    taxonomy.module
 Category:     feature requests
 Priority:     normal
 Assigned to:  chx
 Reported by:  chx
 Updated by:   stefan nagtegaal
 Status:       patch

Is this considered for 4.6 or 4.7??
I like it!


stefan nagtegaal



Previous comments:
------------------------------------------------------------------------

January 31, 2005 - 00:19 : chx

Attachment: http://drupal.org/files/issues/taxonomy_db_rewrite.patch (6.71 KB)

I'd like to present a use for db_rewrite_sql: taxonomy rewrites. If this
goes through, it will be possible to create an access mechanism,
languages and whatever for taxonomy.
This is a very small change, I think, much smaller than the
node_rewrite_sql megpatch was 'cos at the moment nothing changes. There
are no DISTINCTs deleted. But this opens a door for future things.
Also, this only affects taxonomy.module, 'cos no other module deals
with term_data and vocabulary tables (well, forum.module does, but
those queries does not need a rewrite).


------------------------------------------------------------------------

January 31, 2005 - 03:41 : moshe weitzman

please, let's identify some use cases before we run more queries through
the regex and hooks implied by db_qeury_sql. There might be a good
reason to do this, but you have to convince us.


------------------------------------------------------------------------

January 31, 2005 - 07:49 : chx

In my latest version of db_rewrite_sql, which Dries has not yet
commited, regexs are not executed if not necessary. That version was
created well before Moshe's post, and I'm pretty sure it will pass,
'cos it is not a feature but a bugfix patch actually.
Until there are no implementations of hook_db_rewrite_sql which cares
for primary_field=='vid' or 'tid' , the performance hit is minimal, no
regexps.


------------------------------------------------------------------------

January 31, 2005 - 14:22 : Jose A Reyero

Use cases:
- Permissions for taxonomy terms/vocabs,  some tables and conditions
must be joined for taxonomy queries
- Multilanguage pages/taxonomy (i18n), additional conditions needed
also for taxonomy


------------------------------------------------------------------------

February 1, 2005 - 09:09 : robertDouglass

+1 for being able to put user/role based permissions on vocabularies. I
see this as extremely important (can we do menus too?)


------------------------------------------------------------------------

February 1, 2005 - 11:07 : chx

Yes, we can do menus [1] too. Good idea.
[1] http://drupal.org/node/16542


------------------------------------------------------------------------

March 1, 2005 - 10:08 : tangent

This patch has no effect on term/node access.
1. All roles have been given the "access content" permission.
2. I have removed the "all" grant from the node_access table.
3. I have the "Categories" block visible and it is showing the terms
and number of nodes which are created.
4. Browsing as an anonymous user I can see the same terms and node
count in the categories block that I see as admin.
5. Clicking on a term (/taxonomy/term/2) shows all nodes (and their
content) associated with that term. For example, an image node is
displayed as a thumbnail and a page node is displayed with the teaser.
6. Clicking on the node title (/node/2) displays a "access denied"
message.
Node access is restricted when accessed via node.module but not via
taxonomy.module.
Printing out the sql that is generated after the rewrite in
taxonomy_term_page(), for example, I don't see any joins added so I
guessed that a db_rewrite_sql hook was required for this to be added
since the primary in your patch is "tid".


------------------------------------------------------------------------

March 1, 2005 - 10:14 : chx

tangent, this is not that easy. If you rewrite taxonomy queries, you get
a chance to make a hook_db_rewrite_sql implementation which fires on
$primary_key=='tid'. The only current implementation being
node_db_rewrite_sql fires on 'nid'.


------------------------------------------------------------------------

March 1, 2005 - 10:20 : tangent

I don't understand if you are saying that this is hard to implement or
should be handled in another module. Are you saying that
taxonomy_db_rewrite_sql() is required and needs to fire for 'tid' in
order to restrict access as I thought?


------------------------------------------------------------------------

March 1, 2005 - 12:55 : chx

I have made some documentation on hook_db_rewrite_sql though it does not
showed up yet.


------------------------------------------------------------------------

March 1, 2005 - 20:06 : moshe weitzman

I'd like to see this patch in core. By running taxonomy queries through
db_rewrite_sql() we can achieve two key enhancements:
- access modules can filter out terms to which the current user has no
access. this would complete our implemetnation of private forums. jose
mentioned this earlier.
- taxonomy node listings and feeds could be filtered by node type using
an upcoming simple module which recognizes '&type=event,story'  style
querystrings as a filter. this will work on taxo lists, home page list,
tracker, etc.
there are likely more uses.


------------------------------------------------------------------------

March 1, 2005 - 20:16 : tangent

+1 for me too. The access functionality that this patch enabled is
essential in my opinion and should be in 4.6. Without it, the currently
implemented node access functionality is worthless.
I think the final patch should include a db_rewrite_sql hook to
complete the functionality though.


------------------------------------------------------------------------

March 5, 2005 - 17:43 : Bèr Kessels

+1 from me too. But I would like to see some benchmarking with a
database with loads of terms. If someone volunteers I have a DB with
approx 300 terms and the same amount of nodes in them. Just give me a
private call (berkessels curlythingy gmx dot net) and I might forward
it (if i know you ;).





More information about the drupal-devel mailing list