May 2007 - Development - lists.drupal.org

Open ID status report (and easter egg)
by Robert Douglass 16 May '07

16 May '07

Is there any chance of Open ID getting into Drupal 6? The issue for this seems to be here: http://drupal.org/node/131026 The last patch is from March and no core committer has commented on it. This is supposed to be one of the killer features for Drupal 6, and it is the right thing to do. What can we do to raise awareness of the issue and build some momentum behind it? -Robert [Since this is a repost, gotta make it interesting: Thunderbird tells me that committer is misspelled, so I went to www.thefreedictionary.com to check, and found this: Com`mit´ter *n.* *1.* One who commits; one who does or perpetrates. *2.* A fornicator. #2 - LOL ]

4 3

Drupal Netvibes Universe
by Matthew Farina 16 May '07

16 May '07

Netvibes is interested in providing a drupal universe at www.netvibes.com/drupal. I put together an initial universe based on some feedback I previously got from the list. It should be complete by the end of this week. Is there a place in the community we can advertise this? Initially the universe consists of 2 pages being a general and a developer page. The general page has on it the drupal planet, drupal pics on flickr, drupal.org rss feed, drupal groups homepage feed, drupal events from groups.drupal.org as a webcal, drupal on del.icio.us, the lullabot podcast, drupal general discussion, drupal showcase, and drupal new modules. On the developer page there are feeds for the drupal dojo, lullabot articles, drupal translations forum, drupal core forum, drupal module development forum, drupal theme development forum, drupaldigest CVS mailing list, drupaldigest documentation list, drupaldigest development list, and a block with quick links for developers. Is there anything else that would be good to have?

7 8

Re: [development] Drupal Netvibes Universe
by Matt Farina 16 May '07

16 May '07

1 0

Newbie announcement + starting a new meeting related module
by Bob 16 May '07

16 May '07

Hey there, I'm new to this so go easy if I make any blatant faux pas! A bit about me: I've been doing php & mysql programming for quite a while now, and make the odd hack application here and there. I think like a lot of people I've come round to the idea helping with a big CMS is a much better way to go! I've not contributed to a big project before either. I got a copy of the Drupal Pro Development book, and it all seems kinda straightforward so hopefully I'll be ok! Anyway, I want to create a new module. I've not seem anything similar, but let me know if I'm duplicating existing functionality (I think there's some crossover, but anyway). And also sorry if this is the wrong place for this, I couldn't see a suitable list otherwise! I want to make a module for meetings that tracks individual agenda items and action points. I'm involved in an activist community where a lot of people do a lot of different meetings all the time, and there's rarely any continuity. The module would work as follows. 1. Before a meeting, people can add individual agenda items that allow comments and discussion. 2. Just before the meeting, the agenda can be printed off as a time saving device. 3. After the meeting, comments or minutes can be recorded against specific items to allow better tracking (keywords, etc) 4. Also, and the main focus of this module, individual action points can be added and assigned to users. 5. In a way similar to case tracker, people can then leave comments and mark tasks when they're done. 6. At the next meeting, it should be easy to keep a track of what's actually been done, and see what's dragging on. As you can see it's kind of a circular process, but I hope you kind of get the idea! I have a few ideas how this will all work in my head, but if anyone is interested or would like to help that would be great, as I think it's quite an ambitious first project and a little mentoring would be appreciated! A few notes: - I was looking at making meeting node types extensions of event types, to keep all that functionality. - Two basic new node types would be involved - Action Point and Meeting. - I was thinking of using taxonomy to track things like meeting groups. - For action point entry, I was visualising posting them as a plain text list, which then gets parsed and each line added as a node. As I've already stressed, any and all input welcomed, even if it's a case of 'don't bother because of X reason'. Thanks a lot! David xx -- phone: 0774 3917404 skype: daresbalat msn: bobulatorm(a)hotmail.com

6 11

Re: [development] Drupal Netvibes Universe
by Michelle Cox 16 May '07

