March 2009 - Development - lists.drupal.org

Re: [development] Duplicated modules
by As If Productions 12 Mar '09

12 Mar '09

At 05:45 AM 3/11/2009, Ivan Sergio Borgonovo wrote: >What I'd find useful would be >- better categorisation system and better search system on categories Big +1 on that. >- a flag to check if a module provides an API or is just an application >- an activity index (average lines of code changed/time) >- a issue queue index Regular +1 on those. >Maybe we could let people (other than the maintainers) to >"categorise" the project. Best idea I've heard yet. Ivan, I want to have a beer with you. >I really don't see duplication as a problem. Ditto. In fact I appreciate it. It's finding the one you need that is the problem. The way I see it, this problem requires a taxonomical/navigational solution, not a paradigm shift in methodology. It would have to be an ongoing task/project in its own right, but IMHO it's one that could easily be supported by less-than-hardcore developers. LVX TF --- As If Productions http://www.asifproductions.com Interactive Worlds and Immersive Obsessions

5 4

arg_separator
by Dave Cohen 12 Mar '09

12 Mar '09

Is there a reason for this in drupal's default settings.php? ini_set('arg_separator.output', '&');

2 1

Failed to install HEAD
by Dave Cohen 11 Mar '09

11 Mar '09

I'm trying to submit a patch which changes a form in install.php. Because of that change the test bot always fails with "Failed to install HEAD". At least I'm guessing that's why, the error message really gives no explanation. Is there something I can include in the patch to make the test bot succeed? The patch is here: http://drupal.org/node/394282 Thanks, -Dave

4 4

sandbox projects
by Jim Taylor 10 Mar '09

10 Mar '09

I'm curious is there is a handbook page on developing sandbox projects. A Google s/d.o search doesn't turn up much (saw mention of it on a recent thread and the one module I have contributed had a 3 years old attempt in there) -- Jim Taylor Rooty Hollow LLC, Owner jim(a)rootyhollow.com www.rootyhollow.com (614) 886-5530 Twitter: jalama Linkedin: http://www.linkedin.com/in/rootyhollow

2 1

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

10 Mar '09

> From: Marcel Partap <mpartap(a)gmx.net> > >> PLEASE Look at that thread and you will see many others also against >> *enforcement* ( = manpower & acrimony) but for a generally useful >> community-based process. > So enforcement of coding style and not breaking tests is too large of > a price to pay, now i see. Coding style reviews are good, and can even happen automatically. That's trivial. There is even a process for running automated tests. Although you may find that almost no contrib modules HAVE tests. This is a non- automatable detail. Modules breaking tests is not an issue for users. However, neither of these have anything to do with the very real issue of DUPLICATION and overlap. >> Note, not a "core developer" gatekeeper team, > Even after me going to lengths doing 20 or so postings to explain and > reason what i have in mind, it's amazing people still misunderstand > what i propose. Is it me or them. The ONLY way to actually tell good code from bad code, and tell duplicates and redundancy is by informed developer review. That is the manpower needed. And as noted earlier, it needs to be skilled devs, not just popular vote. Which leads us to back to requiring housekeeping work by some non-existent cadre. >> but better visibility and feedback loop to resolve dupes. > Frigging exactly what i proposed. No. "Visibility" and feedback on proposed modules was was my suggestion last year. What I saw you propose in [Date: Sun, 08 Mar 2009 16:30:29 +0100] was bureaucracy, enforcement, automation, restrictions, vetos, and the belief that better code could be automated by : > what is possible is to come up with an algorithm that leads to > a statistically significant improvement on the sustainability and > correctness of decisions. I just gotta disagree that good, or more importantly - useful and unique - code can be judged by an algorithm in a way that will address the problem at hand. If you have such an algorithm handy, please suggest it as an addition to coder.module. > Why does that make me wonder > what sort of device would be required for making a human being to > constructively try to understand someone else's perspective and > subsequently reconsider their own position. :-) > > btw abundant opposition happened before in history to non-messiah > people which were more right than wrong. And so you completely miss the point. o_O Just because lots of experts disagree with you does NOT prove that you must be right. There are a heck of a lot more folk who were told they were wrong - and were wrong. Citing an exception only proves the (general) rule. Whether we are a meritocracy, a democracy, a timocracy or a dictatorship (benign or not), your campaign to make contributing to Drupal three times harder for everyone is just not getting any traction. Vast numbers of people already find CVS and patches a heck of an obstacle. I've had dozens of probably-OK patches die in the water because it there wasn't enough motivation for even one other valid developer to help push it through. Requiring a quorum of *10* votes as you proposed means that nothing would happen ever. If it was even conceivable that Drupal contrib became so draconic, it would force contributions into the "badlands" (see proposal http://drupal.org/node/307211) and possibly be divisive enough to justify a totally parallel repository of 'unvetted but free' code on another site. I (and many others) don't want to see that happen. *sigh* To end on another hopefully constructive suggestion, module voting and rating has ALWAYS been discussed and proposed, and is one of the key requested features the background of the d.o. redesign. If this comes though as providing a top list of recommended or even semi-official modules, that is a good thing. But such ranking or classification is NOT going to take the form of prohibiting people from contributing new innovation. You describe your elaborate voting system as one where not enough votes = no commit access. That may be what is turning everyone off. Voting for informational purposes, I think we could get behind. But making rules that will negatively affect the majority of developers and damage the community ... not popular. It may be possible to rework your proposal in a more practical way - but only if it enables the community by shepherding input, not as a bully cop that bans input by default. .dan.

1 0

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