April 2007 - Development - lists.drupal.org

Re: [development] Accessing CCK field data (single, multiple, or shared) from another module
by Karen Stevenson 04 Jun '07

04 Jun '07

To find the right table for a field for a SQL query, use the API, like this: $db_info = content_database_info($field); $table = $db_info['table']; That will always return the right table for the requested field. $field needs to be the complete field array, not just the field name, so if you only have the field name, you would do: $field = content_fields(my_field_name); $db_info = content_database_info($field); $table = $db_info['table']; content_database_info($field) also contains info about the columns declared by the field so you know what field names to use in a SQL query. It returns an array that looks like: Array ( [table] => content_type_story [columns] => Array ( [value] => Array ( [type] => varchar [length] => 50 [not null] => 1 [default] => '' [sortable] => 1 [column] => field_phone_value ) [value2] => Array ( [type] => int [length] => 10 [unsigned] => 1 [not null] => 1 [default] => 0 [column] => field_phone_type ) ) ) ----- Original Message ---- From: Rob Barreca <rob(a)electronicinsight.com> To: development(a)drupal.org Sent: Thursday, March 22, 2007 7:55:31 PM Subject: Re: [development] Accessing CCK field data (single, multiple, or shared) from another module > > Is there a function for getting the data that you can just give a node > type and a field name and it handles the rest? This is something I've just run into as well. I have a hardcoded to query the DB for the multiple field table, but have a TODO in there to find the right API call. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob(a)electronicinsight.com Benjamin Melançon wrote: > Gracious developers, CCK people especially... > > I wrote an access control module that works with the node relativity > module to cascade permissions to all nodes lower in a hierarchy. I > hard-coded a query for a userreference field on a custom content type > as one way to give a user access to a node (and its descendants). > > In generalizing this, the current stumbling block is the way CCK > stores single instances in the content data table and shared instances > of a field in a separate table. > > Is there a function for getting the data that you can just give a node > type and a field name and it handles the rest? > > Or is there a place to check what the case is for a particular field? > (Even a "column_exists()" function would do it for me, but haven't > found one in PHP...) > > It's being developed in Drupal 5 and fixing this (as well as saving > explicitly permitted users when creating a new node) is all that's > needed for posting the project for general use. > > Many thanks, > > ben > > Agaric Design Collective > Open Source Web Development > http://AgaricDesign.com/ > > People Who Give a Damn > building the infrastructure of a network for everyone > http://pwgd.org/

5 4

multilanguage patches in need of attention
by Gabor Hojtsy 28 May '07

28 May '07

Hi, I started to collect (and intend to keep up) a list of multilanguage interface and content support related core patches which are in a state where you can review code and/or at least provide your opinion on the code present there: http://groups.drupal.org/node/3714 There are impressive stuff in there like t() for JavaScript strings and node language support. Please look there for a few interesting issues to look at if you are like: 'dude, I have a lot of spare time, but what patch do I choose to review, let me see...'. ;) Gabor

3 2

Beware of static and unset together
by Karoly Negyesi 14 May '07

14 May '07

Hi, So says the PHP manual about unset "If a static variable is unset() inside of a function, unset() destroys the variable only in the context of the rest of a function. Following calls will restore the previous value of a variable." This will lead to really weirdo stuff if you have: function foo($refresh = FALSE) { static $storage; if ($refresh) { echo "refreshing\n"; unset($storage); } if (!isset($storage)) { $storage = microtime(); } return $storage; } echo foo() ."\n"; echo foo(TRUE) ."\n"; echo foo() ."\n"; Observe how the third and the first results are the same as if the refresh did not happen. As Drupal often uses such constructs. Use $storage = NULL instead of unset, for example -- or some other appropriate initial value like '' or array(). list_themes() in core for example has been biten by this, thanks goes to dww for reporting it. The patch is at http://drupal.org/node/134161 btw. I think it's better known that if you have global $x; unset $x; then $x will be unset only in local scope, as global $x is same as saying $x = &GLOBALS['x']; The above issue is actually the same because -- according to my knowledge -- static is a global which has a special flag 'you are only visible to function foo', so basically you have $storage = &$GLOBALS['_static']['foo']['storage']; and then you destroy this reference (of course GLOBALS['_static'] does not exist, I just used it for illustration). Regards, NK

12 15

Why do we avoid auto-incrementing db columns?
by Barry Jaspan 03 May '07

03 May '07

Could someone either clue me in or point to a prior discussion about why Drupal avoids using auto-incrementing database columns? If it is database compatibility, which versions of which databases that we support do not have it? Thanks, Barry

21 37

Sign-up procedure
by Karthik 02 May '07

02 May '07

In a site with ~33000 users, I found that about ~1900 sign-ups were never completed and essentially clutter up the user table. I am looking for opinions on the pros and cons, if any, of streamlining the default sign-up procedure to: a) Sign-up form only contains an e-mail field that the user fills in to confirm authenticity. b) The e-mail field is stored in a separate table along with the sign-up URL token. c) The sign-up e-mail contains nothing besides a sign-up URL which the user clicks as opposed to the current e-mail which contains a number of choices. d) The user is presented with a web page where he selects his username, password and assorted details (other than his e-mail for the first time) and is logged in immediately. e) Only after successfully completing step d) is the user account added into the user table. f) Perhaps an e-mail is sent upon successful completion of the procedure for future reference. Thanks, -K