16 May '07

It has a really great error message, though. I LOL'd (literally) when I read that. :) Michelle On 5/15/2007 8:17:47 PM, Matthew Farina (matt(a)mattfarina.com) wrote: > The link doesn't work yet. That's where it will be at sometime later > this week. > > - Matt > > On May 15, 2007, at 8:58 PM, Walt Daniels wrote: > > > No such link > > > > -----Original Message----- > > From: development-bounces(a)drupal.org [mailto:development- > > bounces(a)drupal.org] > > On Behalf Of Matthew Farina > > Sent: Tuesday, May 15, 2007 5:44 PM > > To: development(a)drupal.org > > Subject: [development] Drupal Netvibes Universe > > > > Netvibes is interested in providing a drupal universe at > > www.netvibes.com/drupal. I put together an initial universe based > > on some > > feedback I previously got from the list. It should be complete by > > the end > > of this week. Is there a place in the community we can advertise > > this? > > > > Initially the universe consists of 2 pages being a general and a > > developer > > page. The general page has on it the drupal planet, drupal pics on > > flickr, > > drupal.org rss feed, drupal groups homepage feed, drupal events from > > groups.drupal.org as a webcal, drupal on del.icio.us, the lullabot > > podcast, > > drupal general discussion, drupal showcase, and drupal new mod

1 0

Re: [development] [drupal.org] big link on the front page
by Robin Monks 15 May '07

15 May '07

