- Development - lists.drupal.org

Re: [development] The static $perm variable in user_access reset erroneously
by Ron Parker 06 Nov '08

06 Nov '08

Damien Tournoud wrote: "This is nothing more than a bug. Please see http://drupal.org/node/329646 ." Yes, that's it. Applied the patch and getting expected behaviour now. Thank you! -ron

2 1

Place, Geotagging
by Steven Clift 04 Nov '08

04 Nov '08

I am interested in your Drupal developer take on two related ideas: 1. Place - Many of the sites hosted on Drupal are local organizations with local content. What do you think of having a standard way Drupal (and other open source CMSes) allow sites to assign the geographic place name (or perhaps a point) that best represents either where their organization is based? How about an automatic map of Drupal sites or listings by hierarchical placename? Perhaps a connection to http://gaze.mysociety.org would work. 2. GeoTagging - What do you think of defaulting or at least having the ability to assign a point, bounded place, or "global" geo-tag in terms of the general scope of individual content items created? An option changeable near a save/post button. It seems to me that as long as geotagging is an afterthought, the ability to aggregate/navigate much of the newer and dynamic content on Drupal hosted sites by geographic relevancy will be quite limited. Imagine the power of just a few CMSes adopting a similar way to describe the place of sites (which could be "earth" for those who think the Internet is best when viewed as narrowly "global") and even more granular meta-data on specific content items as a default rather than an add-on. Please also reply to: clift(a)publicus.net Steven Clift http://stevenclift.com P.S. I am gathering feedback on this idea as part of an exploration commissioned by a major U.S. foundation.

2 1

drupal.org scheduled maintenance
by Chad Phillips -- Apartment Lines 04 Nov '08

04 Nov '08

following discussions with killes, i've scheduled a brief maintenance window for drupal.org. Details here: http://drupal.org/node/329973

1 0

Re: [development] The static $perm variable in user_access reset erroneously
by Ron Parker 03 Nov '08

03 Nov '08

