May 2007 - Development - lists.drupal.org

Re: [development] Actions in core
by Boris Mann 02 May '07

02 May '07

On 5/1/07, John VanDyk <jvandyk(a)iastate.edu> wrote: > What are actions? <snip> +1, awesome example, someone please copy / paste into the first of the "Actions" handbook pages :P > Another issue is, uh, factoring of Drupal code. Core has a lot of > things that have never been factored out. In our example above, you'd > expect to be able to call a function like user_block_user($uid) so > that the action's 'do' op just becomes a wrapper around existing > functionality. Instead, currently user blocking is done inside > user_save(). So you could say "well, just do user_load(), change the > status, and do user_save() and stop mumbling about factoring!" OK, > that leads me to the next issue. And this "factoring" should lead to CRUD-type functions that can be used easily in install profiles as well.... -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com

2 1

Drupal 6 status update
by Dries Buytaert 02 May '07

02 May '07

Hello, I started writing a Drupal 6 status update for publication on the drupal.org main page. The post is currently unpublished (!) but lives at http://drupal.org/ drupal-6-status-update. I'm inviting all site maintainers to have a look and to extend the post a bit. Many of you can edit the post and might have something to add (if only a link). So please, go ahead and make some improvements and additions. When you do, keep in mind that you're writing for a broad audience and try to avoid developer speak. If you're not sure if something is worth adding, add a note at the bottom of the post. Also make sure to keep the post unpublished. I plan to go over the latest version of the post, wrap it up, and publish it tomorrow afternoon (24 hours from now). Thanks for the help! :) -- Dries Buytaert :: http://www.buytaert.net/

1 1

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

MySQL SELECT COUNT(*) vs. COUNT(col1)
by Khalid Baheyeldin 02 May '07

02 May '07

This is a good article explaining the difference between COUNT(*) vs. COUNT(column) depending on the column you use. http://www.mysqlperformanceblog.com/2007/04/10/count-vs-countcol/ Also, note that InnoDB COUNT is generally slower than MyISAM's always up to date COUNT. -- 2bits.com http://2bits.com Drupal development, customization and consulting.

1 0

Re: [development] Actions in core
by Khalid Baheyeldin 02 May '07

02 May '07

On 5/1/07, John VanDyk <jvandyk(a)iastate.edu> wrote: > > What are actions? > This would be awesome in core. Assigning userpoints for actions will be much easier and much more configurable. Go John go ... -- 2bits.com http://2bits.com Drupal development, customization and consulting.

1 0

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

Primary keys: some are wrong, others are missing
by Barry Jaspan 02 May '07

02 May '07

Currently, Drupal defines primary keys for some of its tables but in practice does not really use or rely on them as primary keys. The Schema module, however, is going to use them. I will soon begin development of Migrate, a module for incremental data migration between Drupal systems, and only tables with primary keys will be able to participate. To that end: 1. node's primary key is wrong. Currently, the primary key of the node table is (nid, vid), and we have a unique index on (vid). I think this is incorrect. Semantically, if a node has nid 12 and vid 30, we do not think of it as "node 12/30", we think of it as "node 12." The path to access it is node/12, not node/12/30. More precisely, the nid is what uniquely identifies the node as an entity; therefore, it needs to be the primary key. So, we can change the primary key to be (nid), add a unique index on (nid,vid), and leave the unique index on (vid) too. There will be no performance consequences or code changes outside system.install. 2. Other tables have no primary key. The tables block, filters, flood, permission, and term_relation have no primary key. They should, and the Schema module will need them to if they are to participate in upcoming functionality. Note that we do not have to change the code to *use* these primary keys, we just need to add them. Since we have now resolved that using auto-incrementing fields is allowed in Drupal, we do not even need to change module code to maintain the primary key. These two changes will require a core schema update with patches in system.install. If there is consensus, I'll submit a patch. Thanks, Barry

4 4

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