Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

See updates below. I upgraded to 3.7.1 using svn. I did this on my localhost first to make sure everything is fine. Everything was, so I proceeded to do it on the server. However, on the server, the users' avatars are not showing up and instead everyone is getting Gravatar's mystery man.

Here is the code I have in my functions.php:

<?php switch ( $comment->comment_type ) :
case '' :
?>
<p <?php comment_class(); ?> id="li-comment-<?php comment_ID(); ?>">
<div id="comment-<?php comment_ID(); ?>">
<?php echo get_avatar( $comment, 40 ); ?>

When I look at the source of the generated page on my localhost for the above I get the following code:

<img src="http://localhost/[path]/wp-content/uploads/avatars/[a number]/[imagename.jpg]"

On the server when I view source I get the following code for the same user:

<img src="http://gravatar.com/avatar/[alphanumeric]=http://[mywebsite.com]/wp-content/plugins/buddypress/bp-core/images/mystery-man.jpg[code]"

I must be making a mistake somewhere but for the life of me I cannot figure it out. The only explanation I can come up with is that Gravatar is not accepting requests from localhost and that is why it is working the way I would like it to on my localhost.

So what do I have to do to make their local avatars show up (the ones they uploaded themselves)? I should also add that I am using the BuddyPress plugin (both on localhost and server).

Aside from that, is there a technique people use to compare the files on the server with those on the development machine? Something akin to vimdiff?

UPDATE: I copied the localhost directory recursively using cp -r to another directory. I then rsynced that directory with the remote server making it a mirror of the server. Then I ran diff -NbBiwr /path/to/localhost /path/to/localhostCopyThatWasRsynced and received no major differences save for stuff in the .svn directories. When I view the copied version in a browser the local avatars show up. This is really starting to make no sense at all. I also updated the sql database to reflect the one on the remote server and the local avatars show up on localhost but not on the remote server.

UPDATE 2: Here are all the things I attempted since the last update:

  1. Toggle wp-debug to true. No errors of note.
  2. Removed the entire directory, did a new svn co.
  3. Deactived all other plugins besides BuddyPress.
  4. Used the default BuddyPress theme.
  5. Installed version 3.6.1 (the last good version I used).
  6. Checked and rechecked directory permissions.
  7. I removed the avatars directory and when someone tries to upload an avatar it creates the avatars directory and the userid subdirectory but the image does not upload. The subdirectory remains blank. This is the error that is returned on the front end Upload Failed! Error was: Unable to create directory wp-content/uploads/avatars/1407/avatars/1407. Is its parent directory writable by the server? As you can see it duplicates the avatars directory and the userid subdirectory for some reason. This happens on both the server and localhost. Localhost is displaying avatars properly however.
  8. Tinkered with birgire's suggestions below. Nothing.
share|improve this question
    
Is there a filter applied to get_avatar on one but not the other? Does localhost have the same settings, plugins, and theme as your server? –  Pat J Nov 11 '13 at 21:06
    
