December 2007 - Development - lists.drupal.org

Requesting namespace reservation
by Michelle Cox 04 Dec '07

04 Dec '07

I'm starting work on turning my user profiles tutorial into a module. I am calling it "advanced profiles". Since it will be at least a week or two before I have code to commit, I'm not making a project, yet. But it's a fairly generic name so I wanted to make it known that I'm using it just in case. :) Odds are no one else will grab the name in that time but you never know with modules coming fast and furious these days. Michelle

2 1

Re: [development] important reminder: do not use API functions inupdate code
by Michelle Cox 04 Dec '07

04 Dec '07

On 12/4/2007 10:09:00 AM, Larry Garfield (larry(a)garfieldtech.com) wrote: > Given our relatively short development cycle, it wouldn't > surprise me if there are a lot of people trying to do 2-version jumps. 4. > 7 is still a supported version and will remain so until D6 is released. > Actively blocking people from jumping from a supported version (or just > barely not supported) to a supported version (or just barely supported) > seems, well, rude. :-) Dropping 4.6 and earlier makes sense. > > I'm all for recommending that people go through D5 first, but there's no > need to make a 4.7->6 upgrade effectively impossible. (Or a 5->7 upgrade > later, or 6->8, etc.) I'm one of those hoping I can take a site from 4.7 straight to 6 without having to go through 5 first. But my feeling is, if it works, great, but don't hold back progress or anything just to make it possible. If keeping the 2 version jump option is causing problems then I'll deal with having to do one version at a time. Michelle

1 0

Re: [development] Do not let postgresql hold back great patches
by Karen Stevenson 04 Dec '07

04 Dec '07

The question of how to handle dates isn't something we're going to 'solve' in a few emails back and forth on this email list and I figure maybe we should finish this thread up or move it elsewhere. The PHP5 function variant_date_from_timestamp seems to be something designed to work on Windows, I've not seen that used in any other situations. It just converts raw dates to and from timestamps, with the timezone adjustment unknown or ambiguous, part of the problem we have when storing dates as timestamps now. This whole issue is quite complex, even if we standardize on storing all dates in the database using native date formats, the SQL to manipulate the dates is still completely different from one database to another. And we need better ways to associate timezones with the stored dates, for dates that should be associated with specific timezones, so you know how to transform them when they're displayed. For date SQL that works across databases, a simple regex find and replace won't work because the code needed to extract date values from datetime columns can be completely different from one database to another (like the completely different ways you extract a week number from a datetime value in MYSQL and Postgres). My solution, for now, is to create a function that composes SQL date snippets from specified criteria. That has been enough for me to be able to do things like get Views queries correctly constructed in both MYSQL and Postgres. It's not a perfect solution, but it's much simpler than a complete abstraction layer. And even if we start storing all core date fields in native datetime format, we still need to have ways to handle dates in non-native formats if we want to be able to do things like import iCal or RSS feeds or otherwise use date values that originate elsewhere. Once I get the new Date API working (hopefully pretty soon), I'm it can be used as a focus for further work and discussion about how to handle dates in core going forward. If nothing else, maybe we can set up a time at the next DrupalCon for a meeting of anyone interested in this subject to hammer out ideas. Karen ----- Original Message ---- From: Earnie Boyd <earnie(a)users.sourceforge.net> To: development(a)drupal.org Sent: Tuesday, December 4, 2007 8:52:09 AM Subject: Re: [development] Do not let postgresql hold back great patches Isn't it preferred to use the ansi-sql92 TIMESTAMP column and allow the DB engine to do TRT with it? Then we can use PHP5 functions variant_date_from_timestamp and variant_date_to_timestamp to convert it.

1 0

LDAP Address Book module seeks maintainer
by Omar Abdel-Wahab 04 Dec '07

04 Dec '07

LDAP Address Book module needs not much description but needs someone's time to maintain. Unfortunately I didn't and do not have time to maintain it. Please contact me for details.

1 0

Do not let postgresql hold back great patches
by Karoly Negyesi 04 Dec '07

04 Dec '07

In my opinion, any patch should be committable to core once it works on mysql and has a decent hope (use common sense) to work on postgresql. Once it's committed those who care about postgresql, if they so want to, can test and if there is a need, fix it. Prime example: http://drupal.org/node/146466 this is the most important patch we have currently as it makes Drupal search speedy and nice. And it is more or less on hold just because noone is sure whether the postgresql update works or not. Regards, Karoly Negyesi

25 79

