February 2007 - Development - lists.drupal.org

seeking module maintainers
by Knapen Dries 08 Feb '07

08 Feb '07

Dear list, It has taken some time before I was able to admit it to myself, but due to some extensive changes in my academic career I no longer have time to actively and responsibly maintain the modules I created. To be honest, I even didn't get to thoroughly study the changes in Drupal 5 from a developer's perspective, so I don't see myself upgrade these modules any time soon. I prioritized my Drupal and other activities, and I have decided that in the foreseeable future I will only continue to contribute to the Drupal project as the treasurer of the Drupal Association, and no longer as a module developer, since I believe that the Association is currently more important to support Drupal and help the project grow. Therefore, the following modules need new maintainers: Flash Gallery http://drupal.org/project/flash_gallery Graphstat http://drupal.org/node/33946 Inactive User http://drupal.org/node/10435 Simplenews http://drupal.org/project/simplenews As for Simplenews (critical for drupal.org) RobRoy (http:// drupal.org/user/22975) already has cvs access, and released a working 5.x version of the module. Furthermore, Sutharsan (http://drupal.org/ user/73854) provided a lot of great patches for simplenews lately. I'll forward this e-mail to him in case he doesn't read this list. I will unsubscribe from most public Drupal mailing lists soon, you can contact me in private through http://drupal.org/user/17892/ for cvs access and/or module ownership. Drupal.org site administrators are also free to perform these actions. I'd only like my name to be mentioned as the original author on the project page and README.txt of Flash Gallery, Graphstat and Simplenews. cheers, Dries Knapen

9 15

create patch form
by sime 08 Feb '07

08 Feb '07

Has anyone meddled with a patch creation form? Eg: 1) select the file of interest 2) paste your variation code 3) submit to create a patch Seems simple, judging from the few times I'm brave enough to use the command line (yes, I'm GUI user who would struggle to code this). In my wanderings through contrib, I've seen many users submit code which solves a problem, but which is not in expected patch format. For example, a zip file of whole modules! This happens more in the contrib modules where patches are less critisized and users are sharing solutions with each other that "just work". Some might question whether we should cater for these developers. I say yes, because they are solving problems but cannot communication the answer very well. If a developer installs a module on a site, and then fixes a bug, then they have a solution - however to then submit that answer in legible form is quite an effort for many. Further more, we then expect users to be able to generate function-contextual patches from root. This is a hard to grapple and I'm sure the effort is too much for some, and they never submit a patch at all. Interested in any thoughts. Simon (sime)

13 17

Re: [development] CCK in Drupal 6
by Karen Stevenson 08 Feb '07

08 Feb '07

There are so many good ideas flying here I thought I would try to get them organized in a place where we can do something with them so I started a wiki page on g.d.o at http://groups.drupal.org/node/2717. Unfortunately, only the first page ended up as a wiki page. The pages created automatically from the wiki links ended up as story pages that cannot be edited. Can someone with admin rights straighten it out for me? There are only 3 pages. I could create new wiki pages, but can't delete the story pages, so I just stopped because I was messing things up. http://groups.drupal.org/node/2719 http://groups.drupal.org/node/2720 http://groups.drupal.org/node/2718 It's not complete, I just tried to get some of the big ideas documented. On a couple of the pages I just pasted parts of this thread as a starting point. Once the story pages get changed to the wiki pages they were supposed to be, they can be cleaned up and fleshed out by anyone who is interested. Anyway, it's a beginning... Karen ----- Original Message ---- From: Darrel O'Pry <dopry(a)thing.net> To: development(a)drupal.org Sent: Wednesday, February 7, 2007 3:19:09 PM Subject: Re: [development] CCK in Drupal 6 On Wed, 2007-02-07 at 14:28 -0600, Larry Garfield wrote: > On Wed, 7 Feb 2007 22:11:11 +0200, adrian rossouw <adrian(a)bryght.com> wrote: > > > > On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote: > > > >> > >> This can be overcome with a few simple #validate functions on form > >> elements correct? > >> > > > > There are definitely 2 steps involved here. > > > > widgets do processing on the input, to change it into the right data > > type. (this is how i felt checkboxes/ select lists should have been > > handled, not by being hardcoded in form_builder) > > fields validate the data that they have been given, whether by code > > or by the widgets. > > > > I don't believe we should include the #validate functions for the > > field types / widgets into the form structure thought, > > because if we do it right,. every single field will have validation > > rules, > > and all that information will not often be modified (fields can still > > have additional validation rules of course). > > > > We don't want to bloat the data structure unnecessarily. > > Potentially naive question from someone who has not used FAPI to its fullest extent > yet: What does hook_widget offer that hook_elements does not? Would it be feasible > to simply beef up hook_elements to fill in any missing functionality that hook_widgets > has that it doesn't, then deprecate hook_widget? The widget callbacks in CCK, hook_widget_info, hook_widget_settings, and hook_widget provide a few things above and beyond form elements. 1) hook_widget_info, A way to specify which widgets work with which fields. 2) hook_widget_settings, provides a form and setting so users can configure widgets through the browser when creating field instances. 3) hook_widget, the only unique addition that can't be handled through the current FormAPI is the prepare op. > That would give us the bonus of CCK-added fields and form_alter value-add fields > both being able to support "rich fields". Instead of a CCK field called "node > reference", you'd have a FAPI element called node_reference: > > $form['other_node'] = array( > '#type' => 'node_reference', > '#default_value' => $node->other_node ? $node->other_node : 0, > '#required' => TRUE, > ); I think we're kind of headin in this direction but you would call $form['other_node'] = drupal_field('nodereference'); > And then you could do the same with arbitrarily complex elements/fields which can then be > value-added or CCK-added via the admin. The problem is these kinds of constructs are currently only valid on nodes, since CCK in its present form is about decorating nodes with custom fields. I've been playing with the idea of field instances and their values as their own data silos, much like Ber's idea of microcontent I think, and similar normalized lookup or attribute tables in databases. I don't think this is within the scope of getting CCK into core. I think we should avoid new features at all costs, until we get the integration done right for our existing feature set. Then start planning how to expand on it. > > Or am I completely misunderstanding hook_elements entirely (which is entirely possible)? hook_elements basically defines a set of defaults for a '#type'. Its nice to have simple dumb elements. I'm not sure you need a widget all the time and widgets use elements themselves. With #process they're nicely nestable.

