May 2008 - Development - lists.drupal.org

programmatic creation of node
by Novák Áron 11 Jul '08

11 Jul '08

Hi! While the development of FeedAPI, i faced with a problem. FeedAPI has to create nodes programmatically, i believed that this is a really easy thing to do, feedapi now works like this: $node->data1 = "foo"; $node->data2 = "bar"; node_object_prepare($node); // this is about the default values node_save($node); But I got a report that this is not a good way to do: http://drupal.org/node/196273 Summary: "node_object_prepare() and node_prepare() functions are meant to simulate the demonstration of a node" And some users, who use FeedAPI + 3rd party modules together, really experience bugs around node creation / handling: http://drupal.org/node/195105 (summary: the core forum module uses form_alter to pass taxonomy-like data. And this data is lost now.) Can you suggest me a perfect way to handle this problem? mustafau (http://drupal.org/user/207559) suggested to use drupal_execute($form_id, $form_values), but in this case, i had another problem: drupal_execute has no useful return value and $node structure remains unaltered, so i had to do a node_load after this, which is quite expensive. Thanks, Aron Novak

11 20

Re: [development] Trust (was: Hit and run contrib)
by Jakob Petsovits 04 Jun '08

04 Jun '08

On Friday, 30. May 2008, Daniel F. Kudwien wrote: > We are parsing the "#12345" bit, but why don't we also parse the "by sun" > bit to assign 'contributor credits' to users for the corresponding project? Imho that's a quick-and-dirty workaround, whereas the proper solution would involve letting the contributor commit the patch by herself. That might either be reached by switching to a distributed VCS (where "committer" and "uploader" are decoupled from each other - probably the right solution for core) or by the even more open-sourcey way of granting access to all of contrib by default. > OTOH, if there was a prepared candidate - would you really grant CVS > access? Would you grant access to me? The question is "would I trust you not to mess up my modules"? Personally, I'm confident that you are careful with other people's modules (given your previous track record), I would grant you commit access to all my projects in a second because I know that you won't abuse that power. But that is the core of the issue at hand here - we've got lots of CVS accounts, but we don't trust them a single bit. Instead of relying on trust and goodwill, we rely on technical measures to lock out potential helpers before they even get the chance to do something wrong. Now there are plenty of arguments against this, but I think trust is a crucial element in open source projects, and stimulating involvement is important *especially* for modules that have wide exposure and a large user base. I think granting CVS access should be the default, as well as expecting the account holders to follow a commit policy that we set up. Instead of denying commit access to single directories, we'd trash the CVS account of people who don't respect the commit policy (which would involve not pissing off the respective module maintainer). That also has the consequence that people who deliver more and better code for a given module can't be blocked by inactive maintainers anymore, instead the maintainers have to actively work on their status as project leader. Which in turn stimulates progress both of "external" contributions and of maintainer involvement. As of now, modules are considered to be the personal property of a given person or company, even if their importance has a much higher impact than those. I think we should get away from this notion, and consider modules on drupal.org the joint property of the community, not only in license but also in governance. If collaboration doesn't work out (which I believe will be the exception much rather than the rule), one can still fork anything and come up with something else on his own. That's how open source normally works, and I fail to see why drupal.org needs to be the big exception. If we grant CVS access to people, we should trust them to fix more stuff than they break. If they break more stuff than they fix, retract commit access on the whole. Think about how we can make a transition to trusting people. Wishes, Jakob P.S.: A showcase. KDE has a repository where each committer has access to the whole SVN repository, and an accompanying commit policy [1] (next to other policies). Potential committers need to formally apply for an account, but when they get one then they're trusted to do stuff right. And you know what? It works. Bugs are fixed by people who would otherwise just be watching the progress, and code gets ported by people who modify the base framework. Just recently I fixed a few trivial bugs in Kate, which made me motivated enough to join the Kate development list and post a few more, less trivial patches there for review - if they're approved, I can commit them on my own. On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess. Now you can critizise me for being lazy, but I think this is symptomatic and happens all the time. If we want to scale contrib, we need to lower the contribution barrier for people who are able to fix stuff, while raising the barrier for people who break stuff. Let incompetent CVS users release their modules on their own server (they're probably no good for drupal.org either) and educate them to get into version control and patches before they're granted a CVS account. In turn, give trust to the people who actually have proven to be worthy of a CVS account. [1] KDE commit policy: http://techbase.kde.org/Policies/SVN_Commit_Policy *goes off to get his flame-resistant jacket*

7 14

Hit and run contrib
by Caleb Gilbert 03 Jun '08

03 Jun '08

No real propositions here - just observations...but with the popularity of Drupal growing by leaps and bounds the amount of flaky hit and run maintainers/contrib-modules also appears to be growing exponentially. It's annoying. :p - Caleb

15 22

Re: [development] How Trellon gave back to Drupal (May 2008)
by Samuel Rose 31 May '08

31 May '08

> > Date: Fri, 30 May 2008 20:02:29 -0400 > From: Earnie Boyd <earnie(a)users.sourceforge.net> > Subject: Re: [development] How Trellon gave back to Drupal (May 2008) > To: development(a)drupal.org > Message-ID: <20080530200229.suha3owy9qtc0go0(a)mail.progw.org> > Content-Type: text/plain; charset=UTF-8; format="flowed" > > Quoting Robin Monks <robin(a)robinmonks.com>: > > > Now, I appreciate that trellon is being so helpful to the community. > That > > said this felt like one of those cheaply made 3 minute paid commercial > ads > > for the magical do-all blender and dog food mixer that comes up right in > the > > middle of a good movie on TV. I wasn't expecting to need a TiVo just to > > read the Drupal dev list. > > > > I have mixed feelings on this. I think the information is good but I > don't know that I want every producer of modules and patches to do the > same on this list. I think that a g.d.o would be better then I could > subscribe to the group to get the updates for the ones I want to watch. > Others mention Planet but that appears to me to be an aggregate from > any site publishing data about Drupal it might be the place but > subscribe/unsubscribe isn't available for a particular interest. > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/ > > > > I think it's cool to know who is doing what. It would be neat to actually see a report from other module developers who are releasing work like this, displayed prominently and in an easy to find and follow way. A dedicated group on g.d.o could be a great option. Plus, this could be cross linked with the project pages on drupal.org, for instance. This type of publicity could help people attract more funding for their development work, by helping people get a better understanding for what they are doing in detail over time, for one thing. -- Sam Rose Social Synergy Tel:+1(517) 639-1552 Cel: +1-(517)-974-6451 AIM: Str9960 Linkedin Profile: https://www.linkedin.com/in/samrose skype: samuelrose email: samuel.rose(a)gmail.com http://socialsynergyweb.com/services Related Sites/Blogs/Projects: OpenBusinessModels: http://socialsynergyweb.net/cgi-bin/wiki/FrontPage http://p2pfoundation.net http://blog.p2pfoundation.net http://www.cooperationcommons.com http://barcampbank.org http://communitywiki.org http://openfarmtech.org Information Filtering: http://ma.gnolia.com/people/srose/bookmarks http://del.icio.us/srose http://twitter.com/SamRose

1 0

How Trellon gave back to Drupal (May 2008)
by Morbus Iff 31 May '08

31 May '08

http://www.trellon.com/ As a well-known Drupal shop, Trellon continually strives to contribute back to the Drupal community in any way it can. Sometimes, we're just too busy, other times, we're just plain ol' lazy and, more often than not, Morbus is complaining about quality or phenoptosis or whatever. By keeping track of what we give back, however, we hope to more clearly see how much we are, or aren't, helping Drupal help ourselves. This month saw the release of a number of modules: Xapian integration http://drupal.org/project/xapian http://www.trellon.com/blog/xapian-search-drupal "A common challenge for Drupal sites is working with documents in different formats and getting them into the search engine. Drupal does not natively index PDFs and Word documents, despite the fact they are the most commonly exchanged text formats on the Internet (outside of HTML) ... [we've] developed a module that replaces Drupal's native search features with the Xapian search engine." Teleport 1.0 http://drupal.org/project/teleport We announced this last month, but our "hotkey-activated launcher utility inspired by Quicksilver" has reached 1.0, for both Drupal 5 and Drupal 6. On a recent project, we've had to provide simple event signups and payment acceptance. The signup module provides part of this solution, but we also added the signup_pay and signup_status modules to the mix. Some remaining requirements resulted in a few additional companions: Signup Pay Early Bird http://drupal.org/project/signup_pay_early_bird Adds two extra fields to the signup_pay module that allows the event creator to specify an early bird discount rate, or percentage, which is then taken into account by signup_pay (req. small patch). Signup Restrict by Role http://drupal.org/project/signup_restrict_by_role Adds the ability to restrict signups to a particular role. For example, if you only want users with the "members" role to be allowed to signup for a particular event. Event Webform http://drupal.org/project/event_webform Adds the ability to relate a webform to an event. This is particularly useful for letting users include requirements for the event (do they want lunch, a room, pickup at airport, etc.) A healthy number of patches were also contributed, plus one for core: Drupal core: Allow new comment timestamp to be passed http://drupal.org/node/253577 constant_contact: subscriptions.module integration http://drupal.org/node/263691 link: Extra url parameters http://drupal.org/node/256490 mailhandler: Dies if command line found with no command http://drupal.org/node/253906 services: XMLRPC server does not honor optional parameters http://drupal.org/node/179848 signup_pay: various typos http://drupal.org/node/260066 http://drupal.org/node/260524 signup_pay: Add new status code link doesn't show correctly http://drupal.org/node/260527 signup_pay: Role weights errors http://drupal.org/node/260539 signup_pay: Allow other modules to change payment amounts http://drupal.org/node/263575 usernode: add user roles as a viewable field within views http://drupal.org/node/260780 Until next month, superfriends, Develop Drupal Daringly! -- Morbus Iff ( damn you richards! i will have my revenge! ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus

20 25

Slow down with the official releases of contrib already, ok? ; )
by Derek Wright 31 May '08

