April 2009 - Development - lists.drupal.org

Re: [development] Menu Tree Access Control?
by Simon Roberts 08 May '09

08 May '09

> Date: Fri, 3 Apr 2009 00:11:51 -0400 > From: Andrew Berry <andrewberry(a)sentex.net> > Subject: Re: [development] Menu Tree Access Control? > I'm working on a site nearing completion which uses Books and > book_access for a case similar to yours, though without quite as much > granularity. We've been quite happy with book_access. If you pursue a > more fine-tuned system for permissions within a book outline, let's > get a group going and see what we can come up with, as I think it's > something my clients would be interested in. I've also been doing fine-grained book-page access, per-user and per-role, and ended up coding more than I would have liked. (Writing ACLs on the fly, and twiddling with menu-entries during theming - uugh). No idea if this is useful, but I saw this new project pop up a few days ago http://drupal.org/project/book_page_access

4 5

hook_user('categories')
by David Cohen 06 May '09

06 May '09

Sometime in the 5.x-6.x timeframe, the API for hook_user($op == 'categories') changed in a major way. No longer is the $account parameter passed in, and I think the data structure to be returned gained a lot of options. But I can't find the documentation for this. Its not in the 5.x to 6.x page on d.o (http://drupal.org/node/114774) nor is it reflected on http://api.drupal.org/api/function/hook_user/6. Can someone point me to general doc, or an example of how to emulate the following logic in D6. The logic is basically to show the user an edit category only if they have permission to change their own settings. if ($op == 'categories') { if (user_access('edit own extended permissions') && $user->uid == $account->uid) { // build the data structure } } The above logic wont apply in D6 because $account is not passed in, and the return value is expected to have new menu data structure elements which take the place of that logic. But I'm struggle to figure out, in part because I can't find the doc. thanks.

4 4

Custom module, do you think I should add it to cvs.drupal.org ?
by Pierre Rineau 03 May '09

03 May '09

