January 2007 - Development - lists.drupal.org

Splitting hook_menu into hook_menu and hook_router
by Karoly Negyesi 19 Jan '07

19 Jan '07

Hi, We discussed renaming hook_menu and hook_router was a popular choice but as Gerhard says "I don't like to rename funtions just for the sake of renaming them" so it remained hook_menu . However, looking at my brain dump at http://drupal4hu.com/node/28 tells me that further down the road a split is needed. hook_router has these things: -- path as primary key. We use this as an array key, so an alter hook can easily be provided. -- access callback and arguments -- page callback and arguments -- map callback and arguments hook_menu has these: -- path. This is not unique. It's often requested that one path could have more than one visible link. -- parent. If you omit this, it can be autogenerated but for setting it to some arbitrary value, let's say MENU_ROOT can be used to indicate a new menu. With this (or via other means if someone has a better idea) we can put links into any menu. -- title. -- weight. -- expanded. With path being unique in one and not unique in the other, I fail to see how the two could be unified. And I fail to see the point as well. We could lose path being an array key and make it a property again in hook_router as it was in old hook_menu but then what shall happen if someone defines two router items to the same path? This is a mess. The above is nice and clean. Regards NK

8 31

convert all DRUPAL-4-7 *tags* into *branches* at once?
by Derek Wright 19 Jan '07

19 Jan '07

this is about the infamous "sticky tag is not a branch" error described here: http://drupal.org/node/57516 our contrib repository is littered with "DRUPAL-4-7" tags that should really be branches. back in the dark ages before the new release system, it didn't matter that much, and our CVS repository access control scripts didn't care. now it matters a great deal, and the scripts enforce that all new branches and tags fit our naming convention and do what they should (i.e. "DRUPAL-5" must be a branch, and "DRUPAL-5--1-0" must be a tag)... however, there's still a bunch of older tags that should be converted. about a month ago, there were 75 DRUPAL-4-7 tags that should be branches. a few of them already have support issues waiting. it's a pain in the ass for the CVS admins (me), and it's a pain in the ass for the end developers (some of you). in http://drupal.org/node/103429 i propose to just write a script to do this conversion all at once, so that developers don't have to stumble into this problem on their own, and i don't have to do any more manual effort to help correct things on a case-by-case basis. does anyone object to this proposal? if so, please follow-up here and say so: http://drupal.org/project/comments/add/103429 otherwise, i might try and get to this sometime early next week, since the manual support load this problem is generating is driving me nuts, and slowing me down from doing Real Work(tm). cheers, -derek

2 1

"Subclassing" the standard #autocomplete form widget
by Rob Thorne 18 Jan '07

18 Jan '07

I need a widget for Forms API which is *almost* identical to the textfield autocomplete widget in 5.0. I want the same user experience -- the user types and chooses an item. But I want the underlying AJAX and Drupal behavior to differ a bit. An example of the type of widget I'd want would be a "Country Selection" widget where what I really want is the two-character country code (US, CA, GB, FR, and so on), but I want the user to think of typing "United States", "Canada", "Great Britain", "France" or so on in order to get the popup to get set on this code. Looking through the 5.0 sources, the way the current autocompletion widget works is via includes/form.inc, where the theming function theme_textfield($element) special cases textfields with the '#autocompletion_path' , by making sure that autocomplete.js gets added to the page going out, and by adding a hidden <item> to store state information that the code in autocomplete.js needs to do its work. I really don't need to change behavior very much; I just need to send back an array of array(key, value), where the standard widget sends back an array of string values. But pretty much everything else that Unconed's code does exactly what I want, and while I can copy if if that's easiest, I don't want or need to change what he did. What's the best way to create my modified Forms API widget? It looks like I'd want to "override" or "subclass" theme_textfield, although only to add behavior: I don't want standard autocomplete widgets to behave any different than usual (although I'd not want both sets of code to compete on the same widget). I'd then copy autocomplete.js and make very small changes in it, changing function names where required. Is there a better way to do this? Or even better, has someone else already done this? Thanks, Rob Rob Thorne Torenware Networks

5 7

menu patch
by Dries Buytaert 18 Jan '07

18 Jan '07