David Metzler wrote: "I downloaded and looked at the code for user_access and I have one idea. I've had some problem intializing static structures to arrays or objects in certain versions of php. Try changing the definition of $perm as follows: static $perm = ''; if (!$perm) $perm = array(); See if that changes the caching behavior in your php rev." "Another minor point regarding this debug, Since you're not dumping all of the $perm variable, we don't really know that the user_id is the same. What if the user_id was being checked? (we know which was being modified) Would recommend debugging print_r($account,1) and print_r($perm,1) after the reset line. " I've added a var_export command to dump the values from both $account and $var . I'm also using the $perm definition suggested above. This is the initial call to user_access to flush the $perm variable: • ogur | module to call = node_content | type = story • ogur | Preparing to call module_invoke • ogur | Calling user_access('ClearCache', NULL, TRUE) • user_access | string = ClearCache • user_access | static $perm is NOT already set • user_access | $perm set for uid 3 (test01) • user_access | string = ClearCache | $perm values = 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4 • user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • user_access | permissions returned (end of function): (access comments,access content,view uploaded files,view advanced help index,view advanced help popup,view advanced help topic,post comments,post comments without approval,search content,use advanced search,subscribe to newsletters,view links in block,create page content,create story content,delete own page content,delete own story content,edit own page content,edit own story content,upload files,configure member roles,access devel information,display source code,execute php code,switch users,view devel_node_access information) • user_access | $account : class stdClass { var $uid = '3'; var $name = 'test01'; var $pass = ''; var $mail = ''; var $mode = '0'; var $sort = '0'; var $threshold = '0'; var $theme = ''; var $signature = ''; var $created = '1214004001'; var $access = '1225742808'; var $login = '1225218681'; var $status = '1'; var $timezone = NULL; var $language = ''; var $picture = ''; var $init = 'test01(a)scbbs.com'; var $data = 'a:3:{s:13:"form_build_id";s:37:"form-828fb54ceb43bf0d467b9dcc20cebfd7";s:21:"og_user_roles_regcode";s:0:"";s:8:"og_email";s:1:"1";}'; var $timezone_id = '0'; var $form_build_id = 'form-828fb54ceb43bf0d467b9dcc20cebfd7'; var $og_user_roles_regcode = ''; var $og_email = '1'; var $roles = array ( 2 => 'authenticated user', 8 => 'Devel', 3 => 'Group Member', 4 => 'Group Contributor', 7 => 'Group Admin', ); var $og_groups = array ( 24 => array ( 'title' => 'USADance LA', 'type' => 'group', 'status' => '1', 'nid' => '24', 'og_role' => '0', 'is_active' => '1', 'is_admin' => '0', 'uid' => '3', 'mail_type' => NULL, 'created' => '1225139825', 'changed' => '1225139825', ), ); } • user_access | $perm : array ( 3 => array ( 'access comments' => 0, 'access content' => 1, 'view uploaded files' => 2, 'view advanced help index' => 0, 'view advanced help popup' => 1, 'view advanced help topic' => 2, 'post comments' => 4, 'post comments without approval' => 5, 'search content' => 7, 'use advanced search' => 8, 'subscribe to newsletters' => 9, 'view links in block' => 10, 'create page content' => 4, 'create story content' => 5, 'delete own page content' => 6, 'delete own story content' => 7, 'edit own page content' => 8, 'edit own story content' => 9, 'upload files' => 10, 'configure member roles' => 0, 'access devel information' => 0, 'display source code' => 1, 'execute php code' => 2, 'switch users' => 3, 'view devel_node_access information' => 4, ), ) This is the next call to user_access should contain the values of $perm from above, but don't. • ogur | Calling module_invoke('node_content', 'access', 'create', 'story', $user) • node_content_access | type = story | op = create • node_content_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • user_access | string = create story content • user_access | static $perm is already set • user_access | string = create story content | $perm values = 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4 • user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • user_access | permissions returned (end of function): (view advanced help index,view advanced help popup,view advanced help topic,access comments,post comments,post comments without approval,access content,search content,use advanced search,subscribe to newsletters,view links in block,access devel information,display source code,execute php code,switch users,view devel_node_access information) • user_access | $account : class stdClass { var $uid = '3'; var $name = 'test01'; var $pass = ''; var $mail = ''; var $mode = '0'; var $sort = '0'; var $threshold = '0'; var $theme = ''; var $signature = ''; var $created = '1214004001'; var $access = '1225742808'; var $login = '1225218681'; var $status = '1'; var $timezone = NULL; var $language = ''; var $picture = ''; var $init = 'test01(a)scbbs.com'; var $data = 'a:3:{s:13:"form_build_id";s:37:"form-828fb54ceb43bf0d467b9dcc20cebfd7";s:21:"og_user_roles_regcode";s:0:"";s:8:"og_email";s:1:"1";}'; var $timezone_id = '0'; var $form_build_id = 'form-828fb54ceb43bf0d467b9dcc20cebfd7'; var $og_user_roles_regcode = ''; var $og_email = '1'; var $roles = array ( 2 => 'authenticated user', 8 => 'Devel', 3 => 'Group Member', 4 => 'Group Contributor', 7 => 'Group Admin', ); var $og_groups = array ( 24 => array ( 'title' => 'USADance LA', 'type' => 'group', 'status' => '1', 'nid' => '24', 'og_role' => '0', 'is_active' => '1', 'is_admin' => '0', 'uid' => '3', 'mail_type' => NULL, 'created' => '1225139825', 'changed' => '1225139825', ), ); } • user_access | $perm : array ( 3 => array ( 'view advanced help index' => 0, 'view advanced help popup' => 1, 'view advanced help topic' => 2, 'access comments' => 3, 'post comments' => 4, 'post comments without approval' => 5, 'access content' => 6, 'search content' => 7, 'use advanced search' => 8, 'subscribe to newsletters' => 9, 'view links in block' => 10, 'access devel information' => 0, 'display source code' => 1, 'execute php code' => 2, 'switch users' => 3, 'view devel_node_access information' => 4, ), ) • ogur | module_invoke called • ogur | ognodeadd roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • ogur | module_invoke access returns false Again, this problem only occurs, so far, when I have one of these modules installed along with OGUR: tac_lite, taxonomy_access, menu_breadcrumb and admin_menu . Other modules with which I'm told this problem occurs: • Content Permissions • Localization client I've searched the code of these modules for some indication of their modifying the $perm variable, but can find none. I do really appreciate the help. This is driving me nuts! I can find no logical explanation for this modification, thus I'm unable to figure out a way around it. -ron

2 1

CVS-Messages
by Eric-Alexander Schaefer 03 Nov '08

03 Nov '08

Hi List, wasn't there a book page about how a cvs message is supposed to look like? Regards, Eric

2 2

module upgrade
by Eric-Alexander Schaefer 03 Nov '08

03 Nov '08