31 May '08

I've noticed quite a few projects that seem to think the best time to make a new official release is after every CVS commit. While I'm happy to see people actually making official releases, please don't do this. ;) A) Constant stream of noise for your users thinking they have to keep upgrading all the time (via update_status, etc). B) Wasteful of resources (burns up diskspace on d.o for all the tarballs, bandwidth for all the downloads, etc). C) Wasteful of RAM for sites using one of your modules with update_status (update_status needs to download and parse an XML file describing the history of all your module's releases -- as the # of modules on a site grows, and as the number of releases of your module for a given version of core grows, the RAM consumption starts to go through the roof -- see http://drupal.org/node/238950) D) A new tarball after every CVS commit is exactly what the automatically re-generated development snapshot releases are for: http://drupal.org/handbook/cvs/releases/types#snapshot Please don't cry wolf. Only make a new official release when it's really worth it for everyone to upgrade. Thanks, -Derek (dww) p.s. Learn about this and other best practices for release management by reading the very concise 2 page handout about the topic I gave out at my talk at the Boston DrupalCon: http://drupal.org/files/maintain-release-handout.pdf p.p.s. If anyone wants to help fix update(_status)?.module to be less RAM hungry, please join us over at http://drupal.org/node/238950.

21 38

From Docs Team to Developers: Question on Block Visibility in D6
by Shai Gluskin 30 May '08

