June 2007 - Development - lists.drupal.org

Aggregation API - SoC project
by Novák Áron 20 Jun '07

20 Jun '07

Hi! First, I would like to say a big thanks for everyone who wrote mails to the "PHP 5 > aggregator.module rewrite to XML API?" thread, I got lots of valuable information from this, and who edited the three wiki pages I've created at http://groups.drupal.org/rss-aggregation. You can find the details of the project at the group which I mentioned and the http://aggregation.novaak.net site. I replied almost all the questions at the wiki pages, please check it out. Yesterday I chatted with Morbus at #drupal-soc room, fortunately we could arrange the viewpoints, I added the summary of his/common ideas to the "Aggregation API requirements - SoC project" (http://groups.drupal.org/node/4624) wiki page. I would like to ask everybody who is involved in aggregation, please let's review / edit the wiki pages where I tried to collect my experiences/test results and every valuable information from the previously mentioned thread. Aron

1 0

version = "$Name$" considered harmful in .info files
by Derek Wright 19 Jun '07

19 Jun '07

Hello world, It was easy to miss this in my last message[1] to the "Announcing cvs_deploy.module" thread, so I'm starting a new one... The only reason we ever recommended people add: version = "$Name$" to the .info files they checked into CVS was for the convenience of the power-users who deploy from CVS. These people should just use the new cvs_deploy.module[2] instead. This line has caused lots of trouble and confusion for lots of people. I'm sorry I ever suggested it, and wish I had just written and released the cvs_deploy.module right when we were adding the version information to the modules page in D5. Oh well, live and learn... I've edited the 4.7.x -> 5.x upgrade docs[3] and the handbook page about writing .info files[4] to reflect the new best practice: > version (Optional) > The version string will ordinarily be added by drupal.org when a > release is created and a tarball packaged. However, if your module > is not being hosted on the drupal.org infrastructure, you can give > your module whatever version string makes sense. > Users getting their modules directly from CVS will not have a > version string, since the .info files checked into CVS do not > define a version. These users are encouraged to use the CVS deploy > [2] module to provide accurate version strings for the admin/build/ > modules page for modules in directories checked out directly from CVS. > > In the past (before the CVS deploy module existed), it was > recommended to use this: > > version = "$Name$" > However, this led to much confusion and is no longer recommended. > If you are a module developer, and you already have the above line > in your .info files checked into the Drupal CVS repository, you > should remove that line. Please let me know if you have any questions or complaints. Thanks, -Derek (dww) [1] http://lists.drupal.org/pipermail/development/2007-June/024698.html [2] http://drupal.org/project/cvs_deploy [3] http://drupal.org/node/64279 [4] http://drupal.org/node/101009

8 24

MySQL: joins on CHAR columns slower than INT
by Khalid Baheyeldin 19 Jun '07

19 Jun '07

Examples: InnoDB : 50% slower. MyISAM: 6X slower. Conclusions: 1. CHAR keys are indeed slower for joins compared to integer keys 2. Performance degradation can range from few percent to couple of times for Innodb tables 3. MyISAM Tables may suffer significantly if key compression is not disabled 4. Joining on Shorter CHAR keys is significantly faster than Long keys 5. Latin1 (I guess any simple encoding) is significantly faster for joins compared to UTF8 Details here http://www.mysqlperformanceblog.com/2007/06/18/using-char-keys-for-joins-ho…

1 0

How to implement hook_nodeapi when op is 'view'?
by Dave Cohen 19 Jun '07

19 Jun '07