Hi List, for some reason the scheduler.module recorded the time for publish and unpublish in local time of the user with an additional timezone column for translation to utc or whatever. Some time ago I changed it, so that it would store the times in utc and removed the timezone column. This was done for both 5.x and 6.x. Now when upgrading from a current 5.x release to 6.x scheduler_update_6100() gets called and tries to adjust already stored times by their respective timezone values and then removes the timezone column. function scheduler_update_6100() { $ret[] = update_sql("UPDATE {scheduler} SET publish_on=publish_on-timezone WHERE publish_on<>0"); $ret[] = update_sql("UPDATE {scheduler} SET unpublish_on=unpublish_on-timezone WHERE unpublish_on<>0"); $ret[] = update_sql("ALTER TABLE {scheduler} DROP COLUMN timezone"); return $ret; } Since the timezone column does not exists in current 5.x releases the update fails. To avoid it I would check for the existence of the timezone column. But: How? Regards, Eric

2 2

Re: [development] Error running SimpleTest on new installation
by Dave Reid 03 Nov '08

03 Nov '08

That SimpleTest error happens when the first test fails. Since the test didn't complete, it's test_id does not get saved. If more than one tests pass, a valid test_id is saved. I have an issue report for this bug at http://drupal.org/node/325824*. * Dave* * > That particular error is usually caused by a bug in one of the unit tests you ran causing simpletest to hiccup. I've seen it a couple of times, and it's sometimes sporadic, unfortunately. It could be a bug in simpletest itself. I've not ruled that out yet. > > See if you can narrow it down to a single test that's causing the problem. If you can establish a pattern (a particular test, more than X tests, some particular phase of the moon, etc.) then file a bug report for the appropriate module (which could be simpletest itself). If you need more help narrowing it down, stop by #Drupal on IRC. Simpletest is high in the mind of most core devs of late, so there's a good chance you'll find someone who can give you more detailed help tracking down the problem. > > Thank you for helping make Drupal better! > > --Larry Garfield > > On Thu, 30 Oct 2008 13:16:11 -0400, "Sookocheff, Kevin" <Kevin.Sookocheff(a)cbsa-asfc.gc.ca> wrote: > >> Hello, >> >> I had checked out a fresh version of Drupal from CVS this morning and >> each time I run some SimpleTest test cases I receive the following >> error: >> >> Undefined index: test_id in _simpletest_batch_finished() (line 423 of >> E:\xampp\htdocs\drupal_test\modules\simpletest\simpletest.module). >> >> I am new to Drupal development and want to get started by writing some >> tests and reviewing patches. Does anyone have an idea about fixing the >> above problem so that I can get started? >> >> Thanks, >> Kevin

2 1

Re: [development] The static $perm variable in user_access reset erroneously
by Ron Parker 01 Nov '08

01 Nov '08

