- Development - lists.drupal.org

Wasting time and effort
by Michael Favia 10 Mar '09

10 Mar '09

I've noticed an increasing number of "meta discussions" and I'd like to try to refocus our collective efforts if possible. All of these discussions about regulating contribution module development or only releasing core when the top X modules are upgraded, are more distracting then they are productive in my opinion. It is a dearth of labor not a lack of ideas that is the bottleneck of this project and almost every one of the issues raised could be fixed by more work in place of increased regulation. The ordinary folks who review and create patches on issues are our lifeblood and engine. While it might not be as glorifying as re-imagining the contribution module ecosystem or as easy as writing an email, we notice and value your effort for the real contribution that it is. We dont need more regulation, we need more contribution. So lets pick up our shovels instead of our pens and get to work (myself included). If you don't know how and want to learn how just ask in channel and I'll be happy to help you personally. -mf

16 29

Re: [development] Wasting time and effort - Here's a productive suggestion instead
by Dan Morrison 10 Mar '09

10 Mar '09

I tried to post this into the thread earlier, but I may have been blanked due to using a different email (? I only use the digest) Anyway ... Re Suns suggestion earlier about a review period - I proposed the same a long while ago. [A suggestion for reducing new-duplicated modules : require RFC or statement of intent posting] http://drupal.org/node/316973 PLEASE Look at that thread and you will see many others also against *enforcement* ( = manpower & acrimony) but for a generally useful community-based process. Note, not a "core developer" gatekeeper team, but better visibility and feedback loop to resolve dupes. It got to the 'nice idea' stage, but no further. Everyone is welcome to review duplicates over in the [Duplicated Modules hall of shame] http://groups.drupal.org/duplicated-modules-hall-shame where these issues are acknowleged, and hopefully being worked towards. Please see the wording of the statement of intent over there. I'd like to keep out of this debate, which is not succeeding in convincing either Marcel or everyone else, but : > > Well it's not that my proposal is totally unrealistic. Only because no > one is supporting it does it become so. Would Dries or Angela have > proposed it, everybody and his dog would be up in flames of enthusiasm > and surely consider it the right way to go. It could be that everyone disagrees with it because they think it's a bad idea. If one person says doing something is a stupid idea, they may just be being mean or not have had their coffee yet. If three random people say it's a stupid idea, maybe they're ganging up on you. (you could consider what seemed to prompt that) If half a dozen long-time developers, each who have seen this or similar suggestions several times before, try to explain at length exactly why a certain approach isn't such a practical idea, consider the possibility that they may know what they are talking about. If the whole world disagrees with you, you may be the messiah, but you're probably just wrong about this one thing. .dan.

3 2

wit's end: altering options for an optionwidgets_select element - OR - life without #DANGEROUS_SKIP_CHECK
by Harry Slaughter 10 Mar '09

10 Mar '09

I want to alter the options for a cck optionwidgets_select element based on data in the node itself. I can't use a function in the cck widget configuration page because that's called before the node is loaded, so I don't know what the options should be yet. I can't do it in hook_form_alter() because optionwidgets_select elements have not yet been fully rendered (the actual options for the select have not been set yet). I can make the alteration using #pre_render, but then form validation has run already so I've corrupted the form and I fail _form_validate() and get the 'illegal choice...' error. And I cannot use the drupal_process_form()/drupal_rebuild_form() trick (as seen in AHAH) because the #pre_render callback does not have access to $form_state. I can't use #DANGEROUS_SKIP_CHECK because it has been removed. Maybe I could use AHAH, but that would be very hacky as I do not need any input from the user in order to generate my options, just data from the node itself. The upgrade doc says to look here for alternatives to #DANGEROUS_SKIP_CHECK: http://drupal.org/node/182310 - yet that issue supplies no examples of a workaround. I understand the reason for removal of #DANGEROUS_SKIP_CHECK, but this use case is the type that the option was truly created for (I think :) I'm posting this question to the list after several days of trying every solution I could think of. If there is a solution, surely it will help others as well. -- Harry Slaughter Web Developer Devbee - Effective Drupal http://devbee.com/ 619-249-8780

2 2

Drupal 7 "When it's Ready"
by Aaron Winborn 08 Mar '09

08 Mar '09

