October 2008 - Development - lists.drupal.org

Views 1.x issues need testing
by Daniel F. Kudwien 30 Oct '08

30 Oct '08

I am working on getting a (hopefully final) Views 1.7 release out of the door. If you have one or more existing Drupal 5 sites using Views 1.x - preferably backups/development sites of live sites, and most preferably with highly customized Views stuff - it is most probably in your own interest to help in reviewing and testing the patches listed in http://drupal.org/node/208855#comment-1018848 If your sites make use of Taxonomy in Views, exposed filters, RSS feeds, multiple views arguments - even better. Participating is simple: Just click on 2-10 different issues on that list, download and apply the latest patch in the issue, and report back if the views on your site still work - ideally also including whether the goal of the issue has been achieved, of course. Each patch needs 2-3 confirmations to be RTBC. Some issues will require updates to the upgrade path for Views 2.x; that will be dealt with after 1.7 has been released. Thanks, Daniel

1 0

Making #access required on forms
by Angela Byron 27 Oct '08

27 Oct '08

Gerhard brought this up on the security team list, but it seems like it's worth broader discussion: --- Hi there, as more an more people use Drupal to provide non-traditional Webpages (e.g. providing services using Ajax, Flex, ...) our traditional access permission checks in hook_menu are less than ideal. For example, you can use drupal_execute to conveniently create content or anything else. However, no check for access permissions is done since this only happens in the menu hook for node/add/whatever. I therefore propose to push for D7 that the #access parameter on forms be made mandatory. Opinions? --- My initial thought on the downside is that this has implications for people who are using drupal_execute() to perform programmatic tasks (node/block/etc. creation, etc.); they would no longer work unless the script switched to user with the proper credentials (so we should probably get a nice user switching API function in core). It is also something in the upgrade steps that, if missed, will cause forms to completely disappear which is bound to result in support requests. On the other hand, it would provide extra security and would be akin to the way we force menu callbacks to provide an access control or they don't appear for anyone. It might also help us clean up some nasty places in core (node form, I am looking at you) where we have if (user_access(...)) hard-coded. So, I echo: opinions? :) -Angie

17 20

Re: [development] Has anything changed with module_invoke() recently?
by Ron Parker 25 Oct '08

25 Oct '08

Ron Parker said: "This same exact code worked in 5.x, so I have to believe there is something that has changed in 6.x with module_invoke() / $user . Furthermore, this code worked in the initial Drupal 6.x versions, so this change, whatever it is, is rather recent. Theoretically, module_invoke below should not return false, but it is" Nancy Wichmann said: "I have recently run into problems with hook_access. It is widely misunderstood and many module return false when they really should be returning null. I even had to change many of my modules. I know there are many out there that are still wrong." Could someone please point me to how I begin to solve this problem? I am certain that the user object contains the correct roles that should allow permission. How do I track down what's going on with module_invoke? -ron

1 1

Drupal Test Suites
by Steven Surowiec 24 Oct '08

24 Oct '08

I've been working on several Drupal projects for work and am thinking of getting an install of PHPUnderControl (http://www.phpundercontrol.org) and was wondering if there's any tests for Drupal core that are publicly available I'd be able to drop into the test suite. If not I think this would be something worth putting some time into, even as a regular project on the site. Since all the modules we write depend, in some way, on the core code, being able to include a generic core test suite in with our own would probably prove to be pretty useful. Especially for those of us that find ourselves needing to occasionally dig into core code now and then.

3 3

Has anything changed with module_invoke() recently?
by Ron Parker 24 Oct '08

24 Oct '08

Regarding Drupal 6.x. Running core Drupal with og, og_user_roles and tac_lite. I am dynamically creating roles and adding them to the $user object in hook_boot and hook_user('load') (and several other places). The $user object contains the roles that the user needs to create content for the node $type in the example below (I have verified that). Theoretically, module_invoke below should not return false, but it is: <?php global $user ; // $user object contains correct roles for access // Got this from node.module (node_access) // No matter the type, this should return us the create permission. $module = node_get_types ( 'module' , $type ); if ( $module == 'node' ) { $module = 'node_content' ; // Avoid function name collisions. } // I checked $user->roles before this is called $access = module_invoke ( $module , 'access' , 'create' , $type , $user ); // and, afterwards. They are exactly what they should be to allow this // this user access to this content ... ?> $access is FALSE. What happens in module_invoke where it would override the roles in the $user object? This same exact code worked in 5.x, so I have to believe there is something that has changed in 6.x with module_invoke() / $user . Furthermore, this code worked in the initial Drupal 6.x versions, so this change, whatever it is, is rather recent. Any ideas, whatsoever? Thanks! -ron

