February 2007 - Development - lists.drupal.org

looking for new maintainers.
by Bèr Kessels 04 Feb '07

04 Feb '07

Hello, A lot of modules seeking maintainers recently :/ While we are waiting for a better solution[1], I started a wiki-fied solution http://drupal.org/node/115828 If its considered a bad idea, please just remove that page. Bèr [1] http://drupal.org/node/65975 -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl

1 0

Looking for new module maintainers
by Earl Miles 03 Feb '07

03 Feb '07

Posting to the dev list doesn't seem to get a lot of response to this kind of query, but I'm posting it here anyway. I need to reduce my workload a bit. Some of these requests have been standing for awhile, but I probably have not done a good job of making sure the requests are out there where everyone can see them. I’m looking for the following: * A new maintainer for delicious module. — the delicious API has changed. This is a module I took over maintenance on back in my early days of Drupal, and I’m just not particularly interested in it, which means it languishes. It’s still a very valuable and useful module. Right now all it NEEDS is someone who’ll maintain it, keep up with the API, and make the 4.7.x version stable and port it to 5.x. It could use someone who’d like to redo the entire thing and make it use nodes and taxonomy as well. * A new maintainer for the views bookmarks module — this module isn’t terribly difficult, but it is a touch more advanced than some might be. It’s a useful module that has a lot more users than I realized — but I haven’t the time to properly maintain it. It doesn’t need MUCH maintenance, either. I don’t think there’s too far that this piece of code needs to go, it just needs the occasional bug fix. * A co-maintainer for the forum access module — this module is extremely useful and there’s quite a bit of room for this to grow into a healthy add-on to the forum module. Theoretically it could also branch into an advanced forum set of its own. There’s lots of things that could happen here. I’d like to retain involvement in the module, but I don’t need to; if someone comes along with lots of great code and ideas, I’m happy to step aside and let the module go. * A co-maintainer for panels module — While working on Panels 2, I’ve basically let Panels 1 rot. It needs a lot of bug fixes, at the very least. Also, I need someone to specifically maintain the layouts. I’m NOT a CSS expert by any means, and the CSS seems like it needs some adjustments. And I would like more layouts. And there is a bunch of work to be done on Panels 2, as well. Panels is looking like a very important module to Drupal right now — this is a place someone could come in and really make a contribution.

2 1

By Ref Patch
by Earnie Boyd 03 Feb '07

03 Feb '07

http://drupal.org/node/109569 Earnie

1 1

Creating "dependent fields" in CCK
by Rob Thorne 03 Feb '07

03 Feb '07

Nedjo raised a question today concerning CiviNode's CCK widgets. civicrmdata.module implements a widget type that is a lot like nodereference and userreference, except it points to a contact record in CiviCRM, a PHP contact relation management package. Right now, it's possible to select an existing contact (via its "contact_id" field), and choose what CiviCRM calls a "profile". This is different than Drupal's profile; it represents a sort of window into a contact by selecting which fields of the contact record you want displayed. Currently, civicrmdata uses the CiviCRM profile to theme and render how the the "contact" displays when a CCK node renders its "view". Nedjo wants tighter integration; he wants to display and be able to edit a single field of a contact record. This makes a lot of sense, but it isn't clear how best to implement this with CCK's hooks. Here are some of the issues; * Typically, you want a group of CCK fields that are all related to the same CiviCRM contact object, say as example to indicate "who to contact" as part of a CCK node. If you change the person you want to contact, you need all of the dependent fields to point to that new CiviCRM contact. It would be very helpful if the contact_id could be changed in one and only one place, and have the CCK fields that point to the fields of the contact change in lock-step. Is this how calculated fields (in the contributed module) work, and is this the right model? * CiviCRM contact records have a fairly large memory footprint, and calling the CiviCRM APIs for fetching contacts takes processor time, so ideally, you want to fetch a contact object at most once per node (less if you cache between nodes). Is it possible to cache this information at the node level to allow the first field to render do the fetch, and all other fields pull from the cache. * When a contact field is edited, order matters; you don't want to write to the CiviCRM data store until all of a contact's 'dependent fields' have reported their changes. So it sounds like an update needs to happen in two phases. Can this be done with CCK (and Drupal's) current hooks,and if so, which ones do I need to look at. I wrote a good piece of civicrmdata's code, so I'm at least a bit familiar with CCK's hooks. But the above issues stump me. Can anyone shed light on this problem? Thanks, Rob Rob Thorne Torenware Networks http://www.torenware.com

