- Development - lists.drupal.org

node_feed vs. node_build_content vs. nodeapi alter op
by Gabor Hojtsy 20 Jan '07

20 Jan '07

Hi, I in migrating weblabor.hu from Drupal 4.6 to 5.0 and found two interesting issues in node building for rss and website view. When the website view is generated in node_view(), then node_build_content() prepares the formapi-like array structure, which calls the view nodeapi hook. There is *very similar* code in node_feed(), only except that it does not remove the  delimiter for some reason. This might be some leftover cruft, and node_build_content() should be reused there. I would submit a patch if verified. More interesting is the usage of the 'alter' nodeapi hook. It is called when a node is disaplyed on the web (from node_view()), but is not called from node_feed(), when a node is displayed in a feed. Now I can use this differenece to alter my nodes differently in web mode and rss mode (ie. I would like to have my upload related filters activate on the web, but only remove the special tags when I generate RSS). But seemingly this difference is a bug. Isn't the 'alter' nodeapi hook supposed to be used both in web mode and rss mode? Gabor

2 1

Re: [development] "Subclassing" the standard #autocomplete form
by Scott Reynolds 20 Jan '07

20 Jan '07

I may not have this quiet right but isn't this what hook_autocomplete is for? http://api.drupal.org/api/HEAD/function/user_autocomplete You can print drupal_to_js($my_array)? Mostly emailing a response because I would like to know the answer too. Date: Wed, 17 Jan 2007 17:43:10 -0800 > From: Rob Thorne <rob(a)torenware.com> > Subject: [development] "Subclassing" the standard #autocomplete form > widget > To: development(a)drupal.org > Message-ID: <45AED0AE.5060806(a)torenware.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I need a widget for Forms API which *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 > >

3 3

Re: [development] adoption for 'abandoned' modules?
by Karen Stevenson 19 Jan '07

19 Jan '07

Re the issue of co-maintainers: 1) Asking at the time a person is first applying for cvs access is way too early. What if they are just getting ready to submit a module that actually never even goes anywhere? We don't need a co-maintainer for that. We need co-maintainers much later in the process -- after a module has been out and become adopted and established and important enough that it needs some looking after. 2) One feature for the project system that would help this process along would be a way to show a link to co-maintainer(s) on the project page. Currently you see a link only to the primary maintainer. You can look at commits and try to guess who a co-maintainer might be, but you might get that completely wrong. If we had a link there: a) You would know there is a co-maintainer b) You would have an easy way to get in contact with him/her This would be useful not just to site maintainers, but to anyone who is having a problem and not getting a response from the primary maintainer. Also, I would require that anyone listed as a maintainer must have their contact form enabled, otherwise they get de-listed and their project gets put up for adoption on a special adoption page. OK, maybe that last bit is a little strong :-) but whether or not there is a way to contact the maintainer should be another factor in our 'gold star' system. Karen

9 10

adoption for 'abandoned' modules?
by Jill Elaine 19 Jan '07

19 Jan '07

Hello Coders, Jeff Eaton's post requesting permission to add himself to the CVS access list for an neglected module brings up the topic of the proper procedure for adoption of modules that have been neglected or abandoned. From this list, I gather that a user can essentially 'take over' a neglected module...or add themselves as a maintainer...by applying for a CVS account and explaining the situation. The documented procedure to update a module (fix a bug, add a feature) is "open an issue" and "submit a patch". But there is no documentation that explains what to do if good, tested patches are never applied to the module and/or the maintainer cannot be contacted. I am on the documentation list and would like to write up something that explains what to do in this situation. As maintainers of modules, what do you think this procedure should be? For instance, with your module, what would you like to see happen if you were 'run over by a truck' and disappeared from the Drupal world? ** What would be a reasonable set of steps so that your module continued to be maintained? ** What is a reasonable length of time to wait for a response from you? ** Who should be contacted if your profile is set to 'no contact'? ** What else needs to be considered here? Thank you so much for your input. jillelaine

9 12

Re: [development] Splitting hook_menu into hook_menu and hook_router
by Metzler, David 19 Jan '07

19 Jan '07

I think we'll need to think carefully about what it means to have two different menu items tied to the same path. If these are in separate parts of the menu tree, it creates some ambiguity about which parts of the menu should be expanded and which shouldn't when a particular path is gotten to. My prediction is that trying to resolve this ambiguity will lead to some pretty messy code. I agree tab coding needs cleaning up, but there are aspects of this loose coupling that actually becomes harder when you separate the concepts. If I navigate to example.com/admin/themes and that is available say as a tab, and as separate menu item, how do I know whether to display the tabbed context or not? I don't see how I can without tightly coupling the concept of path and menu navigation. So if we separate the router and the menu, I think the path needs to stay with the menu, and not with the router. Maybe a route, can appear at multiple paths? Let the route be more namespace-like: "tincymce.config"? I bet hook_menu_alter is possible without separating concepts of menu and router, given that we're presenting drupal an array of menu items. It might be more dangerouse, but it seems possible. :). Finally having multiple links to a page does not necessarily imply that you have multiple instances of the same path to the menu, it really just means that you need links to a menu item to appear in multiple places. Dave -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Karoly Negyesi Sent: Thursday, January 18, 2007 6:38 PM To: development(a)drupal.org Subject: Re: [development] Splitting hook_menu into hook_menu and hook_router > > But sometimes, something might simply logically go in two places, > > because classification isn't always as clean as we want it. This is > > why we have two views for the administration page now. By Task and > > By Module. > > Sure, but how would the router/menu separation simplify that compared > to the current system. As far as I can tell, you'd still need two > routers and two menu items. You indeed need two router items for the 'by task' and the 'by module' pages. However, what Merlin says is that these two pages prove that sometimes two links eventually pointing to the same place are meaningful and needed. The current administration menu is a mirror of the 'by task' page and there is no way to have an 'administration by module' menu because one page, one visible menu link is the current possibility. This is not merely a minor shortcoming of the old menu or even the new menu patch, both of which use path as a primary key -- router items naturally have path as primary key as you just can't have two router items for the same path and this needs to be enforced. As a side effect, we gain the possibility of an easy and trivial hook_menu_alter.

1 0

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