- Development - lists.drupal.org

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

10 Dec '09

> If you want to contribute code to a module, do it by providing a patch > in the issue queue. The reasons for this are legion: Yes, that's the accepted standard approach, and it works well ~90% of the time. But that still means there's a _huge_ number of cases where it _does not work very well_. > * The code needs really needs to go through more than one person > before it is released to the public. How exactly do you define 'release to the public'? Commiting code to a development branch used only by developers? Or releasing ready-made quality-inspected module packages? > The issue queue is the appropriate way to handle that. Well yes, it is one feasible way to handle it. > * The maintainer still really should be the only one creating release > tags, Why? > and for that matter is the only one that can edit the project > page and create the release nodes. mmh.. What is the key characteristic of the internet project with the hugest growth rate in the last decade? (*) > * Sometimes a change can be great on the surface but have horrible > consequences. ..ack, had that before ;) > The person who is most likely to know this is the > maintainer, because they have the most experience with that code. Actually - that's bad for core CMS functionality like messaging, file management, payment, workflow, isn't it? Is it not preferable to have a bigger group of people be involved and familiar to such implementations? > Note that core is the extreme of this, with massive interdependence > and 2 committers. Yes, but there are more than two people in the project capable of grokking every commit that goes into drupal core. These two 'just' mostly do the (highly critical!) job of judging code readiness (relying heavily of course on opinions voiced on the report thread), plucking the cherries from that big colourful issue queue tree ;==) > * If anything I'd say this would discourage people from contributing a > module, since other people breaking their code is now a hassle they > have to deal with. Breaking *whose* code? Is this still free software - or just freeware hosted on a common platform? > * This change doesn't solve any real problem (especially eliminating > forks). Not by itself, of course. We shouldn't do software like some politicians do geopolitics (i.e. 'nicht zuende gedacht' ;) > If the maintainer is not doing their job, there is a process > for replacing them. Bureaucreacy (how tf is this spelled **g) to solve problems that wouldn't exist without it, we need more of it. > If that process needs work then fine, but it at > least mostly works when it is used. Might be or not, it is a barrier, putting people off from contributing. And one's persistence to have his work published somewhere on drupal.org might not be correlated to that work's quality (means good sh1t might - instead of automagically being supported - lay stale = double plus bad).. regards, marcel. * hint: anyone can change any article in wikipedia, anonymously and instantly. That's a NULL height entry barrier. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

7 13

Convention for accessing global variables
by Brian Vuyk 10 Dec '09

10 Dec '09

Obviously, there are two ways to access global variables. 1. Via the global keyword: <?php global $user; print $user->uid; ?> 2. By accessing the $GLOBALS array directly: <?php print $GLOBALS['user']->uid; ?> Is there an established convention for this within Drupal core? The majority of cases in HEAD use the global keyword (~470) instead of accessing the $GLOBALS array (~40 cases). Is this something that should be made a coding style issue for consistency across the codebase? As a sidenote, accessing the $GLOBALS array directly in on average 25% faster than using the global keyword. Of course, both run fast enough that the difference is hardly noticeable. Brian Vuyk

3 3

Style's stuff
by Gustavo Cabral 10 Dec '09

10 Dec '09

Hello everyone: I need to change the look of certain pages, ie I have installed the organic group, and only I want to change the appearance of any content generated by this module with CSS. How can I differentiate them from other content? I know I have to change or rename the file page.tpl.php, but I do not know what I need to put as file name. I am a rookie in styles, forgive me. Thank you very much. I appreciate their support. Gustavo .-

3 2

consulting about user maps
by Gastón Pablo Pérez 09 Dec '09

09 Dec '09

Hi! I'm using Drupal 6 and i want to add something to view in the user profile a map (gmap if it's posible) with her/his location. how can i do that? I would like to edit a particular user and add data for example the street phone city, country, etc. Also it would be well if i would be able to relate several users to the same location. thanks in advance. Gastón Pablo Perez Email: gpperez(a)gmail.com Web: http://cv.gpperez.com.ar

2 1

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