December 2009 - Development - lists.drupal.org

Core patch authors/reviewers, please update your groups.drupal.org profile
by Greg Knaddison 09 Dec '09

09 Dec '09

Hello, Periodically I like to do some analysis of the people who were mentioned in commit messages to Drupal core. You can see past sets of data at http://growvs.com/node/599 For this iteration of the statistics, webchick felt it would be interesting to cross reference the data with a list of organizations where people work to see if there are any trends. The best place we could think to get organization data for a lot of people is from groups.drupal.org's "organization" profile field. However, this field is often empty or out of date (you're so busy writing patches, I know). So, if you think you've worked on a patch and are interested in having your work attributed to the right company please go to http://groups.drupal.org/user and fill in the profile field (it's on a sub tab of the "Edit" tab called "Business"). If you get an "Access denied" message, please be sure you are logged in to drupal.org and refresh the page. If you still get an access denied, mail me privately. If you get a message about synching accounts, please follow the instructions to do that :) If you want to make the single sign on better, see http://drupal.org/project/issues/bakery I'll be publishing the stats in the next few days. Thanks! Greg -- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Mastering Drupal - http://www.masteringdrupal.com

2 2

Add data to Drupal session
by Salvatore De Paolis 09 Dec '09

09 Dec '09

Hi, I'm new to this mailing list, I hope is the right place to ask for such questions. I'm writing a module for drupal which implements a jabber client and hooks in the appbar module. The issue i'm having now is regarding the data used for jabber communication. I'm using a jabber class and I need to store this object somewhere so that the _init code is just executed one time. I thought about sessions and I found a couple of ways, both don't works properly for me. First is using the global $user: function jwclient_jabberclass_init() { global $user; if (!isset($user->jabclient) && $user->uid) { require_once('jabber.php'); ... $jab = New Jabber($debug); $jabclient = New JabberClient($jab); $jabclient->jabber_client_set_user($user); ... user_save($user, array('jabclient' => $jabclient)); } } function jwclient_init() { jwclient_jabberclass_init(); ... } function theme_jwclient_chat () { global $user; return $user->jabclient->status; } This solution gives me an errors of __PHP_Incomplete_Class Object. Googling in understood that a proper way to save classes in session is to fistly define the class and than call session_start. I don't see ways to achieve this since the class I'm using is defined in a module and the drupal session is already initiated. A workaround i found on drupal.org is by using serialize/unserialize but it doesn't work around for this case. I changed the code in this way: function jwclient_jabberclass_init() { global $user; if (!isset($user->jabclient) && $user->uid) { require_once('jabber.php'); ... $jab = New Jabber($debug); $jabclient = New JabberClient($jab); $jabclient->jabber_client_set_user($user); ... $jabclient = serialize($jabclient); user_save($user, array('jabclient' => $jabclient)); } } function jwclient_init() { jwclient_jabberclass_init(); ... } function theme_jwclient_chat () { global $user; $jabclient = $user->jabclient; $jabclient = unserialize($jabclient); return $user->jabclient->status; } The result is: warning: unserialize() expects parameter 1 to be string, object given After this, i give away $user and tried with $_SESSION function jwclient_jabberclass_init() { global $user; if (is_null($_SESSION['jabclient']) && $user->uid) { require_once('jabber.php'); ... $jab = New Jabber($debug); $jabclient = New JabberClient($jab); $jabclient->jabber_client_set_user($user); ... $_SESSION['jabclient'] = serialize($jabclient); } } function jwclient_init() { jwclient_jabberclass_init(); ... } function theme_jwclient_chat () { $jabclient = unserialize($_SESSION['jabclient']); return $jabclient->status; } This attempt works on the first call. On the second call I get again the error about __PHP_Incomplete_Class Object. I'm out of clue now. Anyone know how to manage the case of storing objects in session with drupal? Thanks, Salvatore

5 8

Max size of $language->language property
by Scott Reynolds 09 Dec '09

09 Dec '09

