[buddypress-trac] [BuddyPress] #5202: Create a new Group Avatar outside of the Group via PHP
buddypress-trac
noreply at wordpress.org
Tue Oct 15 18:01:43 UTC 2013
#5202: Create a new Group Avatar outside of the Group via PHP
-------------------------------------+-----------------------------
Reporter: svenl77 | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: Groups | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-refresh |
-------------------------------------+-----------------------------
Changes (by boonebgorges):
* keywords: has-patch dev-feedback => has-patch needs-refresh
* milestone: Awaiting Review => Future Release
Comment:
svenl77 and I talked about and worked through this problem a bit at WCEU.
I agree it's very problematic that there's no simple, procedural way to
set an avatar for a group or a user.
The crux of the issue is that our avatar upload handler function relies on
`wp_handle_upload()`, which itself calls `wp_upload_dir()`. We need to
filter the output of `wp_upload_dir()` dynamically, since we store in
different directories for different user/group IDs. The problem is that,
the way that WordPress filters work, the filtering has to happen in a
separate callback function. And that callback function has to have *some*
way of figuring out what the intended group/user ID is. The method we're
currently using is to assume that the avatar is intended for the *current*
group/user, information that is available in the callback function by
(eventual) reference to the $bp global. (If WP filters were set up in such
a way that we could pass parameters to callbacks at the time that we
called `add_filter()`, we could solve this ticket by passing the group ID
manually to the `wp_upload_dir` filter callback.)
svenl77, the solution you have proposed in
set_group_avatar_by_group_id.php is good enough for use in a plugin, but
we can't adopt it for BP core. It's dangerous to be manually modifying
superglobals like `$_POST` and `$_FILES`, because of possible name
conflicts/overwrite (among other reasons). Likewise, it's potentially
problematic to change the value of `$bp->groups->current_group` manually -
in part, because you might want to change the avatar of one group while
looking at another group's page, and making the change you suggest would
mess up the *actual* current group.
A more effective solution in BuddyPress would be to create a new global
key where we could temporarily stash the avatar item id/type, so that
it'll be accessible later on for the `wp_upload_dir` filter. Something
like:
{{{
function bp_core_upload_avatar_to_item( $avatar, $item_id, $item_type ) {
if ( empty( buddypress()->avatar_admin ) ) {
buddypress()->avatar_admin = new stdClass;
}
buddypress()->avatar_admin->item_id = $item_id;
buddypress()->avatar_admin->item_type = $item_type; // 'user', 'group'
add_filter( 'upload_dir', 'bp_core_avatar_dir_filter', 10, 0 );
wp_handle_upload( $avatar, array( 'action' => 'bp_avatar_upload' ) );
remove_filter( 'upload_dir', 'bp_core_avatar_dir_filter', 10, 0 );
}
function bp_core_avatar_dir_filter() {
$item_id = buddypress()->avatar_admin->item_id;
$item_type = buddypress()->avatar_admin->item_type;
$subdir = 'group' == $item_type ? 'group-avatars' : 'avatars';
$path = bp_core_avatar_upload_path() . '/' . $subdir . '/' . $item_id;
// etc
}
}}}
This is all off the top of my head, and some different error-checking etc
will probably be required, but it gives an idea of a safer method to do
what's being suggested here.
Ideally, once we had something like this in place, we would refactor our
existing avatar upload process so that it uses the new functions. Also, it
should be applied to users as well as groups.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5202#comment:1>
BuddyPress <http://buddypress.org/>
BuddyPress
More information about the buddypress-trac
mailing list