I'm concerned about the sentiment in Dries' declaration of Drupal 7 will be released when it's ready. I know this has been hashed out before, for instance back in September with Disparity of Versions: Towards Creating a Sustainable Solution to the Disparity between Drupal Core and Contributed Modules (http://drupal.org/node/311893) (which was itself an eloquent continuation of a long-standing discussion). I still strongly believe that we're shooting ourselves in the foot when we continue to use "0 critical patches" as the sole metric of a core release. Core MUST BE informed by contrib. To do otherwise is to create a divide of development that means six to nine months of the vast majority of sites waiting on critical module updates. In the referenced thread, chx asked, "Creating a "golden" contrib has been discussed for very long. It's not clear what we would achieve and who would work on achieving that." Acquia has answered that quite well. Acquia has stepped up to fill in this need with their official "Acquia Drupal", with its list of 21 supported contributed modules. I applaud their efforts. To quote them, they address this need: "From the thousands of Drupal modules, Acquia has selected some of the most commonly used and essential community modules for building modern, social publishing websites without programming." Chx continued with "Also, the whole issue is IMO Drupal 6 specific. As Drupal 5 is such a fantastic release, people felt it's good enough to serve longer and redesigned the architecture of their modules. This is not something that will be repeated soon IMO. As the Drupal 7 cycle is made longer, the issue will smoothen itself out during the next half year." I believe that lengthening the core development cycle is an answer, but still not THE answer. The unstable releases have certainly been a boon, and it's exciting to see a few modules beginning to create unstable releases; this is core informing contrib, and webchick has really stepped up to the plate to make that happen. However, no matter the fanfare with which Drupal 7 will be released, few sites in the wild will upgrade until their required contrib modules have been upgraded to that version. Yes, Drupal 6 was exceptional in the time required before major adoption. In a nod to contrib, fields and views are going into core, which is a direct way of contrib informing core. But there will always be a new Views or CCK that takes off like wildfire, and there will often be times when adoption of a new release of core will be held up by waiting development on a new and complex contributed module. Maybe not Drupal 7, but if we don't address this concern in a systematic and thoughtful way, it will possibly happen by Drupal 8, and certainly by Drupal 9 or X. Another show-stopping factor in creating a new metric is agreement on what metric to adopt. The team that penned Disparity of Versions were intentionally agnostic to metric in their discussions. However, no matter how these golden modules would be selected, and regardless of how that could be gamed, the reality is there will always be important contributed modules that the community depends upon. We can look to Acquia and other companies to identify these modules for us. That's a good thing, and irrelevant to the discussion. In fact, if the community would step up and take responsibility for these issues, it would validate their efforts. I propose that we take the tool that was not yet available at the time of the original post. We now have a publicly available metric of modules at use in the wild. Let's just take the top 10, top 5, or even top 3 modules and call those our "golden modules". Create a new "Supported modules" that dynamically consist of these modules; that can be tweaked once we have some experience with it. Then don't release Drupal 7 until there are 0 critical issues in its queue, AND each of the Supported modules has an official release. The community already works with the modules they need to help with that effort; this gives them more incentive and validation. If a Supported module is not making sufficient progress in an acceptable amount of time, that's likely a sign that perhaps it should be removed from that tier and back into the wild of contrib, so that things are not held up unnecessarily. I strongly believe that these simple steps will make the release of Drupal 7, and each subsequent release, the best release ever. Thanks, Aaron Winborn

22 39

How to clear database after a regular interval
by sivaji j.g 08 Mar '09

08 Mar '09

Hello geeks, Most of the drupal modules has test site programmed to clear database after a regular interval, i would like to know how it works. I want to do the same for drupal quiz module demo site, The demo site has been hosted at bluehost which has cpanel where i have options to write my own cron and run it, but i have no idea on how to use it for this purpose. Any suggestions and criticisms regarding this will be appreciated. -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/

6 6

feeds for docs? and "developers" group?
by Ivan Sergio Borgonovo 07 Mar '09

07 Mar '09

Reading the "When it's Ready" thread I've just learned 2 important things: - there is an automatic tool to help porting modules (deadwood) - now there are good docs about SimpleTest Sometimes I look into discussions or docs or "groups" to see how to best deal with cvs when you use another tool internally, how to setup multisite, if there is anything new about DB API I could exploit etc... Sometimes the docs get stale, outdated or it just don't solve my problem. a) it would be nice if dev could be kept updated on changes to specific sections of docs. b) is there a place to discuss about how to become better drupal developers? techniques, tools etc... Every time I learn something from a ml that could be useful to others or I may "forget" I've the habit to take notes on my (oh!) drupal website. If there was a place where to discuss how to become better drupal developers (and maybe there is such a place) I think the documentation would be even larger and maybe some recurring topics would be less frequent. The dev list most frequent use seems to be: - core announcements and strategies - how do I program this? but not: how do I become a better drupal dev? -- Ivan Sergio Borgonovo http://www.webthatworks.it