2 1

Re: [development] CCK in Drupal 6
by Larry Garfield 07 Feb '07

07 Feb '07

On Wed, 7 Feb 2007 22:11:11 +0200, adrian rossouw <adrian(a)bryght.com> wrote: > > On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote: > >> >> This can be overcome with a few simple #validate functions on form >> elements correct? >> > > There are definitely 2 steps involved here. > > widgets do processing on the input, to change it into the right data > type. (this is how i felt checkboxes/ select lists should have been > handled, not by being hardcoded in form_builder) > fields validate the data that they have been given, whether by code > or by the widgets. > > I don't believe we should include the #validate functions for the > field types / widgets into the form structure thought, > because if we do it right,. every single field will have validation > rules, > and all that information will not often be modified (fields can still > have additional validation rules of course). > > We don't want to bloat the data structure unnecessarily. Potentially naive question from someone who has not used FAPI to its fullest extent yet: What does hook_widget offer that hook_elements does not? Would it be feasible to simply beef up hook_elements to fill in any missing functionality that hook_widgets has that it doesn't, then deprecate hook_widget? That would give us the bonus of CCK-added fields and form_alter value-add fields both being able to support "rich fields". Instead of a CCK field called "node reference", you'd have a FAPI element called node_reference: $form['other_node'] = array( '#type' => 'node_reference', '#default_value' => $node->other_node ? $node->other_node : 0, '#required' => TRUE, ); And then you could do the same with arbitrarily complex elements/fields which can then be value-added or CCK-added via the admin. Or am I completely misunderstanding hook_elements entirely (which is entirely possible)? --Larry Garfield

5 4

should tinymce get a new maintainer tinymce
by Alaa Abd El Fattah 07 Feb '07

07 Feb '07

Hi, I don't know how many of you are following tinymce module development, so I thought I'd bring up this issue on the mailing list. recently user drupal-id.com took over the project and immediately started on a rewrite for drupal 5 discarding all old code. the problem is drupal-id.com's new redesign lacks features that many existing tinymce users find crucial (like customizing the button set and having different buttonsets per role). but the problem is not limited to differing goals, I don't think drupal-id.com is a good maintainer, he does not respond to issues in the issue queue (the issue queue is not 10 pages long and growing rapidly). at the moment the only way to get tinymce to work as before is to patch the DRUPAL-4-7 branch using a patch attached to this issue http://drupal.org/node/100864 check the discussion around this issue to soo how many are complaining about current state of tinymce.module drupal-id.com responded only once to this issue. IMO tinymce needs a new maintainer. cheers, Alaa -- Alaa: Husband of the Grand Waragi Master http://www.manalaa.net

22 42

Community tagging (Was Re: Content Type - wiki)
by Boris Mann 07 Feb '07

07 Feb '07

On 2/1/07, Julian <julian(a)tschannen.net> wrote: > On Thursday 01 February 2007 09:25, Morbus Iff wrote: > > > http://test.tschannen.net ? > > > > What handles the "Add tagging" block on the right? > > A custom module which allows flickr-like tagging. > It is similar to 'community_tags' or 'taxonomy_user' but both of them are not > yet available for drupal 5 and they didn't provide all the functionality I > needed. > > But the module is not yet in a state that it is usable by others. Can we collaborate on community_tags? We've been in touch with taxonomy_user author but gotten no response. We plan on updating community_tags to Drupal 5...it would be great to have you as co-maintainer and merge directions here rather than yet-another-module. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com