In a recent thread I asked about using #pre_render callbacks to affect the way nodes are rendered. (See http://drupal.org/node/147662) This goes some way toward solving my problem, but things could be better. When my #pre_render hook is called, the data structure is filled with arrays that look like: [SOME KEY HERE] => Array ( [#value] => SOME HTML HERE [#weight] => SOME NUMBER HERE ) Because the #value field contains HTML, its very hard to modify. Practically speaking, all I can do is remove some fields from the node content, or reorder fields. I can't manipulate each field the way I really want. (For example, I may want to theme a CCK field differently depending on whether the node in question is a page or a story.) I'd like to see developers stop using this #value => HTML model when implementing hook_nodeapi($op = 'view'). Everyone does, because the documentation on api.drupal.org suggests implementing it this way: <code> case 'view': $node->content['my_additional_field'] = array( '#value' => theme('mymodule_my_additional_field', $additional_field), '#weight' => 10, ); break; </code> Instead, it should be implemented something like: <code> case 'view': // my_additional_data is an array $node->content['my_additional_data'] = $node->my_additional_data; $node->content['my_additional_data']['#theme'] = 'mymodule_my_additional_data'; $node->content['my_additional_data']['#weight'] = 10; break; </code> What this does is postpone the theming until drupal_render is called. And #pre_render hooks have a chance to manipulate data or change the theme function to be called. Please let me know if I'm right or wrong about this, -Dave

2 1

session.hostname
by Karoly Negyesi 18 Jun '07

18 Jun '07

Hi, Core does not use this field. What's the point? Can we drop it? Regards, NK

2 1

Module site_user_list is good, but..
by Huisi Wang 18 Jun '07

18 Jun '07

Hi all, The module "site_user_list" is good, and fits my need. It can display users' profile, and can be searched. But I found a problem that if a field is set as "date", it will be displayed as a string, such as "a:3:{s:5:"month";s:1:"3";s:3:"day";s:2:"11";s:4:"year";s:4:"1992";}". How to change the string into normal format ? Thanks, Huisi

2 1

Re: [development] Go PHP 5, Go!
by FGM 18 Jun '07

18 Jun '07

If this concerted effort means anything, it is precisely that an inflexion in the trends will be caused, causing discontinuity and a new segment in the trend curve instead of just continuing it. Disruptive events... ---- Original Message ---- From: dries.buytaert(a)gmail.com To: development(a)drupal.org Subject: Re: [development] Go PHP 5, Go! Date: Mon, 18 Jun 2007 11:03:28 +0200 > >On 11 Jun 2007, at 11:27, Gerhard Killesreiter wrote: >> If we proceed like this, there will be no way we could revert to >> support >> PHP 4 in February 2008. > >If I can believe my own projections (http://buytaert.net/php-is-dead- > >long-live-php), PHP5 will have a 30% adoption rate by February 2008, > >rather than the current 20%. Maybe February 2008 is a little too >early? > >-- >Dries Buytaert :: http://www.buytaert.net/ >

1 0

Re: [development] Interesting forum module patch
by Michelle Cox 17 Jun '07

17 Jun '07

Heh, that's ironic. I added my UI thoughts on that issue earlier today but just got around to reading the dev list now. I'm not any help with actually coding the UI but, as someone who desperately wants to add polls to forums, I've got more general how the UI could/should work ideas. Michelle On 6/17/2007 6:12:06 AM, Dries Buytaert (dries(a)buytaert.net) wrote: > Patch http://drupal.org/node/20295 is looking for someone who can > write help texts, and who can give some parts of the UI some > usability-love. It's well-suited for a Sunday afternoon. :-) > > -- > Dries Buytaert :: http://www.buytaert.net/

1 0

Skeleton outlines
by Ken Rickard 17 Jun '07

17 Jun '07

As mentioned last week, I am working on a module to create cloneable books. This has been released: http://drupal.org/project/skeleton The module lets you store unpublished node data as a "template," arrange those templates into an outline and create new books that contain the template nodes. See the module page for details. - Ken Rickard agentrickard

1 0

#pre_render - forms only?
by Dave Cohen 17 Jun '07

17 Jun '07

Now that the data structures developed for forms are being used for other data structures, particularly nodes, is there any reason why the #pre_render callback is available only in forms? I suggest moving the code that calls #pre_render callbacks from drupal_render_form() into drupal_render(). In particular I would like to add #pre_render hooks in my hook_view, so that I can tweak the node's content structure before it gets themed. Right now I see no reliable way to do this, short of making a special module with a very heavy weight so that it's nodeapi hooks are guaranteed to be called last. If there is positive feedback to this suggestion, I will submit patches for drupal-5.x and head. Thanks. -Dave

5 5