Quoting Ryan Boren <[EMAIL PROTECTED]>:
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
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
