[wp-testers] 2.0.2 Release Candidate 1

[Kirk Steffensen]

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.
>
> Ryan
> _______________________________________________

Ryan,

Thanks.  We're changing WPG2 to us the WP_User() class instead of calling
$wp_roles directly.

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.

One of my frustrations working with both WordPress and Gallery2 is that 
Gallery2
does a much better job of defining public methods and variables vs 
private ones.
In Gallery2, if a method is named _method you know its private and not to use
it.  If it's named method, then you know its public and safe to use.  Same
thing with $_var versus $var.

Something like this would be a huge help for plugin and theme developers.

The best thing this does for the Gallery2 community is to define the 
methods and
variables that the core developers can change without affecting their module
developers.  But if they are going to change a public method, they post it for
comment several months ahead of time and give developers time to 
adjust. Example:
http://codex.gallery2.org/index.php/Gallery2:Integration_Howto#New_.28Gallery_2.1.29_Specs_for_GalleryEmbed::init.28.29

They also document their public API in a consistent manner, so that their
automated API documentation shows developers how to use those public methods
and variables.  Example:
http://gallery.menalto.com/apidoc/GalleryCore/Classes/GalleryEmbed.html

The moves toward documenting the WP functions are a step in the right 
direction,
but I still haven't seen an actual guideline for how to do that 
documentation or
a move toward a real API documentation repository like Gallery2 has.  
For those
of us trying to bridge two or more frameworks, this would be a huge 
help.  It's
hard enough to keep one framework straight without good documentation, 
much less
two or three.

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.)

Thanks,
Kirk