3 3

Drupal 5 performance
by Dries Buytaert 07 Feb '07

07 Feb '07

Hello, as I promised a while ago on this mailing list, I would do a performance comparison of Drupal 4.7 vs Drupal 5. Well, it's up at: http://buytaert.net/drupal-5-performance. -- Dries Buytaert :: http://www.buytaert.net/

2 1

Re: [development] form_builder and the $form['#type'] .'_value' callback.
by Darrel O'Pry 07 Feb '07

07 Feb '07

I started asking chx about this in IRC last night. I've been working on a few custom form elements for handling files. I need a chance to save files locally before #validate is reached. Chx, suggested #after_build, but I am having issue with my #after_build being called from my element prototype(the default #type values returned from hook_element). While looking through form.inc and trying to figure out why my #after_build function wasn't being called when triggering a submit button on the page I notice there is a large select in form_builder for some default element types, to assign their values from edit/_POST. The _value callback is for defining default values according to chx, and is a rarely used function. I thought it might be a neat idea to move this hard coded select out of form_builder and use the _value callback to assign the #value in form_builder and set the #needs_validation if a value is return from the _value callback. Otherwise use the #default_value defined in the form or the element prototype. I think the behavior would make it easier to build form_elements that don't return a value (type=file ad unchecked type=checkbox are the only ones I know of) and need to generate their value from contextual data. .darrel.

2 1

Fwd: [drupal.org] How to add co-mainteners?
by Boris Mann 07 Feb '07

07 Feb '07

I *think* we can go forward with Kevin as main maintainer of 5--2-0 and Allie/Steve as maintainers of 5--1-0. Who wants main ownership of the TinyMCE project? ---------- Forwarded message ---------- From: Drupal Indonesia <support(a)drupal-id.com> Date: Feb 6, 2007 10:45 PM Subject: How to switch the Maintener? To: Boris Mann <boris(a)bryght.com> Borris Mann, I would like to switch my right as Main Maintener to other, and I just a co-maintener. How to do it? Regards, Jonathan. ---------- Forwarded message ---------- From: Drupal Indonesia <support(a)drupal-id.com> Date: Feb 6, 2007 10:09 PM Subject: Re: [drupal.org] How to add co-mainteners? To: Boris Mann <boris(a)bryght.com> > Yes, cvs access is co-maintainers. You've now added a ton of them, > without communicating about direction. what direction need to comminucate? and how? > Does that make sense? Since we had no response from you, we had to > start another project... > FYI, 12 Jan 2007: Heini reports that my email broken 18 Jan 2007: I give respond 30 Jan 2007: Heini and you come back and report that email still error 7 Feb 2007: I have fixed the email problem. On 30 Jan 2007 I still receive email from other company like CodeGear, that's why I didn't think that I have email problem. What exactly happen is the MX Records point to my other email server. But... clever Kevin directly contact me via website and I see the problem. Thanks Kevin! > There are many folks that need the 4.7 functionality brought to 5. > Ideally, you could move your codebase to DRUPAL-5--2-0 and we could > maintain the extension of the existing base at DRUPAL-5--1-0. > I am not familiar with CVS. I am using Tortoise-CVS. Could you tell me how to create DRUPAL-5--2-0 ? Regards, Jonathan. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com

1 0

The array argument in hook_user: can we get rid of it?
by Nedjo Rogers 06 Feb '07

06 Feb '07

Unlike our other object hooks (e.g., hook_nodeapi, hook_taxonomy), hook_user passes two arguments by reference. Both are representations of the user object, one in array and the other in object format. There's a lot of interest in streamlining our object handling. I've been working on a set of generalized object handling methods that build on our current ones in http://drupal.org/node/113435. As I dig into this, I'm finding that hook_user's difference from our other hooks is one of the main barriers. Maintaining this double pass by reference would force all other object types to do the same, even though they don't have data they need to pass. Hence my question: can we change hook_user to behave like the other object hooks, passing a single argument (the user object) by reference? Pitfalls? Looking at the implementations in user.module, this double passing looks to be mainly a matter of convenience--separating out what are parameters to match (user_load()) or extended user attributes (user_save()) from the base user object. My hunch is, if they're user data they're user data as far as hook implementations are concerned, so it shouldn't matter much if they're passed in a single object. But maybe this is wishful thinking. I'm thinking a patch to change hook_user to pass a single argument by preference may be a necessary prior patch to getting a generalized set of methods in. Thoughts?

4 3