As far as I can tell, yes, they are (supposed to be) mirror images of each other. That is why I was also looking for a way to compare all the files between the two locations. (I should also note that before I ran the svn, the server site showed the users' local avatars just fine.) –  thequerist Nov 11 '13 at 21:45
    
Do you get any info at the bottom of your page from this snippet: add_action( 'shutdown', function(){ printf( '<h3>Debug:</h3><pre>%s</pre>', print_r( $GLOBALS['wp_filter']['get_avatar'], TRUE ) ); }); –  birgire Nov 12 '13 at 0:43
    
This is what was returned (on both localhost and server): Debug: Array ( [10] => Array ( [bp_core_fetch_avatar_filter] => Array ( [function] => bp_core_fetch_avatar_filter [accepted_args] => 5 ) ) ) –  thequerist Nov 12 '13 at 1:58

2 Answers 2

Debug ideas:

You could try to see if this has any effect:

add_filter( 'bp_core_fetch_avatar_no_grav', '__return_true' );

But you should check out the parameters that go through the bp_core_fetch_avatar filter to see if they are correct (untested):

add_filter( 'bp_core_fetch_avatar', 'my_bp_core_fetch_avatar', 99, 9 );

function my_bp_core_fetch_avatar( $html, $params, $item_id, $avatar_dir, $css_id, $html_width, $html_height, $avatar_folder_url, $avatar_folder_dir )
{
    // debug:
    $args = array( 
                    'html'              => $html,
                    'params'            => join( ', ', $params ),
                    'item_id'           => $item_id,
                    'avatar_dir'        => $avatar_dir,
                    'css_id'            => $css_id,
                    'html_width'        => $html_width,
                    'html_height'       => $html_height,
                    'avatar_folder_url' => $avatar_folder_url,
                    'avatar_folder_dir' => $avatar_folder_dir,
            );

   $debug = date_i18n( 'c' );

   foreach( $args as $key => $value )
   {
       $debug .= sprintf( ' | %s: %s ', $key, $value );
   } 

    error_log( $debug . PHP_EOL , 3, '/path/to/my/debug.log' ); 

    return $html;
}

where you have to modify the path to your writeable debug.log file.

The file should then contain lines like this one:

2013-11-12T12:01:16+00:00 | html: ???  | params: ???  | item_id:  ??? | avatar_dir: ??? | css_id: ??? | html_width: ??? | html_height: ??? | avatar_folder_url: ??? | avatar_folder_dir: ???

I updated the above debug code, to take into account that $params is an array.

Some general remarks:

It's interesting to look into the file /bp-core/bp-core-avatars.php.

The avatar image seems to be overwritten via this filter:

add_filter( 'get_avatar', 'bp_core_fetch_avatar_filter', 10, 5 );

and inside the bp_core_fetch_avatar_filter() callback you have this line:

 // Let BuddyPress handle the fetching of the avatar
$bp_avatar = bp_core_fetch_avatar( array( 'item_id' => $id, 'width' => $size, 'height' => $size, 'alt' => $alt ) );

and it was inside that function, I found the applied bp_core_fetch_avatar filter.

So I think these functions might be worth debugging further or maybe you could try to correct the avatars via the above bp_core_fetch_avatar filter?

share|improve this answer
    
The first one produced no differences. The second one I am having difficulty with the permissions, I set them to 777 and still no luck. I did change something in bp-custom.php though. I added these two lines: define ( 'BP_AVATAR_DEFAULT', 'http://[siteURL]/path/to/default-avatar.jpg' ); define ( 'BP_AVATAR_DEFAULT_THUMB', 'http://[siteURL]/path/to/default-avatar-thumb.jpg' ); It replaces the mystery man with that jpg, so it seems since the update it lost the connection to each user's avatar which, by the way, still exist on the server and can be accessed by typing in the complete path. –  thequerist Nov 12 '13 at 18:31
1  
Maybe you can create the file under /wp-content/uploads/ or use the debug.log file created under /wp-content/ when you use WP_DEBUG and WP_DEBUG_LOG in your wp-config.php? –  birgire Nov 12 '13 at 23:12
    
Thanks for the tip. Here is the result: 2013-11-12T20:26:31+00:00 | html: <img src="http://gravatar.com/avatar/[alphanumeric code]?d=http://[mydomain]/path/to/mystery-man.jpg&amp;[params]" class="[classes]" width="40" height="40" alt="Avatar of [user]" /> | params: Array | item_id: [userid] | avatar_dir: avatars | css_id: | html_width: width="40" | html_height: height="40" | avatar_folder_url: http://[mydomain]/correct/path/to/folder | avatar_folder_dir: /correct/path/to/directory –  thequerist Nov 13 '13 at 1:37
    
Getting the above result on both localhost and server, the only difference being that the one on localhost replaces [mydomain] with [localhost] as it should. –  thequerist Nov 13 '13 at 1:47
    
After trying so many debugs I gave up and decided to re-upload the avatars and see what happens. It fails to upload the avatars because it is trying to upload the avatar to http://[domain]/path/to/avatars/[userid]/avatars/[userid] So it is repeating the avatars and userid folders for some reason. Any ideas? –  thequerist Nov 18 '13 at 2:43
up vote 1 down vote accepted

It turns out there was something wrong with the uploads folder. If anybody has this issue in the future, this is what to do.

  1. Deactivate BuddyPress.
  2. chmod 777 uploads/
  3. Reinstall BuddyPress
  4. chmod 775 uploads/

That was all it was.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.