July 2007 - Development - lists.drupal.org

using UID 1 (was Re: Overriding node_db_rewrite_sql())
by Greg Knaddison - GVS 27 Jul '07

27 Jul '07

On 7/26/07, Ken Rickard <agentrickard(a)gmail.com> wrote: > Development testing should never be done as user #1 unless testing > installation or update routines. In fact, nothing but install and update > should be done as user #1. > > See http://drupal.org/node/22284 I see your point here about how it has been confusing to Ron that uid1 could see everything, but I'm not sure I follow the rest of the logic. To me, I don't see a problem with using uid1. I know lots of folks feel strongly about this, but there's also a prominent case[1] or two[2] of smart people doing otherwise. There is even the whole masquerade code in the devel module which makes it easy to switch between uid1 and a normal user during development to facilitate Ron's exact situation. Just yesterday I edited bullet item 1 on 22284 to include all of the arguments on this issue that I was able to glean from the folks that were in IRC when I was digging into the issue. Given that investigation and rewrite, I don't understand the strength of the "don't use uid 1" argument. So, if folks feel strongly one way or another could they please edit that page (or respond here) with some of the reasons why you should "never use user #1". If you're going to say "for the same reasons as you never use root on unix" then please take the time to enumerate those reasons - I'm not sure I believe that comparison so having the list of reasons would help the discussion. Regards, Greg [1] http://drupal.org/user/1 [2] http://groups.drupal.org/user/1 -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg

8 7

Drupal 5 incremental release?
by Caleb Gilbert 27 Jul '07

27 Jul '07

I have no explanation for it - but whatever the reason, either my own stupidity earlier, or if something changed between then and now - the newly released Drupal 5.2 isn't causing the spam.module to disappear as I reported earlier concerning 5.x-dev - and everything else on the site seems to be working very well atm. Just thought it would be good to let anyone who read the earlier part of the thread know. As always, awesome work Drumm and the rest of the core Drupal contributors. :) - Caleb

1 0

Overriding node_db_rewrite_sql()
by Ron Parker 27 Jul '07

27 Jul '07