On Fri , Oct 31, 2008 at 12:27 AM, David Metzler < metzlerd(a)metzlerd.com >wrote: > It sounds like you're suggesting that $perm, a static variable within > user_access() is being modified without user_access being called, but within > a single page load. That doesn't seem possible in PHP, unless there is a > PHP bug. Static variables are supposed to be local in scope to the > functions that create them. To prove beyond a shadow of doubt, put a $debug > statement in at the very beginning of the function user_access and another > at the very end of the function. (just before the return). If what you're This is exactly what I'm suggesting. I put debug statements in user_access, node_content_access, and my OGUR function so that I would see every time they were accessed, and what was in them. To briefly summarize, I have a role "GroupAdmin" which is dynamically added to the $user object. It contains the "create story content" permission. I issue the command to clear the $perm cache: user_access('ClearCache', NULL, TRUE) This is followed by a module_invoke command (which, in turn will again call user_access): module_invoke('node_content', 'access', 'create', 'story', $user) The problem is that the $perm variable in the second user_access call should contain the values from the first user_access call, and it doesn't. It is still set, as it should be, but the variables are different. Here are the results of my debugging: I noticed that even when my hook_init() clears the $perm variable: • user_access('', NULL, TRUE) • ogur roles loaded into user object (hook_init) • user_access | string = • user_access | static $perm is NOT already set • user_access | $perm set for uid 3 (test01) • user_access | string = | $perm values = 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4 • user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • user_access | permissions returned: (access comments,access content,view uploaded files,view advanced help index,view advanced help popup,view advanced help topic,post comments,post comments without approval,search content,use advanced search,subscribe to newsletters,view links in block,create page content,create story content,delete own page content,delete own story content,edit own page content,edit own story content,upload files,configure member roles,access devel information,display source code,execute php code,switch users,view devel_node_access information) The very next call to user_access does NOT contain the correct permissions: • user_access('access content') • user_access | string = access content | $perm values = 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4 ( note that all the permmissions from above are NOT here - the only ones missing are those granted by the dynamically assigned roles ) • user_access | static $perm is already set • user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • user_access | permissions returned: (view advanced help index,view advanced help popup,view advanced help topic,access comments,post comments,post comments without approval,access content,search content,use advanced search,subscribe to newsletters,view links in block,access devel information,display source code,execute php code,switch users,view devel_node_access information) Another test: This is the page loaded: http://mysite.com/node/ognodeadd?type=story&gids[]=24 User should be able to create story. This is what debug returns: • ogur roles loaded into user object (ognodeadd) • ogur | ognodeadd roles returned: (authenticated user,Devel,Group Member,Group Contributor, Group Admin ) These are the correct roles for this user in this group. • ogur | module to call = node_content | type = story • ogur | Preparing to call module_invoke • ogur | Calling user_access('ClearCache', NULL, TRUE) • user_access | string = ClearCache • user_access | static $perm is NOT already set • user_access | $perm set for uid 3 (test01) • user_access | string = ClearCache | $perm values = 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4 • user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) This is correct. • user_access | permissions returned: (access comments,access content,view uploaded files,view advanced help index,view advanced help popup,view advanced help topic,post comments,post comments without approval,search content,use advanced search,subscribe to newsletters,view links in block, create page content,create story content,delete own page content,delete own story content,edit own page content,edit own story content,upload files ,configure member roles,access devel information,display source code,execute php code,switch users,view devel_node_access information) The above are the permissions that $perm should have the next time user_access is ran. It will run again when module_invoke() is called. Below is what comes back the very next time user_access is called. • ogur | Calling module_invoke('node_content', 'access', 'create', 'story', $user) • node_content_access | type = story | op = create • node_content_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • user_access | string = create story content | $perm values = 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4 • user_access | static $perm is already set • user_access | roles returned: (authenticated user,Devel,Group Member,Group Contributor, Group Admin ) This is correct. • user_access | permissions returned: (view advanced help index,view advanced help popup,view advanced help topic,access comments,post comments,post comments without approval,access content,search content,use advanced search,subscribe to newsletters,view links in block,access devel information,display source code,execute php code,switch users,view devel_node_access information) Note that the "Group Admin" role permissions are not included here. They should be the same as from from the ClearCache user_access command above. It appears that the above permissions have been cached somewhere else. • ogur | module_invoke called • ogur | ognodeadd roles returned: (authenticated user,Devel,Group Member,Group Contributor,Group Admin) • ogur | module_invoke access returns false Access should be true here. Installed devel module. There are four user_access SQL queries that appear on this page: 1.16 1 user_access SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN (2,8) 0.77 3 user_access SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7) 0.76 3 user_access SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7) 0.72 3 user_access SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)

3 3

Error running SimpleTest on new installation
by Sookocheff, Kevin 31 Oct '08

31 Oct '08

Hello, I had checked out a fresh version of Drupal from CVS this morning and each time I run some SimpleTest test cases I receive the following error: Undefined index: test_id in _simpletest_batch_finished() (line 423 of E:\xampp\htdocs\drupal_test\modules\simpletest\simpletest.module). I am new to Drupal development and want to get started by writing some tests and reviewing patches. Does anyone have an idea about fixing the above problem so that I can get started? Thanks, Kevin

2 2

Re: [development] The static $perm variable in user_access
by Ron Parker 31 Oct '08

31 Oct '08

The static $perm variable in user_access() contains the permissions that users have. When user_access('ClearCache', NULL, TRUE) is executed, the static $perm value is emptied and re-filled with permissions from the current roles in the $user object . Theorectically, when user_access() is next called, assuming the $ user object contains the same roles, the $perm variable should contain the same permissions which were cached in the first call. This is what happened in Drupal 5.x and the earlier versions of 6.x. This is NOT happening (at least consistently) in the most recent versions of the user.module . I've written a bunch of debug code in the user, node and ogur modules and now have more details. I am printing the output of user_access () every time it is called. When I issue: user_access('ClearCache', NULL, TRUE) Static $perm variable is cleared and re-filled with permissions from current $user object. This is correct. When module_invoke () is immediately executed next: module_invoke('node_content', 'access', 'create', 'story', $user) It will now make another call to user_access() : user_access('create story content', $user) The $user object still contains the same roles. The $perm variable now contains values. This is correct. But the values in $perm are NOT the same as those inserted during the ClearCache call above! They have changed, and NOT from the user_access() function (which I am monitoring)! So the question is: Why has this $perm value changed? So far, I've found this behaviour occurs with OGUR when one of the following modules is installed: • taxonomy_access • tac_lite • menu_breadcrumb • admin_menu I so far am unable to discover what it is about these modules which is causing this problem. This did not occur in 5.x and earlier 6.x versions of Drupal. Please, please, please help! -ron

3 2