Skip to:
Content
Pages
Categories
Search
Top
Bottom

Single sitewide avatar per user?

  • @rebootnow

    Participant

    I am upgrading a site to the new BP version and one thing that rocks is the fact that BP doesn’t go to the db to get the avatar filename. That makes it feasible to access the avatar efficiently in far more places.

    One little issue I see though: the URL is built using the BP_AVATAR_URL constant, which in turn is defined using bp_core_avatar_url(), which in turn uses wp_upload_dir() as the base of the path. This means that when you are in a blog other than the primary blog, it goes to that blog’s upload directory for the avatar.

    Is this “by design” so that users can have different avatars for different blogs?

    I know that I can hook into the filter at the end of bp_core_fetch_avatar() to change the current behavior, but before I do that I want to make sure that BP does have multiple avatars for a user.

Viewing 11 replies - 1 through 11 (of 11 total)
  • @rebootnow

    Participant

    Quick update on how I made this work. Added the following filters in bp-custom.php.

    I would still like to know if BP is expected to look for different avatars depending on the blog that is currently active.



    /* Set sitewide avatar path for all blogs */
    function _core_avatar_upload_path( $path )
    {
    return ABSPATH . ‘wp-content/blogs.dir/1/files’;
    }
    add_filter(‘bp_core_avatar_upload_path’, ‘_core_avatar_upload_path’ );

    function _core_avatar_url( $url )
    {
    return ‘http://’ . get_current_site()->domain . ‘/files’;
    }
    add_filter(‘bp_core_avatar_url’, ‘_core_avatar_url’ );

    @djpaul

    Keymaster

    Some avatar bug stuff has been fixed in the next version of BuddyPress.

    @peterverkooijen

    Participant

    @Paul Gibbs, can you point out which pieces of code have been fixed, which functions etc? Is it also WP 3.0-ready? Is it documented somewhere, on trac or something like that? I’m not a developer, so I’m not sure where to start.

    @rebootnow

    Participant

    Peter, this is info that you could get in trac as easily as Paul. I think he may be referring to this ticket: https://trac.buddypress.org/ticket/2451. But it isn’t exactly the same bug. My issue seems independent of BP_ENABLE_MULTIBLOG.

    Digging around in trac I found this changeset by @apeatling that introduced the problem: https://trac.buddypress.org/changeset/2984 (as a fix to https://trac.buddypress.org/ticket/2317 ).

    After this change the BP_AVATAR_URL and BP_AVATAR_UPLOAD_PATH are derived from wp_upload_dir(). So the avatar location is based on the uploads location for the individual blogs, instead of being based on the upload location for the primary blog.

    I would suggest using “get_blog_option( BP_ROOT_BLOG, ‘upload_url_path’ )” and “get_blog_option( BP_ROOT_BLOG, ‘siteurl’ )” but it seems from the comments in the ticket that JJJ thought they weren’t reliable.

    UPDATE: I have opened https://trac.buddypress.org/ticket/2469

    @rebootnow

    Participant

    Ah, it seems that the 1.2 branch is more up to date than the trunk. The “bp_core_avatar_upload_path()” and “bp_core_avatar_url()” there solve my problem by correcting the path/url for the multiblog case.

    @johnjamesjacoby

    Keymaster

    Yeah the trunk needs to be merged with the branch after 1.2.5. Thanks guys for helping out.

    @windhamdavid

    Participant

    thanks @johnjamesjacoby for the follow up and @rebootnow for the additional insight on this. I believe that tickets #2451 and #2469 are related because with multiblog enabled it’s still kicking an avatar path and upload relative to the wp_upload_dir(). I tested the 1.2 branch but I just svn sw’ed up to 1.2.5 and I see the that the trunk merge didn’t quite make it regarding avatar_upload_path(). There are no differences between the bp-core-avatar.php in the 1.2.5 tag and 1.2 branch? This one is outsmarting me thus far, I’m afraid to filter the core_avatar_upload_path with custom functions for future compatibility and the filters don’t exactly account for the structure of the avatar uploads if the upload path for the site settings is modified – as in something like such http://gzet.net/wp-content/uploads/avatars/ ~ when the rest of the sites adhere to the /blogs.dir/#/ protocol.

    @windhamdavid

    Participant

    I do however see these bits of goodness in the trunk which is indicative of my current structure and leads me to believe that the fault is as @rebootnow called it. It’s still asking for get_current_site() when displaying avatars on a secondary blog with multisite enabled.

    + if ( bp_core_is_multisite() )
    + $path = ABSPATH . get_blog_option( BP_ROOT_BLOG, 'upload_path' );
    + else {
    + if ( !$path = get_option( 'upload_path' ) )
    + $path = WP_CONTENT_DIR . '/uploads';
    + else
    + $path = ABSPATH . $path;
    + }

    and


    if ( bp_core_is_multisite() && BP_ROOT_BLOG != $current_blog->blog_id )
    - $upload_dir = str_replace( $current_blog->blog_id, BP_ROOT_BLOG, BLOGUPLOADDIR );
    -
    - return apply_filters( 'bp_core_avatar_upload_path', $upload_dir );

    @windhamdavid

    Participant

    kaching – this works

    @johnjamesjacoby

    Keymaster

    1.2.5 has an almost totally rewritten bp_core_fetch_avatar function that should fix these issues. Can you confirm that all files are up to date and try again?

    @peterverkooijen

    Participant

    “Peter, this is info that you could get in trac as easily as Paul”

    I’m not a programmer, so I wouldn’t know where to start with trac. Thanks for the pointer!

    I’ve replaced some functions in my custom 1.1.3 mess with code from 1.2.5 and have some partial success. Uploading avatars still does nothing though. Has everything been fixed in the latest BP? It works on a clean install, but do I need to manually update settings for upload_path or other things in an upgraded installation? Create an uploads folder? Other things to check?

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Single sitewide avatar per user?’ is closed to new replies.
Skip to toolbar