- Development - lists.drupal.org

Select to auto-submit
by Brett Evanson 12 Mar '08

12 Mar '08

Any way we can make an exposed filter do an autosubmit when they select one of the options? Does the Javascript Tools module have anything to do with this? -- Brett Evanson <mailto:brettev@gmail.com> brettev(a)gmail.com

2 1

drop sprint this Thursday
by Kristof Van Tomme 12 Mar '08

12 Mar '08

Anybody wants to join me on Thursday (5PM CET - 10AM PDT - 1PM EDT) for a DROP Sprint? We get together on IRC and we go through a bunch of issue queues and collect anything bitesize we find. We discuss the issues with the other sprinters to get coherent point scales and then post the tasks to DROP. Can somebody make #dropsprint on IRC? Maybe this is a good opportunity to clean up your issue queue ;)

2 1

Additional hooks for SSO modules?
by David Metzler 12 Mar '08

12 Mar '08

I got this request on my issue queue for the cas module. http://drupal.org/node/232897 Given that there is a request here for support of those who maintain SSO modules, I thought I'd see if there are others on the dev list with comments? The filter hook seems reasonable to me but the user transformation service does not. Dave

1 0

Project module and extra tags
by Omar Abdel-Wahab 10 Mar '08

10 Mar '08

This might not be a major issue but I think it worths mentioning: release name in project with extra tags (DRUPAL-5--1-2-RC1) are listed all in lower case while contributions CVS allows the creation of these tags in any character case. Thus both DRUPAL-5--1-2-RC1 and DRUPAL-5--1-2-rc1 appear the same. I'd like to either have CVS restrict the creation of tags in lower case at all or have project module list them in their original case. I usually checkout code from CVS and it's painful having to visit module's page in d.o. then browse CVS (when a module has an extra tag) to see what is the original CVS tag. As I just said, this might not be a major issue but I see it as an inconsistency that may or may not get some attention. Thank you Derek once more for the new features in project module. -- Omar

2 1

reverse selection of node types is clumsy
by Dave Fletcher 10 Mar '08

10 Mar '08

Two modules I've used recently require you to make "reverse selections" of node types. They ask "select node types *not* to use" or similar. I find three issues here: 1) I have to reverse my thinking in order to make the correct selection. It takes longer. 2) I have lots of node types in my system and I normally only want to select one or a few of them in any given case. The selection is *much* bigger inversed. 3) When adding a new CCK type, it is not included in this reversed list - enabling the new type by default! It's easy to forget to disable this until someone discovers the bug of a content type where it does not belong. Cheers, --fletch

9 18

Google Summer of Code 2008 -- Your help needed
by Joshua Brauer 08 Mar '08

08 Mar '08

It's that time of year again. The Drupal project has the opportunity to participate in the Google Summer of Code (SoC). For anyone new to the SoC concept the basics are that the Drupal provides mentorship and leadership for a group of college students to apply for the program and be paid to spend their summer working on a summer open source project. In addition to the code produced the most valuable thing that comes from SoC is the opportunity to bring some great new contributors into the Drupal project. Background material on past Drupal SoC projects and the program in general can be found here: - http://drupal.org/google-summer-of-code/2007 - http://drupal.org/google-summer-of-code/2006 - http://drupal.org/googlesummerofcode2005 Although it is a "Summer" project (in the Northern Hemisphere anyway) a lot of the community effort needs to happen THIS WEEK. And for this we need YOUR help! To make the most of the SoC we need thoughtful project proposals and a dedicated group of mentors. If you'd like to sign up as a mentor visit <http://groups.drupal.org/soc-2008-mentors > and subscribe to this private group. In order to post your project ideas round up your ideas for something that would make a summer project that would advance Drupal and post it as a new discussion to <http://groups.drupal.org/soc-2008>. The other important step is to discuss the projects already posted. While it is not strictly necessary to be willing to mentor your project it is a good idea to help identify willing mentors for your project idea to be successful. In 2007 Drupal was awarded 20 slots by Google so we need lots of ideas with mentors to make as much from this year's project as possible. The pages from past years can give you several ideas of both projects from the past as well as past mentors who could be resources in deciding how you want to participate in the project. Our final ideas list needs to be completed by March 12, 2008 at noon PDT/19:00 UTC. Extremely condensed version: Go to http://groups.drupal.org/soc-2008 and lend a hand :) Thanks, Josh --------------------------- Joshua Brauer Our lives as we lead them are passed on to others, whether in physical or mental forms, tingeing all future lives together. This should be enough for one who lives for truth and service to his fellow passengers on the way. --- Luther Burbank

1 0

update_status and the new project node functionality
by Derek Wright 08 Mar '08

08 Mar '08

Now that you've all had a few days to play with the new toys, I finally pulled the lever to generate the XML files that update_status uses based on the new settings on your project nodes. So, your changes on those settings are now "live" for the purposes of update_status -- please be cautious and aware of the fact that when you deselect the "supported" checkbox on a given branch, your users will see a nice big red warning about it. After I did this, I noticed a few modules (e.g. devel and comment_upload) where giving me warnings since the officially supported versions were 5.x-0.*, but i was running a 5.x-1.x-dev (from CVS). I fixed up the settings on those two modules, so now both 5.x-0.* and 5.x-1.* are supported, but the official releases from 5.x-0.* are still recommended. However, other modules that use '0' for the major version should beware, check the node/N/edit/ releases tab on your project(s), and configure things appropriately. This is exactly the kind of edge case that the heuristics I mentioned in a previous message couldn't handle without human intervention. Cheers, -Derek (dww) p.s. For now, these XML files are only regenerated every 6 hours, so if you alter some project settings, then manually fetch data on the available updates report, you won't immediately see the changes. I'd like to see that fixed if anyone wants to help. See: http://drupal.org/node/184418

3 3

Re: [development] programmatic creation of node
by Hans Salvisberg 08 Mar '08

08 Mar '08

Not calling nodeapi/prepare before nodeapi/update will cause problems for the Subscriptions module. It needs to be able to tell whether the user has just published a previously unpublished node, and to do that it needs to know the old $node->status. I think you should call nodeapi/prepare also before nodeapi/insert, because that's what core does.

1 0

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