January 2007 - Development - lists.drupal.org

Refactor l() and url()
by Steven Wittens 21 Jan '07

21 Jan '07

I'd like to point your attention to the following patch: http://drupal.org/node/111347 :) Steven Wittens

1 0

Re: [development] adoption for 'abandoned' modules?
by Steven Peck 21 Jan '07

21 Jan '07

We do have access to the email addresses regardless of contact settings and often a private email is sent before transfer is done. > -----Original Message----- > From: development-bounces(a)drupal.org [mailto:development- > bounces(a)drupal.org] On Behalf Of Darren Oh > Sent: Saturday, January 20, 2007 9:52 PM > To: development(a)drupal.org > Subject: Re: [development] adoption for 'abandoned' modules? > > On Jan 20, 2007, at 10:31 PM, Angela Byron wrote: > > > We shouldn't be encouraging people to e-mail maintainers. We should > > be encouraging people to use issue queues, because that's where > > community development and support happens. I specifically disabled > > my contact form for this reason. I know other maintainers have as > > well. > > The point is for one person with an active interest in the module to > be able to check with developers to see why they are not responding > to the issue queue. I've been told several times to check with the > module maintainer when a module I was interested seemed to be > abandoned. Two modules have been turned over to me when I reported > that the maintainer's contact form was disabled. It would have been > nice to have been able to ask the former maintainers if they intended > to be actively involved in future development.

1 0

Re: [development] adoption for 'abandoned' modules?
by Steven Peck 21 Jan '07

21 Jan '07

> -----Original Message----- > From: development-bounces(a)drupal.org [mailto:development- > bounces(a)drupal.org] On Behalf Of Karen Stevenson > Sent: Saturday, January 20, 2007 4:12 AM > To: development(a)drupal.org > Subject: Re: [development] adoption for 'abandoned' modules? > > That comment was supposed to be a little tongue in cheek. Ah, missed that. > Yes I know some of the high profile developers have done that and I can > understand why. I think it has to be combined with other factors -- no way > to contact them directly + no response to open issues on the queue = a > developer whose modules need to get downgraded or adopted. Here we get into a perception thing again.... how would one define someone's activity to downgrade them? I myself am a burst worker. Do stuff, do other stuff, live life... go through issue queue in a rampage, repeat ;) > However I do think there is really no reason for new developers who are > not so high profile to make themselves unreachable. Personal privacy? Paranoia, anti-social :) > Anyway, I wasn't really proposing automatic action against anyone whose > contact form was disabled. > > Everyone reacted to my tongue in cheek comment and no one reacted to what > I thought was the important idea -- that we provide a place on the project > page where you can identify the co-maintainers. > > Karen Well, I can see who the other maintainers are :) and was aware of Derek's idea's on the subject and remember Dries mock up. I am sure many others do as well so it's a good reminder that not everyone tracks what was said 6 months ago vs. the decisions that were made to get the progress on the solid foundation done so that the fancy bits could actually have some hope of being accomplished. I believe that Derek replied on the issues already, I am merely commenting on the diversity of knowledge on the list.

1 0

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

21 Jan '07

That comment was supposed to be a little tongue in cheek. Yes I know some of the high profile developers have done that and I can understand why. I think it has to be combined with other factors -- no way to contact them directly + no response to open issues on the queue = a developer whose modules need to get downgraded or adopted. However I do think there is really no reason for new developers who are not so high profile to make themselves unreachable. Anyway, I wasn't really proposing automatic action against anyone whose contact form was disabled. Everyone reacted to my tongue in cheek comment and no one reacted to what I thought was the important idea -- that we provide a place on the project page where you can identify the co-maintainers. Karen ----- Original Message ---- From: Steven Peck <speck(a)blkmtn.org> To: development(a)drupal.org Sent: Friday, January 19, 2007 9:31:18 PM Subject: Re: [development] adoption for 'abandoned' modules? > -----Original Message----- > From: development-bounces(a)drupal.org [mailto:development- > bounces(a)drupal.org] On Behalf Of Darren Oh > Subject: Re: [development] adoption for 'abandoned' modules? > > On Jan 19, 2007, at 11:41 AM, Karen Stevenson wrote: > > > 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. > > Not too strong at all. If a person wants to control a project but > doesn't want to be contacted, he should maintain the project on his > own computer, not on Drupal. Let people who disable their contact > forms have CVS access, but find someone who will actually maintain a > project to be the maintainer. > Um, and those that out of frustration with people using the contact forum to mail them directly for support instead of using the issue queue? Do we disable their contrib. modules? Site admins can use the contact form. We have the email information and can email directly. Not to put a fine point on it but I know several active module contributors who have disabled their contact modules because of this sort of abuse.

4 4

Personal battle plans for Drupal 6
by Dries Buytaert 20 Jan '07

20 Jan '07

Yes, it's time to share your personal battle plans for Drupal 6! It's a bit of a tradition, and I think it's a rather fun one, so go ahead and share your personal battle plans for Drupal 6 at http:// drupal.org/node/111140. Oh, and this time, stick to the guidelines please! -- Dries Buytaert :: http://www.buytaert.net/

1 0

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