Hi folks, I made a really, really simple module (3 lines and a JS file). It uses the "title" HTML attribute on text and textarea HTML inputs to display an empty value in the input, which disappear on focus, and re-appear on focus out if input is still empty. This is simple, I saw something like 10 or 20 different JS implementations; I choosed one of them, (one I saw on Drupal.org's forums), adapted it a bit the JS file to be more coherent with Drupal6. The real module just does a "drupal_add_js()" in hook_init() (which should be compatible with aggressive caching). Do you think this is a good idea to commit it in the Drupal CVS, as a new project? Or do you known some modules which already does the same thing, in a better way? Regards, Pierre.

5 8

node_delete on module specific node
by sivaji j.g 30 Apr '09

30 Apr '09

Hello folks I am a gsoc student working on quiz module. Quiz module treats quiz and its question types (multichoice, true/false etc) as a Drupal nodes. I would like to know whether i can delete a nodes specific to quiz module in hook_uninstall. My mentor and current maintainer of quiz module mbutcher is not sure about this. I have already asked this question in #drupal and came to know that core modules never deletes thier node with type story, page etc but nobody is sure about nodes specific modules. If you suggest me to leave quiz nodes untouched like core modules imagine the situation where i have some primary links to quiz nodes and quiz nodes promoted to front page they remains active even if i uninstall quiz module, how should i handle this situation ? or shall i unpublish the quiz nodes to tackle this situation ? -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/

10 11

modify permissions using hook_menu_alter()
by Lluís 29 Apr '09

29 Apr '09

I am developing a module which will allow users to post certain content-types after 30 days of being registered. I think this is achieved using hook_menu_alter(); but my code freezes drupal with a white screen. Whats is missing in my code? function wu_menu_alter(&$menu) { foreach (node_get_types('types', NULL, TRUE) as $type) { $type_url_str = str_replace('_', '-', $type->type); $menu['node/add/'.$type_url_str]['access callback'] = 'wu_role_access'; $menu['node/add/'.$type_url_str]['access arguments'] = array('create', $type->type); } } function wu_role_access($a='',$b='',$c='',$d='',$e='') { // echo "**************"; //if uncommented this is displayed return true; //when it works I will implement the rest of the function } -- *La vida és com una taronja, que esperes a exprimir-la? *Si creus que l'educació és cara, prova la ignorància. *La vida és com una moneda, la pots gastar en el que vulguis però només una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient.

7 24

Drupal development maintenance teams
by Nedjo Rogers 29 Apr '09

29 Apr '09

Karoly's recent post to this list about stagnation in the core issue queue sparked a lot of good ideas and some great short term action, including this weekend's patch review sprint (yeah participants!). I want to follow up on one of the ideas--that we should consider new structures in our patch management and in particular look at building teams responsible for different areas of development. Of all the great ideas that came up, this is the one that I find the most exciting. In lots of ways it builds on what we're already doing elsewhere. Take code sprints--these are short term development teams, working together on a particular area of development. Or else consider the security team. Formal membership, clear mandate and responsibilities, and a great track record of members stepping up and capably doing the work. What would the equivalent be for core development? Here's the idea in a nutshell. Instead of the current situation, where it's pretty much every patch for itself, we have instead a team of maintainers for each area of core (mapped to the core "component" identified in project issues). For each area, we have one or two leads--an expanded version of the "maintainers" we already have designated for different areas of Drupal core. These leads continue to be appointed by Dries. But instead of being individually responsible for an area, these leads select and lead a team of maintainers. These teams are managed a lot like the current maintainers list. Here's an idea of how it might work. Dries appoints an lead in a given area, e.g., internationalization. That lead invites individuals with proven expertise and a track record to become formal members of the internationalization maintenance team, responsible for all issues in the "multilingual support" and locale module components. Members of this team are listed on a drupal.org page along with members of the other members of the team. The basic responsibility of team members is to review, update, and refine patches in their given areas until they are closed. They can also take a step back as needed and evaluate overall progress and needs in an area, prioritizing patches to review and improve or creating new ones. Patch contributors can contact team members directly to discuss their patches and get help. A key advantage is that this approach wouldn't rely on big process or infrastructural changes. In many ways it's just a small step in the same direction we've been going. But, by enabling developers and contributors to take on formal responsibilities in patch management, it could have the potential to harness and coordinate our currently disparate efforts. Drupal development maintenance teams--an idea whose time has come? If so, what are our first steps to make it happen? Nedjo

15 21

Guidance on OS X dev setup
by Nik Derewianka 29 Apr '09

29 Apr '09

Hi all, Relatively new to drupal + php, but not to programming and would like a bit of recommendation in tools to use on OSX for drupal development. Tools - Textmate/Coda etc or more full blown eclipse, other ?? Recommended ways to debug drupal so that i can see how things work. Is CVS the only revision control system in use for drupal ? Any plans for a modern CVS/DCVS any time soon ? Slightly more specific to Services + AMFPHP (yes i will be checking out g.d.o soon): With flex the uid property on a serialised object is reserved for flex's tracking of objects so it inevitably clobbers the uid properties being returned by the various user objects in drupal. Currently the amfphp module gets around this by doing: /* * ugly! ugly! ugly! * we need to use a method call wrapper here to convert all 'uid' values in the result * to 'userid'. this is because flex uses the property 'uid' in objects and will overwrite * anything we send with its own value. */ function amfphp_method_call($method_name, $args) { // convert all userid to uid $args = amfphp_fix_uid($args, 0); $result = services_method_call($method_name, $args); // convert all uid to userid $result = amfphp_fix_uid($result); return $result; } /* * ugly! ugly! ugly! */ function amfphp_fix_uid($data, $direction = 1) { $uid = 's:3:"uid";'; $userid = 's:6:"userid";'; $from = ($direction) ? $uid : $userid; $to = (!$direction) ? $uid : $userid; $data = serialize($data); $data = str_replace($from, $to, $data); $data = unserialize($data); return $data; } Ideally, it would be better to expose a duplicate property of userid in user/node/etc classes instead of the huge refactoring task of changing uid to userid etc, but understandably this may not be the ideal solution. Can anyone recommend a possibly different approach than the one taken above ?? (And apologies if this has been already discussed elsewhere, kindly point me to it so that i can read up on it). Thanks, Nik

1 0

Very concerned over Drupal's core development
by Karoly Negyesi 29 Apr '09

29 Apr '09

Hi, I know there are many patches are written, reviewed and committed still. But, without intending to critique of anyone in particular, I see a very dangerous cycle: As Drupal 5 and 6 are very good, rock solid releases, people are satisfied and very busy there, much less is the need, the drive and the availability for core development. This means less patches are written. Also core got bigger. Very, very few people touch actions/triggers, fields, filter system, openid or for that matter, menu just to name a few. Once a patch is written , it needs a review. However, the testing bot, curiously, made patch reviews even harder -- no longer can a novice just install a patch, click around and report back "works" ( the testing bot, of course added a lot of quality to Drupal, I am not saying, down with the bot). This has very severe consequences: we always had too few reviewers and now the entry barrier is even harder as you need to do meaningful code reviews all the time. Low reviewer activity means patches do not get 'bumped' and they linger. Lingering is exacerbated by the loss of Steven and that the single guy who can call the big decisions now has a kid (soon two) and two companies to run. Of course, this leads to frustration on behalf of the patch writers and even less patches get written or reviewed and people draw back into their own little contrib empire where they call the shots... Regards Karoly Negyesi

40 101

Hook_menu_alter doesn't work if menu item changed
by Nancy Wichmann 28 Apr '09

28 Apr '09

If I do anything to a menu item, including changing its position (weight) with menu administration, then hook_menu_alter is unable to change its title. This seems to be contrary to the way the hook should work; essentially the hook is all but worthless in this case. Does anyone know why this is this way? Yes, I can update the menu_links table and change it there just fine, but then Im doing a query to change what a query should be about to do anyway. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2079 - Release Date: 4/24/2009 7:04 PM

6 21

varchar(255)
by Dave Cohen 25 Apr '09

25 Apr '09

In another recent thread (about watchdog), Frédéric suggested increasing the size of the watchdog.referer column. And he's right to suggest it because strings that are too long are not written to the database. This brings to 3 the number of columns I increase to varchar(255) on my Drupal sites. The three are watchdog.referer, users.mail, and sessions.sid. If my understanding of mysql is correct, there is no difference between a varchar(128) column filled with 128-byte strings and a varchar(255) column filled with 128-byte strings. However, there is a huge difference between a varchar(128) column filled with 129-byte strings and a varchar(255) filled with 129-byte strings. (The latter will work). So please, when developing for Drupal and wondering what size to make that varchar... stop wondering and use varchar(255). Or if you need it even longer varchar(65535). Note that lengths up to 255 can be represented in one byte, and 65535 in two bytes. Oh and please do correct me if I'm wrong about any of this, -Dave

3 2