8 11

Re: [development] aggregator2 update path complete!
by Ken Rickard 02 May '07

02 May '07

>> (Half kidding. It would be great if all who work on aggregator stuff >> unify their efforts on such an API). Already there. See http://groups.drupal.org/node/3528 (or the original post at http://drupal.org/node/130942) Aron Novak's SoC project also addresses this, turning Aggregator module into an API with standard library for parsing, but opening up a pluggable architecture for other modules to replace/extend. I believe that all the aggregator-type module authors are on board with the new API concept. If you haven't read the proposed API, now is a good time... - Ken Rickard agentrickard

6 11

Increase performance of caching
by Jeff Fillmore 02 May '07

02 May '07

Dear Developers, I’ve been working with a few modifications to the caching system of Drupal, and have found a simple way to speed it up by about 5% across the board ( more with pages that use the cache system more) with only adding five lines of code. I found that Drupal was calling the cache table multiple times to get the same data so I put the data in a static array. At the top of cache_get function in includes/cache.inc I added these four lines on line 15: static $cache_array = array(); if ($cache_array[$key] != null){ return $cache_array[$key]; } Right before $cache is returned I added this line on line 45: $cache_array[$key]=$cache; I am sure there are lots of other ways to do this, but the reason that I modified the core code directly is that I felt that this type of increase should not a matter of adding a new module, if it is even possible with another module. Although this will increase the overall size of the apache children during runtime I felt that it was a small price for the speed of the application and overall user throughput. Also are there any other places that we could do something similar. For instance cache the menus in memory for the ‘drupal_lookup_path’ for instance. Because this is in the caching for registered and anonymous users the benefit is across the board. Although the increase will diminish over the size of the site, it should be a rather substantial increase for about 70-80% of the drupal installs out there. I am curious to hear feedback as to what you guys think of this addition, and the overall speed increase and offsets. And potentially other increases that would be of similar avenues and if we should pursue them. Thanks Jeff Fillmore HYPERLINK "mailto:jfillmore@sublimenet.com"jfillmore(a)sublimenet.com Sublimenet INC 208-323-9451 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007 9:14 AM

5 5

Re: [development] Increase performance of caching
by Larry Garfield 01 May '07

01 May '07

Drupal uses a lot of static caching, so in concept I don't see a problem with this. Benchmarks would be useful, though, both on speed and memory usage. That said, this should be submitted as a feature request patch against Drupal 6 so that it can be reviewed in the issue queue rather than on the dev list. See: http://drupal.org/node/320 http://drupal.org/patch/create Thanks! --Larry Garfield On Mon, 30 Apr 2007 11:22:04 -0600, "Jeff Fillmore" <jfillmore(a)sublimenet.com> wrote: > Dear Developers, > > > > I’ve been working with a few modifications to the caching > system of Drupal, and have found a simple way to speed it up by about 5% > across the board ( more with pages that use the cache system more) with > only adding five lines of code. > > > > I found that Drupal was calling the cache table multiple times > to get the same data so I put the data in a static array. > > At the top of cache_get function in includes/cache.inc I added these four > lines on line 15: > > > > static $cache_array = array(); > > if ($cache_array[$key] != null){ > > return $cache_array[$key]; > > } > > > > Right before $cache is returned I added this line on line 45: > > > > $cache_array[$key]=$cache; > > > > I am sure there are lots of other ways to do this, but the reason that I > modified the core code directly is that I felt that this type of increase > should not a matter of adding a new module, if it is even possible with > another module. Although this will increase the overall size of the apache > children during runtime I felt that it was a small price for the speed of > the application and overall user throughput. Also are there any other > places that we could do something similar. For instance cache the menus in > memory for the ‘drupal_lookup_path’ for instance. > > > > Because this is in the caching for registered and anonymous users the > benefit is across the board. Although the increase will diminish over the > size of the site, it should be a rather substantial increase for about > 70-80% of the drupal installs out there. > > > > I am curious to hear feedback as to what you guys think of this addition, > and the overall speed increase and offsets. And potentially other > increases that would be of similar avenues and if we should pursue them. > > > > > > Thanks > > > > Jeff Fillmore > > HYPERLINK "mailto:jfillmore@sublimenet.com"jfillmore(a)sublimenet.com > > Sublimenet INC > > 208-323-9451 > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007 > 9:14 AM > > >

3 2

FormHelp Module Idea
by David Metzler 01 May '07

01 May '07

After about the tenth time one of my business persons asked me to modify the description associated with one of my modules form fields, I got to thinking that I might want to leverage form_alter to modify the titles, descriptions and add links to the help documentation for all modules. The strategy I was thinking of is to have hook_form_alter modify the fields based on help data stored in the database. If the user had privileges, they would see links to modify each field displayed on the form in a "wiki" like way. I'm emailing the dev list to ask. 1. Is this a good idea or a bad one given future forms/ internationalization directions? 2. Is someone else working on a similar issue in a different (or same) direction? About to try and code a prototype..... Dave

4 5

Vocabulary description
by Karthik 01 May '07

01 May '07

Do any modules actually use the vocabulary description field for any purpose other than .. description? The textfield description states "Description of vocabulary; can be used by modules". -K

4 4