[wp-testers] 2.0.2 Release Candidate 1

[Owen Winkler]

Kirk Steffensen wrote:
> Quoting Ryan Boren <ryan at boren.nu>:
> 
>> The only place we call $wp_roles->add_cap() is in WP_Role:add_cap() 
>> and that function global $wp_roles properly.  Plugins shouldn't be 
>> calling $wp_roles->add_cap().  They shouldn't really be using 
>> $wp_roles directly at all.

> Ozgreg got the idea to call $wp_roles->add_cap() from looking at Owen's 
> code in
> the Roles Manager plugin, which uses it extensively.

This is partially possible because the Role Manager ensures that 
$wp_roles is initialized to enable Role enumeration, something for which 
there isn't a great wrapper yet.

Here's an idea:

$role = get_role($internal_role_name);
$role->add_cap('new_cap');

This assumes you know what role you want to add the cap to.

These might be useful:

function get_internal_role_names() {
	global $wp_roles;

	if ( ! isset($wp_roles) )
		$wp_roles = new WP_Roles();

	return array_keys($wp_roles->role_names);
}

function add_matching_cap($has_cap, $new_cap) {
	global $wp_roles;

	if ( ! isset($wp_roles) )
		$wp_roles = new WP_Roles();

	$new_cap_roles = array();
	foreach($wp_roles->role_objects as $rolename => $role) {
		if($role->has_cap($has_cap)) {
			$role->add_cap($new_cap);
			$new_cap_roles[] = $rolename;
		}
	}
	return $new_cap_roles;
}

These two functions are completely untested, but the latter was 
something that MarkJ was looking for earlier, too.

> All that said, since there is no clear documentation for what is public 
> and what
> is private, we use what we can to get the job done and then pray every 
> time a
> release comes out that it doesn't break our plugins.  So far, 2.0 broke 
> WPG2
> badly, and the SVN of 2.1 breaks it again because of the fixes that we 
> did for
> 2.0.  (I realize that 2.1 is still very early in development and that 
> it's not
> fair to pick on it, but it demonstrates my point that we made the 
> changes we
> needed to based on the discussions with you and Andy about the handle_404
> function and now those changes are causing problems with the current trunk
> SVN.)

I do not disagree with what you've said about public vs. private 
methods.  Obviously, it's not always clear what is fair game, especially 
as things from 1.5.2 to 2.1 are all hopefully transitioning toward a 
cleaner API.  But...

With WordPress providing such a robust method for plugins to handle 
their own custom URLs, I've always wondered why WPG2 uses such a strange 
method (waiting to override 404s) to have its content displayed.  Mind 
you, I don't use Gallery or WPG2, so I have no idea whether there is a 
specific reason for inserting its hooks in this place, I'm just 
wondering if there wasn't a more future-proof way.

I've seen some other plugins do some crazy things, too.  FAlbum, for 
instance, started writing its own rules to .htaccess after the WordPress 
rules.  Users were left to reposition the new rewrite rules before the 
WordPress rules manually, which isn't very user-friendly, and also not 
as configurable or secure (.htaccess must remain writable) as using the 
internal rewrite.

Granted, the internal rewrite is a bit arcane, but that seems to be a 
better place to hook in.

Of course, feel free to respond with the "Oh, yeah. Duh." response that 
explains it all.  :)

Owen