Re: [development] Has anything changed with module_invoke() recently?
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
I located the source of my problem. In the user_access() function, the static variable $perm is set to hold the permissions for a user. Issuing this command: user_access('', NULL, TRUE); ( http://api.drupal.org/api/function/user_access/6 ) will unset the $perm variable and allow it to reset with the permissions from the most current roles. My debug code indicates that it contains the correct permissions from the roles of the $user object. However, when I issue: module_invoke($module, 'access', 'create', $type, $user); which, in the case of $module = 'node_content' will itself call user_access($permission, $user) , the $perm value is now set (as it should be from my reset command), but no longer contains the all permissions from the roles in the $user object (what was originally set), but only the ones you would find for the user in the role table. Furthermore, I put debug code into user_access() to show me each time it is ran. I do not see it accessed between the time $perm is unset (by my reset command) and it is called by module_invoke(). The way this worked in 5.x: hook_init() would issue user_access('', NULL, TRUE) which would unset the $perm variable so that the next time user_access() ran, it would rebuild $perm. In 6.x appears this no longer works in the same way. So, it looks like either: a. Another module (other than the user.module) is manipulating the $perm variable, or; b. Drupal core is assuring, when module_invoke() is used, that the set $perm variable only contains roles that the user has in the roles table. My question is this: Can the $perm variable be manipulated outside of the user.module? If not, then how is b. above accomplished? Thanks for any assistance whatsoever! -ron ----- Original Message ----- From: "Ron Parker" <sysop@scbbs.com> To: development@drupal.org Sent: Friday, October 24, 2008 12:03:05 PM GMT -08:00 US/Canada Pacific Subject: Re: Has anything changed with module_invoke() recently? 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
participants (1)
-
Ron Parker