Hello world, could we have a look at the menu patch chx has been working on: Patch: http://drupal.org/node/34755 Documentation: http://drupal.org/node/102338 Please, give this a close look. It's a central piece of Drupal, and it is important that we make it as easy to use as possible. At the same time, it should be very flexible, so what I'm really asking for is that you look at this patch with your engineering glasses on. Do you find the APIs intuitive? How does this compare with other systems? Suggestions as how this can be simplified? Is it easier to explain than the current system? Please give this patch your best look, so we can move this forward. Thanks. -- Dries Buytaert :: http://www.buytaert.net/

1 0

Move update modules to api.drupal.org
by Karoly Negyesi 18 Jan '07

18 Jan '07

Hi, Let me sum up a few important mails to the curiously named thread " Core: DRUPAL-5 branched " and let me add my thoughts. Neil said that he would like paths like http://api.drupal.org/api/function/hook_menu/6.x so that we can have tabs per version. Then came the question (Derek, I tink) -- what should reside on http://api.drupal.org/api/function/hook_menu? Earnie Boyd followed up to this: upgrade instructions. He thinks it's a lot of work. But it's not -- we already write these for the handbook. It might be some work restructure the 4.7 -> 5 instructions into this but the 5 -> 6 already can be written into a new structure. What remains is deciding this structure. I suggest using another .php let's say update.php besides hook.php and friends and free-form Doxygen describing the transition where necessary for each hook. So the 4.7 -> 5 restructure will become a matter of copy-paste. Regards NK

2 1

Core: DRUPAL-5 branched
by Dries Buytaert 18 Jan '07

18 Jan '07

Hello world, just to let you know that we branched Drupal core. There is now a DRUPAL-5 branch that will be maintained by Neil Drumm, with help from Steven and me. (http://buytaert.net/neil-drumm) This also means that CVS HEAD is open for development again, and that - after a long code freeze - we can finally start working on Drupal 6. Yay! (I'm going to create a new thread to discuss Drupal 6 later this week.) I haven't assigned a Drupal 6 core maintainer yet. A new core maintainer is not a requirement, but I'll probably assign one in a couple of weeks, once we're a little bit further down the road. Rock on, -- Dries Buytaert :: http://www.buytaert.net/

15 19

Improve multiple database handling
by Rowan Kerr 18 Jan '07

18 Jan '07

Reference this issue, although I did not create the issue: http://drupal.org/node/87074 Greetings all :) Nice work on Version 5! I recently had to make a Drupal 4.6 site connect to a MySQL and a PostgreSQL database at the same time. Of course, this isn't possible with the current implementation of database*.inc since the same functions are redefined in each inc file. I'd like to update my patch for HEAD and hopefully get this feature accepted for the next release. What I actually implemented was two separate features that can be split into different patches for consideration. 1. Allow connections to multiple different types of database servers. 2. Allow different table prefixes for each database connection. Hopefully others think this is a useful feature? :) Again, the issue I'm referring to on Drupal.org is http://drupal.org/node/87074 Thanks, -Rowan

3 4

theme.inc patch
by Earnie Boyd 17 Jan '07

17 Jan '07

Please review the details I have submitted to http://drupal.org/node/110266. The issue I'm fixing is too many reads of settings.php. Earnie

1 0

Need Owner Change on Invite Module
by Nick Wilson 16 Jan '07

16 Jan '07

Hi everyone, I took over the development of the invite module a while back because I needed to work on it and it seemed abandoned. Unfortuately I no longer have time to even answer the issues let alone code for them so the module really needs a new owner. If none come forward, I would appreciate the nodes ownership being changed anyway. Many thanks, and apologies that I cannot help further on this module! -- Nick Wilson Bio/Blog: http://communicontent.com/user/nick-wilson LinkedIn: http://www.linkedin.com/in/nickwilson

2 2

Styling comment blocks according to vote results
by Ben Campbell 16 Jan '07

16 Jan '07

Hi there - I'm working on a system to change the appearance of comments based on how people rate them. So highly rated comments would appear bigger and brighter than badly-rated comments. The voting API abstracts away the rating mechanism nicely (so in theory you could pick any voting module to drive the ratings system). But I'm not 100% sure of the best way to apply different looks to differently rated comments. My current thinking is that it'll have to be pretty tied to a theme - I'd pass some sort of rating metric into comment.tpl.php as an extra parameter and the template applies an appropriate style (probably one of a range of styles defined in a stylesheet). Does this sound like a sane way to do it? Does anyone have any suggestions of approaches I could take to generalise it a little? It'd be nice to decouple it from the theming as much as possible so others can take advantage of it. Thanks! Ben.

3 2