That's a good point, I'm going to try to get a few editors together to make a sustainable Drupal.org newsletter. Interested in being a part of that team? For that matter....sorry for the cross-post, but does anyone that gets this email want to be involved in a better Drupal newsletter? It would literally only take an hour of your time per month. Robin On 5/14/07, joet(a)artatac.com <joet(a)artatac.com> wrote: > > Robin Monks, > > artatac (http://drupal.org/user/67038) has sent you a message via your > contact form (http://drupal.org/user/12246/contact) at drupal.org. > > If you don't want to receive such e-mails, you can change your settings at > http://drupal.org/user/12246. > > Message: > > Im a great beleiver in Drupal and its community. So I feel that having a > big link on the front page to a newsletter that seems to be a year old > seems a big shame. I might be missing something but if it isnt regularly > updated (monthly?) shouldnt we remove the section from the front page? > > Regards > > Joe > -- Robin Monks @ www.civicspacelabs.org @ www.gmking.org Fax: (419) 791-8076 "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems." ~IRC

8 9

FormAPI 3 has landed
by Jeff Eaton 15 May '07

15 May '07

For the last several weeks, chx, myself, and a number of others have been working on a large set of improvements for FormAPI in Drupal 6. (http://drupal.org/node/138706 is the issue in question) The vast majority of these changes revolve around simplifying FAPI's weird edge cases, making the system more internally consistent, removing roadblocks to things like AJAX forms, and applying some of the lessons we learned in previous iterations (making multistep work cleaner and smoother, etc). One of the biggest changes is the introduction of the 'form state' variable. Previous versions of FormAPI used a combination of $form_values, global variables, and custom flags in the form definition itself to capture information about the form's workflow and its current state during processing. In Drupal 6, a single array -- $form_state -- is passed along through each stage of form processing. It contains all the state information and contextual flags needed to control the form's processing and workflow. Among other things, this has enabled us to completely eliminate the use of globals in form.inc, and -- with the exception of edge cases involving batch processing -- we no longer clutter up the session with form state information. The consistency of the form state also variable means that we can use it to eliminate a number of diverse (and weird) techniques for passing data around and controlling flow. Validation handlers can pass data on to submit handlers, submit handlers (be setting $form_state['rebuild']) can trigger a multistep-style revisiting of the form. Submit handlers place their redirection paths in $form_state['redirect'] rather than returning a text-string. Node creation forms can populate $form_state['nid'], which is returned to drupal_execute when its called in that context. Submit handlers can set the $form_state['rebuild'] flag to indicate that the form should be rebuilt, multistep-style, rather than being cleared out. When this happens, all the information in $form_state, including the current post/form_values data, is fed back into the form constructor function. If the form handling requires transient data (like partial answers to a survey) to be built up in multiple stages before permission, handlers can use the $form_state['storage'] bin, which FormAPI caches between page-loads to preserve for the entire lifetime of the form. (Developers no longer have to carry the burden of figuring out where to store all their 'in progress' form values, hide them in unvalidated hidden fields, etc.) In addition, behind the scenes we're also using a new dedicated cache table for forms -- in multistep scenerios where forms must be built once for validation and once for rendering, we're caching the form definition array and retriving it for the validation stage rather than forcing it to be built twice. The fact that we're storing that array structure also opens the doors for AJAX and AHAH forms -- callbacks on the server could open the cached form array and alter in fields that have been added on the client side, so that when validation time comes everything matches up. While that AJAX integration is not explicitly built into FAPI, the new cache-based multistep system makes such change possible. There are MANY changes and improvements. Fortunately, few require much more than changing a function signature. But all Drupal developers are encouraged to visit the upgrade documentation page at http://drupal.org/node/144132 -- there are likely to be LOTS of questions, and that first stab at documenting the changes is only round one. Feedback is much appreciated! --Jeff <http://drupal.org/node/144132>

2 1

New handbook page: Updating API documentation
by Angela Byron 15 May '07

15 May '07

Yes, technically this is a docs thing, but it's primarily about you guys. ;P Following an IRC tutorial this morning with snufkin, there's a new handbook page that explains how anyone on this list can help keep the API documentation up to date: http://drupal.org/node/144223 Now, no more tracking me down in #drupal to tell me that the FAPI reference has a bug. ;) Thanks, add1sun! -Angie

1 0

Reconciling mysql & pgsql schemas
by Barry Jaspan 15 May '07

15 May '07

The Schema core patch (http://drupal.org/node/136171) to provide a base level of database schema abstraction is coming along nicely. This will include defining a table definition structured array so that manual CREATE TABLE statements will be history as well as the suite of db_{add,remove}_{field,key,index} so that ALTER TABLE statements will also be history. Existing hook_update_n() functions and the entire existing "schema version" system will be unaffected. One issue that has come to light is that our existing mysql and pgsql database schemas, as represented in the CREATE TABLE statements, are different. The differences are pretty minor: signed vs unsigned, default vs no default, int vs smallint. However, since the goal is to create a single data structure representing each module's tables, I think we should resolve the differences. I've listed all of the discrepancies below. This list was derived by: 1. Installing HEAD on mysql (with current CREATE TABLE statements) with all optional modules enabled. 2. Automatically generating the database schema structure by inspecting the mysql database and SAVING it in each module's hook_schema. 3. Installing HEAD on pgsql (with current CREATE TABLE statements) with all optional modules enabled. 4. Automatically generating the database schema structure by inspecting the pgsql database and COMPARING it (NOT saving it) against each module's hook_schema. As an example, the first mismatched table is aggregator_feed. The comparison report translates as: "Table aggregator_feed has a column named 'description'. hook_schema for this table says the column has no default value but the actual database column has a default value of ''." Sure enough, if you look at the mysql and pgsql CREATE TABLE statements, you will see that mysql's (which is what was used to create the "declared" structure) has no default while pgsql's (which is what was used to create the "actual" structure) has one. Fixing this is a two-step process. First, we must decide which schema (mysql's or pgsql's) is right in each case. Then, either: 1. write a system_update function to modify each mismatching table into conformance, or 2. put db-specific values into the schema data structure, like this: $schema['aggregator_feed']['fields']['description'] = array( 'type' => 'text', 'not null' => 1, 'pgsql_default' => ''); Note the 'pgsql_default' attribute. We can also use a combination of 1 and 2 if necessary. I propose using 1 whenever possible and 2 only if/when necessary. Comments? The comparison report (compliments of schema.module) follows. Thanks, Barry Tables for which the schema and database are different. aggregator * aggregator_feed o column description: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') o column image: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') o unique keys link: missing in database o unique keys url: unexpected (not an error) block * blocks o column pages: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') * boxes o column bid: declared: array('type' => 'int', 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o column bid: declared: array('type' => 'int', 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o column format: declared: array('type' => 'int', 'not null' => 1, 'default' => 0) actual: array('type' => 'int', 'size' => 'small', 'not null' => 1, 'default' => 0) comment * comments o column format: declared: array('type' => 'int', 'not null' => 1, 'default' => 0) actual: array('type' => 'int', 'size' => 'small', 'not null' => 1, 'default' => 0) o indexes lid: missing in database o indexes nid: unexpected (not an error) * node_comment_statistics o column nid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) contact * contact o column cid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o column recipients: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') o column reply: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') dblog * watchdog o column location: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') drupal * client o column cid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) locale * locales_source o column source: declared: array('type' => 'blob', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1) o column source: declared: array('type' => 'blob', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1) o indexes source: unexpected (not an error) * locales_target o column translation: declared: array('type' => 'blob', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1) o column translation: declared: array('type' => 'blob', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1) o indexes lang: missing in database o indexes language: unexpected (not an error) node * node o column nid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o indexes node_title_type: declared: array('title', 'type') actual: array('title') o indexes node_type: missing in database * node_revisions o column vid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o column vid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o column vid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o column body: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') o column teaser: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') o column log: declared: array('type' => 'text', 'not null' => 1) actual: array('type' => 'text', 'not null' => 1, 'default' => '') poll * poll_choices o column chid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) search * search_index o column score: declared: array('type' => 'float', 'not null' => ) actual: array('type' => 'float', 'size' => 'big', 'not null' => ) * search_total o column count: declared: array('type' => 'float', 'not null' => ) actual: array('type' => 'float', 'size' => 'big', 'not null' => ) system * authmap o column aid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) * cache o column serialized: declared: array('type' => 'int', 'not null' => 1, 'default' => 0) actual: array('type' => 'int', 'size' => 'small', 'not null' => 1, 'default' => 0) * cache_filter o column serialized: declared: array('type' => 'int', 'not null' => 1, 'default' => 0) actual: array('type' => 'int', 'size' => 'small', 'not null' => 1, 'default' => 0) * cache_page o column serialized: declared: array('type' => 'int', 'not null' => 1, 'default' => 0) actual: array('type' => 'int', 'size' => 'small', 'not null' => 1, 'default' => 0) * files o column fid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1) o column fid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1) o column fid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1) o column fid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1) * menu o indexes pid: declared: array('pid') actual: array('parent') * url_alias o column pid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) o unique keys dst_language: missing in database taxonomy * term_data o column tid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) * term_node o primary key: declared: array('vid', 'tid', 'nid') actual: array('tid', 'nid', 'vid') * term_synonym o indexes name: missing in database * vocabulary o column vid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) user * role o column rid: declared: array('type' => 'serial', 'unsigned' => 1, 'not null' => 1) actual: array('type' => 'serial', 'not null' => 1) * users o column uid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1) o column uid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1) o column uid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1) o column uid: declared: array('type' => 'int', 'unsigned' => 1, 'not null' => 1, 'default' => 0) actual: array('type' => 'serial', 'not null' => 1)

4 6

New module: E-Commerce Product Location
by Darren Oh 15 May '07

15 May '07

I've been working on a product that needed locations. Rather than write support for locations into my product type module, I wrote a module that allows location module settings to be configured for any product type as they are for content types. I will be gone for a few days, but when I get back I will release this as a stand-alone module unless there have been similar efforts or plans for E-Commerce location integration that could use my contribution.

1 0