March 2008 - Development - lists.drupal.org

Re: [development] reverse selection of node types is clumsy
by David Timothy Strauss 08 Mar '08

08 Mar '08

Drupal is clearly moving to more of a decorator pattern with nodes, so it is becoming increasingly important that we have good, consistent interfaces for controlling which node types modules "decorate" and how. http://en.wikipedia.org/wiki/Decorator_pattern ----- "Dave Fletcher" <fletch(a)splendora.com> wrote: > IMO it's an interesting solution to have a widget for the purpose, > though I'm not aware of other similar pre-fab widgets in Drupal. > > Thinking about this, yeah an admin setting seems wrong. > > If you want your module to automatically enable something for new > node > types, I'd suggest altering the node type form and put a default-on > checkbox. That way, at least the feature can be disabled immediately > after creating the type, and users don't have to hunt down the > setting. > > Cheers, > > --fletch

1 0

New functionality on project nodes installed on d.o
by Derek Wright 08 Mar '08

08 Mar '08

If you own any project nodes on d.o please read this... I just finished up a patch[1] that was holding up a string of improvements to project nodes. The most important new functionality is that you now have more fine grained control over what releases are displayed on your project nodes[2]. First of all, for each version of core, you now have separate controls for every major version, where you can specify if that core/ major combination is supported, and if you want a dev snapshot displayed for it or not. Then, if you've got multiple major versions for the same version of core, you get a radio to select which version is recommended. Update status (both in D6 core and D5 contrib) already knows about all of this, it just hasn't been visible on d.o yet. So, previously, when you changed the "recommended version", update status would immediately warn users they should upgrade, which caused much confusion and hassle. Now, update status will only warn users to upgrade once you uncheck the "supported" checkbox. So, you can have both 5.x-2.* and 5.x-1.* supported, and 5.x-2.* recommended, and update status won't bother people still running 5.x-1.*. However, say you ship a 5.x-3.*, and decide to drop support for 5.x-1.*, you can uncheck the box and update status will tell them to upgrade. Now, all it means when you mark a given major version "recommended" is a) it's displayed as such on the project nodes, b) update status says so in its status report, and c) it's the version that'll be shown in the project teaser in the project browsing pages. Furthermore, recommended releases are now colored green on the project nodes and project browsing pages, whereas -dev snapshots are always marked as red (to warn people not to download them for real sites). I also fixed a caching bug where sometimes the release tables would have "edit" links in them which most users would get permission denied on, while other tables wouldn't have edit links for users who could use them. Finally, I fixed a wonky bug that would require visiting and saving the "releases" subtab of the edit tab on your project node whenever you added a new release for a whole new version of core. Enjoy, -Derek (dww) p.s. Thanks to Tao (starbow) for some of the cool jQuery goodness on that new edit/releases UI. p.p.s. Thanks to Chad (hunmonk) and Adam (aclight) for reviewing and testing this stuff. [1] http://drupal.org/node/176776 [2] http://drupal.org/node/203313

12 27

control javascript behaviors order
by Jack Bates 08 Mar '08

08 Mar '08

I have one Drupal 6 JavaScript behavior which must be run before another behavior, however the JavaScripts which set `drupal.behaviors.x` are included in the page in the opposite order. Consequently the behaviors are called in the wrong order. I did a little googling and read the section of drupal.js responsible for calling behaviors, but haven't found any techniques for controlling the order of behaviors. Do any techniques for controlling the order of behaviors currently exist, or are any planned? Thanks and best wishes, Jack

3 2

RSS feed of devel mailing list
by Alex Barth 07 Mar '08

07 Mar '08

has somebody set up an RSS feed of the development mailing list with an email 2 rss service like mailbucket? http://www.mailbucket.org/ alex

4 4

Request for comments: update_status_aggregator module
by Omar Bickell 06 Mar '08

06 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey folks, Koumbit asked one of the new developers to come up with an xmlrpc-based update status monitoring tool for keeping track of modules on remote sites. We just put it up on d.o. (http://drupal.org/project/update_status_aggregator - no official release yet) and we`d love your constructive feedback on this initiative. Thanks. Omar Co-founder - Koumbit.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfQBZQACgkQZbmlcPSxoWKTgQCfYYkCnQ+YztCLbqM640JOIRfZ MiAAnR34lJZTPSYdJS/hplFMIuf4mKMA =MeXz -----END PGP SIGNATURE-----

1 0

I posted audio of Dries' Keynote and of Jan and Dries' "Presenting Acquia"
by Shai Gluskin 05 Mar '08

05 Mar '08

I posted audio and still pics of your presentations today. http://sgluskin.podomatic.com/ http://flickr.com/photos/sgluskin/sets/72157604041412955/ http://flickr.com/photos/sgluskin/sets/72157604036546908/ Great presentations. Shai

2 1

Request for comments: Remove comment history from issue emails
by Adam Light 05 Mar '08

05 Mar '08

Hi All There has been a feature request to stop including the complete history of issues in each email sent when a new comment on an issue is created. There are two arguments for doing this: 1. It's a waste of bandwidth, etc. to resend the complete history for every issue, and my guess is that most people don't read anything but the most recent comment. 2. Some email programs that display messeges in a threaded format, such as Gmail, display the entire message, and therefore reading multiple comments in one thread in a row is painful. I have summarized our options with this respect in a comment on this issue at http://drupal.org/node/15380#comment-755454 If you have feelings one way or another about whether we should stop sending the complete history and instead send only the most recent comment in issue emails, please respond in the issue queue, not via email. Thanks Adam Light (aclight)

8 8

Views 2 UI
by Keith Smith 03 Mar '08

03 Mar '08

I recently promised merlinofchaos that I would help with the Views 2 documentation. I'm glad that I did. In reviewing Drupal 6 reviews posted across the web, I'd recently read the "Views preview" section of the post http://tek4dpipol.blogspot.com/2008/02/look-at-drupal-6-core-features-2.html, complete with screenshot. I'd seen various Views UI related posts on g.d.o, though I didn't follow any of them closely. I'd seen UI-related discussion scroll past in IRC. I assumed I was pretty well on top of "state of the art" Drupal interface designs. I was so very wrong. I checked out Views 2 over the weekend, in order to get a feel for how I might could help with strings and documentation. It is fair to say that the new interface "blew me away." It is not evolutionary, but revolutionary. Thomas Kuhn would call it a paradigm shift. It's damn sexy. Earl, what I've seen so far is just fantastic. You -- and everyone who has helped you with this -- have made something special here. I think I want to be you when I grow up. --ks

8 13

RTBC is now "reviewed & tested by the community"
by Karoly Negyesi 03 Mar '08

03 Mar '08

Hello world, After Daniel F. Kudwien pointed at http://drupal.org/node/156637 (rename RTBC) in my other RTBC thread, the issue saw a flurry of activity and, much to my delight, I was able to rename this status to something which much better reflects what it actually is. Thanks to: * fajerstarter for the new name * webchick for rerolling my small patch to make the issue state accomodate the longer name. * hunmonk for commiting and applying it on drupal.org. Enjoy! Karoly Negyesi

12 16