Tag clouds in faceted search
by Cofundos.org 04 Dec '07

04 Dec '07

Hi all, The following drupal related project was created on Cofundos.org (a platform for describing open-source project ideas and pooling resources for their implementation): *Tag clouds in faceted search* by david Tags: drupal faceted-search tag-clouds http://Cofundos.org/project.php?id=20 Project description: Offering weighted facet names (as tag cloud) surplus to hierarchical faceted search would offer further navigational access. Integrate http://drupal.org/project/tagadelic into http://drupal.org/project/faceted_search ! More info at: http://Cofundos.org/project.php?id=20 You can support this project by commenting it or bidding for its impementation! -- 241 Cofundos users were placing 133 bids (amounting Euro 6185) on 67 projects. *Please help making open-source even more successful* Spread the word about http://Cofundos.org

1 0

gearing up for Drupal 6 beta 4
by Gábor Hojtsy 03 Dec '07

03 Dec '07

Hello World, Drupal 6 beta 4 is planned to be released this Wednesday. Sorry for the small delay (it was actually promised to be out at the end of the previous week or earlier this week), but we do a coordinated release with security fixes included. Thankfully this short delay allows us to fix even more critical bugs in this (hopefully) last beta version. http://drupal.org/project/issues?projects=3060&versions=97368,184399,175832… There are 11 open critical bugs and 1 open critical task. The sooner we solve these, the sooner we get Drupal 6 out and the sooner we can add new features to Drupal (7). I know how many of you would love to do new features, and so do I. Please understand that it is quite hard to say no to cool new stuff, but we need to focus entirely on fixing bugs, or otherwise we are just moving around in a circle instead of going forward. (Most cool new stuff patches introduced bugs some of which we still are about to resolve, and introducing new bugs at this stage is no fun). As I said earlier, the mostly constant state of the critical queue (ie. no new bugs getting in) looks like a good sign of the system going strong. So the next step is hopefully an RC1. I hope that we can reach this stage sooner then later. We have been in feature freeze mode for long enough that your frustrations about not getting shiny new features into the release can be turned into feverish bug fixing in the criticals queue. Unfortunately the constant state of the criticals queue (ie. not much progress on the issues) also tells us that not many people find this bug hunting that fun. But thankfully most issues are awaiting your testing and reviews, so you don't need to be the bug hunter. Testing patches is easy! :) Until the RC1 hits the website, string modifications are also accepted in the name of usability improvements. After that, the interface strings are frozen, and translators will be asked to start translations. We changed lots of stuff since Drupal 5, even through the betas, so poor translators will have quite some work to do. Hopefully everything changes for the better. Summary: - do not work on big new stuff and/or behavior modifications for Drupal 6, unless fixing a critical **bug** - if you'd like to help Drupal 6 getting out, focus on the issues on the link above - unless major bugs appear, we plan to move on to RC1 (this could be in a few days to a week or two) - translators hold off your work still for a short while until RC1 Ps. I created an unpublished release announcement for beta 4, which privileged users can go and edit, if you think anything needs to be fixed. It is in full HTML mode as all the previous announcements. Don't forget about switching on saving a new revision, when you edit the node: http://drupal.org/drupal-6.0-beta4 Happy bug fixing to all! Gabor

1 0

New deal
by Karoly Negyesi 03 Dec '07

03 Dec '07

Hi, I just made a deal with catch: if he is interested enough in a bug to review it, I will patch it. If more people get similar fame as a patch reviewer, I am quite willing to struck more similar deals. Regards, Karoly Negyesi

1 0

Re: [development] hook_theme vs hook_elements?!?!
by Darrel O'Pry 03 Dec '07

03 Dec '07

I'm confused about hook_theme. I should have been paying more attention to that discussion. It seems to duplicate a lot of the functionality of the existing render api. I was wondering if someone could help me understand the differentiation and use cases for the similar features? A quick overview of functional duplication... The hook_theme 'arguments' property seems like it would be roughly equivalent to the way element property default values are set using _element_info. The hook_theme 'function' property seems very similar to how '#theme' functions currently. The hook_theme 'preprocess' property seems very similar to the render api's '#pre_render' The hook_theme 'override preprocess' seems to provide the same functionality as hook_view_alter... .darrel.

1 0

PostgreSQL Help Wanted
by Hans Salvisberg 02 Dec '07

02 Dec '07

Hello PostreSQL Gurus, Please take a look at http://drupal.org/node/196831 Could this be a long-standing pgsql bug in core? TIA! Hans

1 0