2 1

Unsetting form values on validate
by Michael Prasuhn 21 Oct '08

21 Oct '08

I am building a directory listing type site and trying to keep all my listings in one node type. There are different options for the types of listings available, and I am using some javascript to show/hide forms on the node/add page. I am also doing quite a bit of validation from hook_nodeapi, of individual field formatting, and so on. One of the things I'd like to be able to do, is upon validation of the node, throw out any form values that do not match the type of listing they have chosen (so that the values won't be shown on the node preview, for example). What is the best way to go about this? I see that in my hook_nodeapi under the validate op, I am getting the node, and the $form itself, not $form_state or $form_values. The submitted data that I wish to discard is in both the $node object, and the $form array under #post among other places. Drupal 6.x btw. -Mike __________________ Michael Prasuhn mike(a)mikeyp.net http://mikeyp.net

6 6

(no subject)
by Kevin Davis 21 Oct '08

21 Oct '08

Hello, I would like to know how to pass variables or information between on form in drupal to another form in drupal. Kevin

1 0

Modules free to good home
by Addison Berry 21 Oct '08

21 Oct '08

I don't have many modules under my care but now that I consider the docs queue my responsibility, I've enough queue work to keep me busy. :-) I'd like to find good caretakers for a few of my modules to lighten the load a bit. If you are interested in either being a co- maintainer or taking over maintenance altogether, please let me know off list (email or contact page http://drupal.org/user/65088/contact) I'm willing to sit in and help answer questions and guide if there are folks that feel like they want to dip into maintaining but still aren't confident - so a good opportunity to get your feet wet, if you are so inclined. I just can't carry the load of development and regular queue maintenance anymore. Modules that need good kibble and a warm, safe bed at night: Nice menus: http://drupal.org/project/nice_menus Prepopulate: http://drupal.org/project/prepopulate Comment Mail: http://drupal.org/project/commentmail - Addi (add1sun) -------------------------------------- Join us at Do It With Drupal! A large scale, curated education event December 10-12, New Orleans http://www.doitwithdrupal.com

1 0

session questions
by Dave Cohen 20 Oct '08

20 Oct '08

Hi, I'm hoping someone understands sessions better than I do and can help me out. I'm noticing different behavior across browsers and I'm having trouble groking it. I'm serving a page with a form, and that form has an autocomplete field. So my drupal gets an initial request for the page, then subsequent requests for the autocomplete callback. I'm testing with Firefox and IE right now, and here's what I observe.... 1) Across all browsers and requests, the session_name() is the same. I believe this is because drupal computes a session name in conf_init(). The name depends on the URL only and not the browser. Am I correct so far? 2) From Firefox, the initial page request and subsequent autocomplete callbacks have the same session_name AND session_id. In other words the session cookie's name and value remain the same. The effect of this is that $_SESSION is shared between the normal page request and the ajax requests. 3) From IE7, the session_name remains the same across all requests, but the session_id() of the initial page request is different from the ajax callbacks. In other words the session cookie's value changes. So $_SESSION is not shared. Is this what I should be seeing? 4) Also from IE7, the session_id is new for ajax callbacks, yet drupal somehow knows which user is logged in. That is $_SESSION is not shared with the original page request, but the global $user is set correctly. How is this happening? Doesn't Drupal rely on the session_id to determine the user? Since session_id has changed shouldn't drupal think the ajax request is anonymous? Is what I'm seeing the way things are supposed to be, or have I somehow screwed up my install? Thanks, -Dave

3 3

Josh Koenig to take up the slack with the Salesforce module
by Victor Kane 17 Oct '08

17 Oct '08

I first published the Salesforce module based on Steve McKenzie's Sandbox code due to the fact that I had a client (helpargentina.org) who needed integration with Salesforce, and naturally I thought the quality and maintainability of the software would be much better served by an open project that interested members of the community participated in. That was true then and it is true now, when it is Josh Koenig who is working on a project and has a great store of ideas and needs with which to update and stabilize the module and make it more flexible and powerful. Since due to other commitments I have been unable to give much love at all to this module in quite some time, there is no doubt in my mind that the best thing for the community and all concerned is for Josh to dive right into direct maintenance of the module, to which he has now been granted CVS access. I am sure Josh will be announcing his Road Map soon. Others have contributed a lot also, bringing to the discussion a lot of useful ideas and code, in connection with this module which is so hard to abstract from project-specific needs, notably Benjamin Melançon and Tom Friedhof. Go Drupal! Victor Kane http://awebfactory.com.ar

4 4