So for Activity module we provided multilingual messages not by using t() or tt() but by simply providing a messages per enabled language and for the language column we use $language->language which is 'en', 'en-us'. See this issue: http://drupal.org/node/634006 It appears that is done wrong though, http://drupal.org/node/651174, as this user claims that $language->language = "zh-hans". So what is the right way to handle $language in database tables? What part of the $language object to you use as the field and how large should the column be? And where does it belong on this handbook: http://drupal.org/contributors-guide -- Scott Reynolds

2 1

Re: [development] Consolidating duplicate contrib modules for D7
by Marcel Partap 09 Dec '09

09 Dec '09

[...] Totally agree with your analysis but not with the conclusion that creating documentation of duplicate module's differences is a feasible way out. Especially, all problems tied to the fact that there's an individual person who has sole sovereignty over a certain part of the code - ain't tackled a bit. If the maintainer is 'malfunct' (in some way or the other), 'his' module is doomed, even though it's licensed as FOSS. Only way of circumventing the problem is forking - something the Drupal project really, really does not need more of (quite the contrary!). Instead, IMHO, the responsibility for contrib code development should move from indiviual people to the collective, i.e. every svn ... uuhm cvs account holder should have commit access to all code. Sounds unmanageable at first but seems to work out very well, f.e. with the KDE project. It's kind of like the shared space 'urban design concept' (http://en.wikipedia.org/wiki/Shared_space) - a lack of strict regulation means individuals have to care a lot more about their interaction with other participants. This way communication _and cooperation_ actually become obligatory to making decisions - consequently a more swarmwork-oriented style of interaction evolves. (..and in contrast to real world shared space traffic, in the rare cases where this process fails and b$ code changes indeed are committed, it's very easy to roll back and rework.) So imho Drupal contrib repository should be freed from only-maintainer-writable-restriction to accessible-for-all-devs. The new way of avoiding bogus code commits is not to prohibit developers (who might be perfectly qualified for the task at hand) from changing certain code, but by giving more clearance to everybody. With more power comes more responsibility of course: covert, disagreed code changes are only prevented by social mechanisms, not repository access rights. To reiterate: this process works perfectly well for KDE: although i have only done some tiny commits here and there, my SVN account is not limited! Nothing there to prevent me from committing havoc to core kdelibs code straight away, right now... Still - it never happens! Proceeding from there, the pitiful situation of duplicate modules with overlapping functionality could be entirely prevented for D7 by - identifying with which functionality this has happened in the past - collecting ideas for frameworks (such as messaging, search functionality, shopping cart, payment, web questionaires, workflows, file handling - oh wait that one's cared for already) or spotting existing ones most fit to do the job in D7 - implement frameworks with focus on modularity, customizability - port functionality from existing modules to these new interfaces - raise the bar on adding new 'isolated' modules The switch to D7 is also a good time to introduce these workflow changes, because with the major API restructuring it has seen, most modules will have to change substantially anyways (and be it just to comply with new coding standards) to be in line with HEAD - a good time for converging, tidying up and trashing cruft code constructs from contrib. Earlier this year i already tried to win some support for this idea (admittedly a bit differently in form) but for all reasons, failed miserably. Bytes are cheap though so SCNR to bring it up again. BTW, using the drupalfr.org GIT mirror for D7 and the infamious tig CLI interface makes the repo really much more friendly to manage - is D7 still not the time to move to a 21st century source control system? regards, marcel. > Differences occur because > - development happened in a similar time frame. > - developers do not play well with each other. > - developer B has contempt for developer A's code > - and is not courteous in discussions of said codes weakness so does > their own project. > - modules seem the same but use wildly differing methods to achieve > their results. > > > The problem with the 'have the doc team do it' pretends we have > assigned people that will magically carry this out. > - They will install various modules on clean test sites. > - They will have use cases which will allow the evaluation of the > modules in questions > - They assume the module contributor in question is responsive and > that duplication is the result of 'just happened' instead of hostility > between developers. > - The modules are actually similar enough in function to be accurately > compared. > - Users will magically find the module comparison page and it will be > up to date. > > Not really going to happen. > > The best long term suggestion is to have the maintainers clearly > document any differences on their project page (preferably the ones > who are second should do this by default). People (devs) who have a > need for a module and had to evaluate could submit an issue with a > request to have an updated 'difference' description added. Suggested > sample text would probably help. A module maintainer is not > necessarily willing to go download a similar module if theirs already > fills their needs. > > The ones that are not used die out as tracked on the usage page. > > I would suggest a linked article on how to evaluate a project for use > (and suggest how to get description updates) linked to the top of the > Projects page description would be more useful. > > sepeck > > > On Thu, Dec 3, 2009 at 3:36 PM, nan wich <nan_wich(a)bellsouth.net> wrote: > > Shai Gluskin wrote: > >> Asking the docs team to write module comparison pieces is a good thing > too > > > > NO!!! The comparison pieces should be written by the module developers > or > > one of their advanced users. > > > > > > Nancy E. Wichmann, PMP > > > > Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. > King, > > Jr. > > > > -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

5 5

$form_state passed to form function from drupal_get_form()
by Steve Edwards 09 Dec '09

09 Dec '09

I have a form that I would like to vary slightly depending on the context in which is it being used, changing things such as the form submit button text and the submit function. To indicate the context, I simply need to pass a string to the form function. According to http://api.drupal.org/api/function/drupal_get_form/6, "Any additional arguments are passed on to the functions called by drupal_get_form(), including the unique form constructor function. For example, the node_edit form requires that a node object be passed in here when it is called." So, I define my variable and call my function: $create = 'create'; $output .= drupal_get_form('my_form_function', $create); As indicated in the text from the page (mentioned above), the node_add() function does something similar: $output = drupal_get_form($type .'_node_form', $node); Within my form function, I assign the button value with a case statement based on that. However, when I run the function, I get no value for my button, and a breakpoint shows that there is no value for my variable. Stepping through some more, I find that when it gets to my form function, my parameter that I passed from my call to drupal_get_form is actually the second one, and there is a skeleton $form_state array passed as the first parameter. When I add $form_state as the first parameter in my form and move $created to the second one, it works fine. I can see in line 371 of form.inc where the form function is called using $form = call_user_func_array(isset($callback) ? $callback : $form_id, $args); and at that point $args[0] is basically $form_state and $args[1] is my parameter that is passed ($created in this case). My question is, why this seeming discrepancy between what the docs indicate and what is actually passed to my form function? I haven't seen anything written in PDD or online that indicates that I have to have $form_state as the first parameter in my form function definition when I want to pass it a variable. Am I missing something? Thanks. Steve

3 4

[Fwd: Re: Error defining parameters in hook_theme]
by Steve Edwards 08 Dec '09

08 Dec '09

OK, got this taken care of, and in quite a painless way. The reason I was trying to use a theme function was because I (mistakenly) thought that getting rid of the divs put around the added form element was causing the problem. Actually, the display problems are caused by the margin and padding settings for the tabledrag handle, which cause the fields to combine together. Since the handle is simply added to the first column on the page, I just added an empty column at the beginning of the table in my override of theme_nodequeue_arrange_subqueue_form. Thus, the tabledrag handle gets put in the empty column by itself, and everything lines up nice and neat. Steve -------- Original Message -------- Subject: Re: [development] Error defining parameters in hook_theme Date: Mon, 07 Dec 2009 13:47:09 -0800 From: Steve Edwards <killshot91(a)comcast.net> To: development(a)drupal.org References: <4B1D6E4C.906(a)comcast.net> <ccbb750f0912071335g121b1f86r58368119dd70c0b6(a)mail.gmail.com> Actually, I have everything working as I need it for my required functionality, except for the display of the title as an editable text field. I can save the data in my table and reorder the items using the default nodequeue functionality just fine; it's just the display of the field as a textfield which is causing the problem (see http://drupal.org/node/653574 for details). My reason for trying to use a #theme function for this field was that it appears that the div that is put around the form item in theme_form_item (being called through hook_form_alter) was what was causing the display problem, so I was going to remove it by overriding theme_form_item for that field. I don't think overriding theme_nodequeue_arrange_subqueue_form would work, since the div that is causing the problem is introduced in hook_form_alter. Unless I change the field type in there.... Hmmm... All I need is to get the display of the field working properly; everything else is working as I need it. I'm so close I can taste it... Thanks. Steve Ezra B. Gildesgame wrote: > It seems like you're touching on a relatively common feature for > Nodequeue: Displaying fields from the nodes while changing the > subqueue order. > > 3rd from the top of the Nodequeue issue queue is > http://drupal.org/node/299111, which has an example from one developer > that might be helpful if it's applicable to Nodequeue 6.x. It's > probably easier easier to just theme the whole > nodequeue_arrange_subqueue_form (we have > theme_nodequeue_arrange_subqueue_form) and tweak the presentation of > this field there, since much of the node object is available as part > of the form. > > Ultimately though I think the best and most re-usable solution for > your apparent end goal is what's proposed at > http://drupal.org/node/568100 -- Implementing the Nodequeue ordering > interface as a Views style plugin. Then we could display any field > with Views support and non-developers could customize the interface > for their use case (photo gallery, album mp3 track listing, etc). > > For the question about how #theme works, it might be helpful to > checkout drupal_render(), which checks for $element['theme'], print > out the lone argument passed to your custom theme function, and/or see > http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.htm…. > > Cheers, > > Ezra > > On Mon, Dec 7, 2009 at 4:06 PM, Steve Edwards <killshot91(a)comcast.net> wrote: > >> I need to replace the title with a text field and use a custom theme >> function >> > > > > Ezra Barnett Gildesgame | http://growingventuresolutions.com | http://ezra-g.com > >

1 0

Hook_help()
by Holly Ferree 08 Dec '09

08 Dec '09

I want to put a specific help message on admin/settings/admin. I am creating a theme that I plan to upload to the drupal projects board for free use. So I want it to tell people that it can be colorized. I actually tried using hook_help (so it either doesn't work or I'm doing something wrong...(I'd bet the later)). ------------------------- I tried in hook_help() in the template.php: <?php function hook_help($path, $arg) { switch ($path) { // Help info for the administration theme page case 'admin/settings/admin': return '<p>' . t('This theme is integrated with the color module! To customize this theme go to the <a href="/admin/build/themes/settings/accolade">settings page</a>. ') . '</p>'; } }; ?> Does anyone know what I did wrong? Thanks for your help, Holly Ferree, Graphic Designer, BFA 813.786.0852 hferree(a)gmail.com http://www.designbyholly.com/

4 3

New version control policies/system? (was: Consolidating duplicate contrib modules for D7)
by Cameron Eagans 08 Dec '09

08 Dec '09

Ooo, huge +1 to both points (contrib free-for-all, and moving to something that's not CVS or Subversion). It would be a lot of work to get to that point, and would likely not be something that could happen for the Drupal 7 release, but it sounds like a fair goal for Drupal 8! ----- Cameron Eagans Owner, Black Storms Studios, LLC http://www.blackstormsstudios.com On Mon, Dec 7, 2009 at 8:12 PM, Marcel Partap <mpartap(a)gmx.net> wrote: > [...] > Totally agree with your analysis but not with the conclusion that creating > documentation of duplicate module's differences is a feasible way out. > Especially, all problems tied to the fact that there's an individual person > who has sole sovereignty over a certain part of the code - ain't tackled a > bit. If the maintainer is 'malfunct' (in some way or the other), 'his' > module is doomed, even though it's licensed as FOSS. Only way of > circumventing the problem is forking - something the Drupal project really, > really does not need more of (quite the contrary!). > > Instead, IMHO, the responsibility for contrib code development should move > from indiviual people to the collective, i.e. every svn ... uuhm cvs account > holder should have commit access to all code. Sounds unmanageable at first > but seems to work out very well, f.e. with the KDE project. It's kind of > like the shared space 'urban design concept' ( > http://en.wikipedia.org/wiki/Shared_space) - a lack of strict regulation > means individuals have to care a lot more about their interaction with other > participants. This way communication _and cooperation_ actually become > obligatory to making decisions - consequently a more swarmwork-oriented > style of interaction evolves. (..and in contrast to real world shared space > traffic, in the rare cases where this process fails and b$ code changes > indeed are committed, it's very easy to roll back and rework.) > > So imho Drupal contrib repository should be freed from > only-maintainer-writable-restriction to accessible-for-all-devs. The new way > of avoiding bogus code commits is not to prohibit developers (who might be > perfectly qualified for the task at hand) from changing certain code, but by > giving more clearance to everybody. With more power comes more > responsibility of course: covert, disagreed code changes are only prevented > by social mechanisms, not repository access rights. > To reiterate: this process works perfectly well for KDE: although i have > only done some tiny commits here and there, my SVN account is not limited! > Nothing there to prevent me from committing havoc to core kdelibs code > straight away, right now... Still - it never happens! > > Proceeding from there, the pitiful situation of duplicate modules with > overlapping functionality could be entirely prevented for D7 by > - identifying with which functionality this has happened in the past > - collecting ideas for frameworks (such as messaging, search functionality, > shopping cart, payment, web questionaires, workflows, file handling - oh > wait that one's cared for already) or spotting existing ones most fit to do > the job in D7 > - implement frameworks with focus on modularity, customizability > - port functionality from existing modules to these new interfaces > - raise the bar on adding new 'isolated' modules > > The switch to D7 is also a good time to introduce these workflow changes, > because with the major API restructuring it has seen, most modules will have > to change substantially anyways (and be it just to comply with new coding > standards) to be in line with HEAD - a good time for converging, tidying up > and trashing cruft code constructs from contrib. > > Earlier this year i already tried to win some support for this idea > (admittedly a bit differently in form) but for all reasons, failed > miserably. Bytes are cheap though so SCNR to bring it up again. > > BTW, using the drupalfr.org GIT mirror for D7 and the infamious tig CLI > interface makes the repo really much more friendly to manage - is D7 still > not the time to move to a 21st century source control system? > > regards, > marcel. > > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >

2 1

Error defining parameters in hook_theme
by Steve Edwards 08 Dec '09

08 Dec '09

In a module I'm creating, I'm embedding the subqueue edit form from the Nodequeue module, and I need to replace the title with a text field and use a custom theme function (overriding theme_form_element) for the textfield. I've registered my theme function with hook_theme: /** * Implementation of hook_theme */ function mymodule_theme() { return array( 'mymodule_subqueue_title' => array( 'arguments' => array($element => NULL, $value => NULL), ), ); } And then call it in my hook_form_alter" $form[$item->nid]['item_title'] = array( '#default_value' => $item->title, '#type' => 'textfield', '#size' => 10, '#maxlength' => 50, '#theme' => 'mymodule_subqueue_title', ); and define my function: function theme_mymodule_subqueue_title($element, $value) { The problem I'm getting is this error message: Missing argument 2 for theme_mymodule_subqueue_title() in .../sites/all/modules/custom/feature_package/mymodule.module on line 450. I'm guessing the problem is in how I define my arguments in hook_theme. Is that what I'm doing wrong, or is it something else? Thanks, Steve

3 3

Where to put views questions?
by Richard Morse 06 Dec '09

06 Dec '09

Hi! I posted a question (http://groups.drupal.org/node/36080) to the views developers group on g.d.o quite a while ago. I haven't received any response yet, and I'm wondering if I posted it to the wrong location? Is there some other forum I should be using to ask for help with views? I tried to find other views groups on g.d.o, but didn't find any. Thanks, Ricky The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

5 4