Currently, I patch the node.module's node_db_rewrite_sql() function. What I would like to do is take this functionality and put it into a separate custom module so that I don't have to patch the core module. I was advised to take the code, place it in my custom module, and weight my custom module heavier than the node module. Tried that, but I'm getting some serious errors. Here is essentially what I'm trying: Taking the same node_db_rewrite_sql() code and placing it in my custom module: function og_user_roles_db_rewrite_sql($query, $primary_table, $primary_field) { if ($primary_field == 'nid' && !node_access_view_all_nodes()) { $return['join'] = og_user_roles_node_access_join_sql($primary_table); $return['where'] = og_user_roles_node_access_where_sql(); $return['distinct'] = 1; return $return; } } function og_user_roles_node_access_join_sql($node_alias = 'n', $node_access_alias = 'naa') { if (user_access('administer nodes')) { return ''; } $return = 'INNER JOIN {node_access} '. $node_access_alias .' ON '. $node_access_alias .'.nid = '. $node_alias .'.nid '; ... my customizations follow ... This actually appears to work for normal authenticated users. However, user #1 is getting ALL nodes listed in every view everywhere. The second problem I've run into is that for certain users, they now get "access denied" error when trying to access content they should have access to. It's like my permissions table got screwed up somehow, but I don't know how to fix it. Help, please! -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com

6 9

Re: [development] Overriding node_db_rewrite_sql()
by Ron Parker 27 Jul '07

27 Jul '07

Many thanks to everyone who responded to my problem. After about the 3rd or 4th email mentioning the special case for user #1, I finally realized what I needed to do. I also wish to respond to some of the issues brought up as a result of this discussion. The solution I made the following modification to the first line, and it worked: if ($primary_field == 'nid' && !node_access_view_all_nodes() && !user_access('administer nodes')) { Overriding node_db_rewrite_sql() David Cohen wrote: i'll go further, and suggest that you should not implement that hook in your module either. you want to restrict nodes using the node access API, just like og itself. See the example node_access module on api.drupal.org I'm sure you're right. This particular issue is part of a larger effort I've embarked on to make different access control systems work together. See: http://groups.drupal.org/access-control. Yes, OG uses the node access API for OG permissions, but what I am trying to do is make OG work with TAC and Content Access. Actually, I have done this. http://groups.drupal.org/node/3700 But, right now, I have to patch core and contributed modules. This effort here is about moving the functionality of that patched code into a separate module altogether. So, in order to not have to patch core code, I have to override the default hook_db_rewrite_sql() functions from a separate custom module. Why not use node access API, just like og itself? I am very familiar with the node access API from my work on OG User Roles: http://drupal.org/node/87679 The way the default system appears to work is to determine whether Module A or Module B or Module C says a user can have access to a node. In order to make OG User Roles, OG, TAC and CA work together, I need to be able to say: Allow the user access if Module A AND (Module B OR Module C ) says it's ok. If someone knows how to accomplish this with node grants, and is willing to work with me, I am all ears. The way I figured out how to do it was by using the "Extensible Node Access/Authoriisation Capability" patch: http://drupal.org/node/122173. This same mechanism is discussed here: http://drupal.org/node/143075. Many of us hope it finds its way into Drupal 6. Anyway, this patch helps me refine node access to my exact specifications. And, it works. However, as you know, node_access only handles create/view/update/delete requests and NOT list requests. In order for node listing to match node access in my environment, I needed to modify the node_db_rewrite_sql() function (as well as the hook_db_rewrite_sql() functions in OG and TAC). I did that, and I've had this wonderful cooperative environment working for a few months now. Using user #1 for development testing Honestly, I think the only reason I do this is because it's what I'm used to. I can see and do everything I need to quickly and easily. Besides, if I wasn't in this habit, I probably wouldn't have noticed the problem with my hook_db_rewrite_sql() code, at least not right away. -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com

1 0

Forum module bug challenge
by Earl Miles 25 Jul '07

25 Jul '07

There's a bug in forum.module that I wanted to fix this cycle, and I realize I am not going to get to it. I've got entirely too many things on my plate (Views 2, I'm looking at you) and I need to divest myself of some of these things I want to do. However, this one is important. template_preprocess_forum_topic_navigation (formerly theme_forum_topic_navigation) has this *really* awful query in it: function template_preprocess_forum_topic_navigation(&$variables) { $output = ''; // get previous and next topic $sql = "SELECT n.nid, n.title, n.sticky, l.comment_count, l.last_comment_timestamp FROM {node} n INNER JOIN {node_comment_statistics} l ON n.nid = l.nid INNER JOIN {term_node} r ON n.nid = r.nid AND r.tid = %d WHERE n.status = 1 ORDER BY n.sticky DESC, ". _forum_get_topic_order_sql(variable_get('forum_order', 1)); $result = db_query(db_rewrite_sql($sql), isset($variables['node']->tid) ? $variables['node']->tid : 0); $stop = $variables['prev'] = $variables['next'] = 0; while ($topic = db_fetch_object($result)) { if ($stop == 1) { $variables['next'] = $topic->nid; $variables['next_title'] = check_plain($topic->title); $variables['next_url'] = url("node/$topic->nid"); break; } if ($topic->nid == $variables['node']->nid) { $stop = 1; } else { $variables['prev'] = $topic->nid; $variables['prev_title'] = check_plain($topic->title); $variables['prev_url'] = url("node/$topic->nid"); } } } To summarize: It runs a query to find every post in the current forum, then counts its way through to your current post, then looks 1 ahead to see what the next/previous posts are. If you have thousands of topics in your forum, this is extremely inefficient. This can be much more efficiently done in two queries where you do a limit 1 and do > on one and < on the other, using the sort criteria, to determine what next/previous is. For example, if you're sorting on created, you do a SELECT nid FROM node WHERE [sufficient clauses to restrict to just this forum] WHERE node.created >= $node->created AND node.nid <> $node->nid LIMIT 1 And reverse it to find the previous. Here's the challenge: Write the patch to fix this, cause this needs to happen. I checked the issue queue and I don't see an issue for it.

8 8

Taxonomy: Multiple parents?
by Konstantin Käfer 25 Jul '07

25 Jul '07

Hi, the taxonomy.module provides a way to make term descendant to multiple independent terms (multiple parents). Does anyone use this kind of functionality, and what for? Konstantin Käfer – http://kkaefer.com/

15 22

Drupal 5 incremental release?
by Caleb Gilbert 24 Jul '07

24 Jul '07

> You said the current 5.x-dev breaks with contributed > modules. But you don't see a reason not to release it?! > > It's been quite common that contributed modules have required some updating along with the Drupal core upgrades (even the incremental ones). If there is a new policy which says that a Drupal core upgrade should never result in any contributed modules being broken, that seems like a new precedent. Many people will welcome the backwards compatibility, but I it seems like a lofty goal given the many changes to the codebase and/or database.

11 12

Re: [development] Taxonomy: Multiple parents?
by Gord Christmas 24 Jul '07

24 Jul '07

Another question about the validity of multiple parents I have been wondering about is that if you select one of the eel terms they are both selected next time you edit again. This as we all know is due to the fact that the tree for a selection is not stored. I only really noticed this writing Taxonomy Super Select and thinking it was a bug in my code. If this is the functionality and you are really only tagging a term and not it's path how is it useful? Aside from classification inconsistencies as well. Gord.

2 1

FAPI execution order cheat sheet
by Karen Stevenson 24 Jul '07

24 Jul '07

I'm trying to figure out just what order various FAPI elements get executed in (#process, #after_build, #validate, #submit, #access, etc.) so I can determine just where I want to insert my custom functions, and I got to wondering if anyone has put together a list of the order things those elements get fired? It would be a very handy little cheat sheet if it exists. What would be really handy is a flow chart of the FAPI processing -- an illustration of exactly what happens and in what order -- but I'd settle for a simple list. Just wondering if anyone has already done this for a training program or something (or maybe has at least the beginnings of something like this) and would be willing to share :-) Thanks! Karen

3 2

Re: [development] Absence - Baby
by Piermaria Maraziti 23 Jul '07

23 Jul '07

At 21.25 23/07/2007, you wrote: >with Karlijn and the baby as possible. I don't know what life will >be shortly after our son or daughter is born, but time permitting, I >might actually be around to help and to get some Drupal work done. It's strange that my first message here (hi all) is something which have nothing to do with Drupal but I wish to let you know that with my first son I increased my nocturnal activity on Internet (and programming) because he liked to sleep on my arms while I was at the keyboard... :-) so perhaps you won't disappear for too much! Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria(a)maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it

1 0