1 0

CVS branch work best practices?
by Peter Wolanin 02 Feb '07

02 Feb '07

Per the discussion on the devel list, I just updated this page with a 3rd option for how to manage HEAD http://drupal.org/node/17570#HEAD -Peter

1 0

Re: [development] CVS branch work best practices?
by Chad Phillips -- Apartment Lines 02 Feb '07

02 Feb '07

AjK wrote: > Now, in HEAD, I start porting to DRUPAL CORE HEAD. There's no point > adding > features here as we are probably in code freeze anyway and we're all > upgrading like mad. > > Then, DRUPAL-6 comes along. Branch my module, wipe HEAD (till next > code > freeze) and continue devel down the DRUPAL-6 branch. please correct me if i'm wrong, but given this approach, why ever have HEAD at all? let's say you permanently wipe the files in HEAD except for the README. couldn't you just create the DRUPAL-6 branch directly from the latest DRUPAL-5 work? it doesn't seem like HEAD ever needs to exist in this model, except as a placeholder for the README. am i off base?? chad

2 1

Provisionator module throws error.
by Pushparajan V 02 Feb '07

02 Feb '07

Hi, I tried provisionator module for Drupal 4.7. It throws the following error: *Fatal error*: Call to undefined function getProvisionatorProfiles() in /var/www/html/drupal/modules/provisionator/provisionator_legacy.inc on line 37 When searched thru the code within provisionator module, this particular function was not defined anywhere.. Is it a problem with the module ? Anybody know how to solve this?.. Thanks -- Pushparajan V http://www.vprajan.org - - - - - - - - if(others(love)>=life) { noends=true; lifetime=others(love).length(); } - - - - - - - -

2 1

Content Type - wiki
by Earnie Boyd 02 Feb '07

02 Feb '07

In discussion of using Drupal for CMS elsewhere, I had a brainy idea as someone objected that Drupal didn't supply a wiki. Thinking out the idea I suggested that perhaps a content type named wiki could be created where revisions are set and the content is published but not promoted where any authenticated user could edit the content. A menu block named Wiki could be created to associate the nodes to. A taxonomy list could be created to help find the wiki content. Let's see I would need a wiki content filter to apply to WikiWiki words. What am I missing? Perhaps a theme to separate the main content from the comments in a tabbed display similar to MediaWiki. What else? Earnie P.S.: I know I can use third party software with Drupal, I'm trying to think through this simplistic idea.

11 20

Re: [development] Drupal 6 release schedule
by Raven Brooks 01 Feb '07

01 Feb '07

Gerhard Killesreiter wrote: > You are probably wrong there. My apologies, I gave you the benefit of the doubt - won't happen again. >What do you want? I even wrote "please". (Which was the part which I really didn't mean, if you want to know.) >Sorry, but if he can't operate google, then he's on the wrong mailing list. Well for starters it might be a nice general rule to just not send anything if you are only going to write something that is not only unproductive but also rude and condescending. Just *try* to put yourself in the shoes of a new developer to the Drupal project for a second. Is it better to be completely condescending when someone asks a question thereby giving them a bad impression of the developer community or would it be better to either a) not say anything or b) be polite and helpful? Option b shows leadership because you've potentially won a new developer to work on the project. Option a is available if you really don't care or can't do option b. Now if someone is being clearly annoying a personal message to that person may be in order, but it certainly isn't out of line for someone new to the list to ask a question like that and if your standard is that they should be aware of every conversation that has ever taken place since drupal began, well that's just ridiculous and insane. People get interested in things topically, and the first impulse isn't--and shouldn't be--maybe I should consult google to see if that was discussed before because that indicates some kind of final decision when that isn't what this is. I've seen long standing things change at the drop of a hat when someone makes a case for them, and that should be encouraged.

7 6

mysql merge tables and partitioning
by Moshe Weitzman 01 Feb '07

01 Feb '07

nice article at http://sebastian-bergmann.de/archives/655-Partitioning-with-Dates-in-MySQL-…. it describes mysql's new partitioning feature which seems like a good idea for our accesslog table. seems like drupal doesn't even have to know about the partitions, apart from system.install. if you haven't looked into it, access logging is a bad performance bottleneck in drupal. if you want a fast site, i recommend disabling statistics.module entirely. if your DBMS isn't mysql 5.1+ this would not apply to your site. thats obvious, but i'm quite certain someone will complain that this is mysql only and 5.1_ only and all that. yeah, we know. move on.

7 8