30 May '08

Developers, The current "Overview on Block Visibility Handbook page<http://drupal.org/node/64135>is tagged "4.7, and 5." Have things changed in D6 on this matter, especially in regard to writing php snippets to insert at admin/build/block/configure/.../...? Shai

1 0

Module Idea/Suggestion
by Jon Antoine 30 May '08

30 May '08

I just had an idea for a module and thought I would throw it out to the development community and hopefully get some feedback on it. I searched Drupal and couldn't find anything already offering this functionality. I'm not sure how common it is with everyone else, but every site I build has a test site on my test server and a live site on my live server. It is not a complicated process to push the test site to the live site, but it is a time consuming one, so why not have a module do it for you? A beginning set of steps: 1. Backup up database 2. Upload Added/Modified/Deleted changes to files 3. Update database The module would need to allow you to specify an ftp location to upload the files to and also allow permission to update the database. I am not as advanced a programmer as some of you so I am hoping for any feedback. Let me know what you think? Cheers, -- Jon Antoine, Owner Antoine Solutions

7 11

Re: [development] hook_file, still relevant or not?
by Darrel O'Pry 28 May '08

28 May '08

@see: http://drupal.org/node/142995 Do we still want completely different eco-systems of file handling modules? FileStore*, upload*, *field, the various media type specific file modules, media mover, disknode, and now fileframework, etc... Or would some of you folk actually like to start having somewhat unified file handling where an individual's work is more widely interoperable....

1 0

Knight Drupal Initiative launch
by Ken Rickard 28 May '08

28 May '08

Announcing the Knight Drupal Initiative ============================ The Knight Drupal Initiative is now accepting grant applications. Anyone may apply at http://groups.drupal.org/knight-drupal-initiative. Application is a two-stage process. First, an open community review will select proposals for submission to Knight Foundation. After submission, Knight Foundation will have final approval over grant funding. More information is available at http://groups.drupal.org/node/10461. There are no deadlines for submission. The program establishes an ongoing grant review process. New proposals will be reviewed monthly by the Knight Foundation. About the program ============= Together, Drupal and the Knight Foundation are working to improve communities by providing a freely distributed, open source digital publishing platform. We are looking to fund proposals that achieve our mutual goals. Drupal and the Knight Foundation agree that open source digital publishing can enable powerful agents of transformation in their respective communities. Together, we are working to improve communities by providing an open democratic platform in the digital age. We provide funding for grant proposals that achieve our mutual goals by using and improving the Drupal platform. More information can be found on the KDI Frequently Asked Questions page at http://groups.drupal.org/node/10464. Proposal guidelines ============== A good proposal should improve or leverage Drupal in order to meet the stated goals of the program. When writing your proposal: * Be clear and concise when answering the questions. * Be sure that both novices and experts will understand what you propose. * Be honest and positive when describing your proposal For more tips, see http://groups.drupal.org/node/10462. Introductory meeting =============== With the launch of the Knight Drupal Initiative, many people have questions. Ken Rickard will host a live IRC chat on Monday, June 2nd, starting at 15:00 EDT [UTC - 4:00]. The chat will be held in #drupal-dojo on freenode. For information about IRC, see http://drupal.org/node/108355 For more on the KDI, see http://groups.drupal.org/knight-drupal-initiative Note ==== [This note also went to registered members of the KDI group. Please forgive the cross-post.] -- Ken Rickard agentrickard(a)gmail.com http://ken.therickards.com

1 0