- Development - lists.drupal.org

Multiple Forms, single form handler
by James McLean 20 Jun '07

20 Jun '07

Howdy, I'm working with a module called 'invite' (not sure if its drupal core or not) and i've added some hooks to allow it to work as a block as well as a regular module. The block is working fine and I have managed to build a form using the standard Drupal forms API successfully. The form submits to my validate function correctly and validates the submitted details as it should. Now, in order to save time and re-use existing code, I would like the form in my block to use the same methods and routines for saving information that the main form uses when you view it directly and fill out that form and submit that (http://drupal.local/invite/) The main form has two fields that are submitted (email address, required - description, not required) and my Block form has a single field (email address). The form built in my block is named 'invites_block_form' and the main form is named 'invite_form' I've attempted to use hook_forms() to achieve this behavior as outlined in the 'Pro Drupal Development' book but cant quite get my head around how to achieve it. If anyone could provide some insight into how to achieve this I would be greatful. Cheers, James McLean

4 4

Re: [development] Go PHP 5, Go!
by Nathaniel Catchpole 20 Jun '07

20 Jun '07

I went down every non-PHP 5 project on the list Sime posted. At this point they either support PHP 5, require it, or appear abandoned. pMachine - abandoned, replaced by by ExpressionEngine (PHP 5 supported) PHP Support Tickets (1.9) - now at 2.0, requires PHP 5.0.1 Support Logic Helpdesk (1.2) domain squatted? Support Services Manager (1.0b) - abandoned Advanced Poll (2.03) no information either way - seems to be abandoned, but e-mailed just in case. PHPSurveyor (1.0) - abandoned, replaced by LimeSurvey dotProject - 2.1 rc has PHP 5 support PhpWiki - couldn't find anything conclusive either way Noah's Classifieds - abandoned "sorry we're not responding to e-mails". I sent this via Gmane but it doesn't seem to have come through, if this is a dupe, I apologise (and for the work sig that'll follow this). Hope it helps with any fantastico persuasion. -----Original Message----- From: sime [mailto:info@urbits.com] Sent: 18 June 2007 16:54 To: development(a)drupal.org Subject: Re: [development] Go PHP 5, Go! Gerhard Killesreiter wrote: >>Had a little look around. Here is a list of scripts supported by >>Fantastico, along with their PHP5 status. Hope this is useful. >>http://tdknights.com/fantastico.htm >> >> -- Confidentiality: This email and its attachments are intended for the addressee only and may be confidential or the subject of legal privilege. If this email and its attachments have come to you in error you must take no action based on them, nor must you copy them, distribute them or show them to anyone. Please contact the sender to notify them of the error. Security: Security Warning: Please note that this e-mail has been created in the knowledge that e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us. Viruses: This email and any attached files have been scanned for the presence of computer viruses. However, you are advised that you open any attachments at your own risk. Please note that electronic mail may be monitored in accordance with the Telecommunications (Lawful Business Practices) (Interception of Communications) Regulations 2000. Disclaimer: Any views or opinions presented are solely those of the author and do not necessarily represent those of B6 Sixth Form unless explicitly stated otherwise ----------------------------------------------------------------------- This message has been inspected by DynaComm i:mail -----------------------------------------------------------------------

3 2

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