2 2

Re: [development] a (probably) simple question w.r.t. drupal_execute
by Aaron Winborn 07 Mar '09

07 Mar '09

Matt, You could also use module_load_include('inc', 'uc_attribute', 'uc_attribute.admin'); Aaron ----- Original Message ----- From: "Matt Funk" <matze999(a)gmx.net> To: development(a)drupal.org Sent: Friday, March 6, 2009 6:59:05 PM GMT -05:00 US/Canada Eastern Subject: Re: [development] a (probably) simple question w.r.t. drupal_execute mmhh, well, to answer my own question, i guess i had to do a include_once(drupal_get_path('module', 'uc_attribute'). '/uc_attribute.admin.inc'); in the module file in order to have access to that form. It looks like it works now. Anyway, is it better to post stuff on drupal.org than on this list? thanks matt On Friday 06 March 2009, Matt Funk wrote: > Hi, > > i am pretty new at developing stuff in Drupal. So this question is probably > an easy one to answer, but i am still new enough that i don't even really > know where to look to start the debugging process. And i am hoping this is > the correct list to post to. > > Anyway, here's the question: > > I am simply trying to programmatically create an attribute for ubercart > (ver2). As far as i can tell drupal_execute seems the easiest (and > intended?) way to do this. > > So i create my $form_state array etc... > Then $form_id = 'uc_attribute_form'; > > When i put that into the module and the menu callback is executed i get: > > ... > warning: call_user_func_array() [function.call-user-func-array]: First > argument is expected to be a valid callback, 'uc_attribute_form' was given > in /home/content/x/p/d/xpdtek/html/drupal-6.10/includes/form.inc on line > 366. ... > > So apparently i am not quite getting something here. My first guess is that > the form_id is wrong. But uc_attributes is enabled and from what i can tell > the form that lets me manually create an attribute is called > uc_attribute_form (located in uc_attribute/uc_attribute.admin.inc). > > > Can anyone shed some light on this for me ... > > > thanks > matt

1 0

a (probably) simple question w.r.t. drupal_execute
by Matt Funk 07 Mar '09

07 Mar '09

Hi, i am pretty new at developing stuff in Drupal. So this question is probably an easy one to answer, but i am still new enough that i don't even really know where to look to start the debugging process. And i am hoping this is the correct list to post to. Anyway, here's the question: I am simply trying to programmatically create an attribute for ubercart (ver2). As far as i can tell drupal_execute seems the easiest (and intended?) way to do this. So i create my $form_state array etc... Then $form_id = 'uc_attribute_form'; When i put that into the module and the menu callback is executed i get: ... warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'uc_attribute_form' was given in /home/content/x/p/d/xpdtek/html/drupal-6.10/includes/form.inc on line 366. ... So apparently i am not quite getting something here. My first guess is that the form_id is wrong. But uc_attributes is enabled and from what i can tell the form that lets me manually create an attribute is called uc_attribute_form (located in uc_attribute/uc_attribute.admin.inc). Can anyone shed some light on this for me ... thanks matt

4 6

Drupalcon tag for issues
by Dmitri Gaskin 07 Mar '09

07 Mar '09

Let's tag all code sprint issues "dc2009 code sprint" Thanks Dmitri

1 0

Re: [development] Drupal 7 "When it's Ready"
by Aaron Winborn 05 Mar '09

05 Mar '09

On Wed, Mar 4, 2009 at 5:50 PM, "Moshe Weitzman" <weitzman(a)tejasa.com> wrote: >Dries did not say anything about D7 that should cause concern. He just said "when it is ready" and we can all discuss what that means. You are assuming it excludes Contrib. But even more productive IMO would Dries actually followed up "when it is ready" by stating it'll be ready when there are "0 critical patches". But I'll certainly give him the benefit of the doubt, and not read any more into that statement, nor from any omissions from that statement. The last thing I want to do is put words in his mouth. >be to discuss what we can do to help modules upgrade quickly. Lets not even get into the reasons why D6 Contrib adoption was slow. What documentation is needed beyond the upgrade page (screencasts, coder/deadwood, .webinars, ...). Can we provide testing infrastructure for contrib modules? Could we focus the issue queue so issues about upgrading are more easily handled? Yes, yes, yes, and yes! A "Supported Tier" of modules by itself would do nothing to solve the issue. We need all of what you've suggested regardless of the outcome this proposal. That means we all need to work towards making this happen, regardless of the metric (or metrics) Dries chooses to use for the release of Drupal X.

1 0