Avatars failing to upload in WP-Single

[DennisSmolek]

In single install Wordpress the avatar script is failing to crop/upload.

The crop issue is because bp_avatar_to_crop() is returning a relative path to the image file instead of a URL absolute. This can be fixed with hard coding but then the file still fails to upload a cropped thumbnail, and the avatar does not change.

Files in question:
bp-default/members/single/profile/change-avatar.php
bp-core/bp-core-templatetags.php
bp-core/bp-core-avatars.php

WP-single 2.9.1
BP 1.2 RC3

To see live go to www.theovc.org registration is open, test away..

I deleted all files and uploaded 2.9.2 and a new BP install.. issue still there..

Perhaps a setting stored in the DB?

Issue seems to be related to something outside fresh installs. I tried a fresh install on OSX 10.6 and jjj did it on Windows 7. Both fresh installs worked fine.

Bumping to 1.2.1, please see if you can isolate the issue so we can reproduce and fix it.

I am only able to duplicate similar (but not the same) behavior on WordPress trunk, which is in a massive state of flux at the moment anyhow.

DennisSmolek?, do you have anything in the offending sites .htaccess that might be rewriting uploads? Can you check your php.ini and make sure everything looks okay there? Also check your error logs and see if there's anything pertaining to the issue; I.E. upload path or temp directory issues?

I'm able to reproduce this but I've modified my core files to fix other issues as well. (keeping gif/png instead of jpeg conversion of the thumbnails - even required some core wp changes to the image functions).

I'll try a fresh install of single wp and bp later this week and detail what I changed.

Replying to nuprn1:

I'm able to reproduce this but I've modified my core files to fix other issues as well. (keeping gif/png instead of jpeg conversion of the thumbnails - even required some core wp changes to the image functions).

Ok, I'm going to add the two files that I modified to get this work on my setup.

*warning* do not use this patch for anything production as it contains a 3rd thumbnail generation for bbpress forums and required modifying the wp-admin/includes/image.php to properly generate a transparent thumbnail (i'm lazy over here and just modified the function)

But maybe it will help, this was merged with a pre-1.2 trunk changes as i ignored updating this file for some of the newer constants (BP_AVATAR_)

and also includes a fix when checking the MAX_WIDTH (as this was causing an issue to fail - not sure if this was addressed in 1.2 final at all)

the .htaccess is:
# BEGIN WordPress
<IfModule? mod_rewrite.c>
RewriteEngine? On
RewriteBase? /
RewriteCond? %{REQUEST_FILENAME} !-f
RewriteCond? %{REQUEST_FILENAME} !-d
RewriteRule? . /index.php [L]
</IfModule?>

# END WordPress

I cant get very far error report wise because its on shared hosting I dont have access to at the moment.

Heres a weird error log:
[Mon Feb 15 21:35:19 2010] [error] [client 67.16.94.2] mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use 'RewriteOptions? MaxRedirects?' to increase the limit if neccessary.
[Mon Feb 15 21:35:20 2010] [error] [client 67.16.94.2] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion?' to increase the limit if necessary. Use 'LogLevel? debug' to get a backtrace.
[Mon Feb 15 21:35:43 2010] [error] [client 67.16.94.2] mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use 'RewriteOptions? MaxRedirects?' to increase the limit if neccessary.
[Mon Feb 15 21:35:43 2010] [error] [client 67.16.94.2] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion?' to increase the limit if necessary. Use 'LogLevel? debug' to get a backtrace.
[Mon Feb 15 21:35:57 2010] [error] [client 67.195.115.95] mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use 'RewriteOptions? MaxRedirects?' to increase the limit if neccessary.
[Mon Feb 15 21:35:57 2010] [error] [client 67.195.115.95] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion?' to increase the limit if necessary. Use 'LogLevel? debug' to get a backtrace.

When comparing access logs to error logs it seems a spider was crawling at the same time so I think its unrelated..

Ok so I ran some tests on the two versions I have. My local version and the version on the server. I put in some echo's for various variables to see what I can hack together. Before I get started here are my results:
BP_AVATAR_UPLOAD_PATH;
BP_AVATAR_URL;
WP_CONTENT_URL;
bp_avatar_to_crop();
bp_avatar_to_crop_src();

Results:
Failing one:
wp-content/uploads
​http://www.theovc.org/wp-content
​http://www.theovc.org/wp-content
wp-content/uploads/avatars/137/dennis-450x300.jpg
wp-content/uploads/avatars/137/dennis-450x300.jpg

Working version:
/Users/desopolis/Sites/wordpress/wp-content/uploads
​http://localhost.localdomain/wordpress/wp-content
​http://localhost.localdomain/wordpress/wp-content
​http://localhost.localdomain/wordpress/wp-content/uploads/avatars/1/dennis-450x300.jpg
/uploads/avatars/1/dennis-450x300.jpg

bp-core-avatars.php line 389

Replace:

		if ( !$path = get_option( 'upload_path' ) )
			$path = WP_CONTENT_DIR . '/uploads';

With:

		if ( !$path = get_option( 'upload_path' ) )
			$path = WP_CONTENT_DIR . '/uploads';
		else
			$path = ABSPATH . $path;

...and report back?

I've got the same issue on WordPress 2.9.2 (SingleUser?) & BuddyPress 1.2. Like DennisSmolek? I'm using it on a shared webhost. The images are uploaded to the correct folder, but cannot be retrieved for cropping due to a wrong path statement.

@jjj: I applied your patch, but it didn't worked. Below you see the paths for the image to crop like its embedded in its "image src=":

Without your patch:
"/home/.sites/_several_/_folder_/_levels_/cmshome/sites/www.stadtfussballgraz.at/web/cms/wp-content/uploads/avatars/4/hannesf2.gif"

With your patch:
"/home/sites/www.stadtfussballgraz.at/web/cms/wp-content/uploads/avatars/4/hannesf.jpg"

It seems like that the absolute (local server) path to the image is used instead of the relative path.

Replying to gemineye:

I've got the same issue on WordPress 2.9.2 (SingleUser?) & BuddyPress 1.2. Like DennisSmolek? I'm using it on a shared webhost. The images are uploaded to the correct folder, but cannot be retrieved for cropping due to a wrong path statement.

@jjj: I applied your patch, but it didn't worked. Below you see the paths for the image to crop like its embedded in its "image src=":

Without your patch:
"/home/.sites/_several_/_folder_/_levels_/cmshome/sites/www.stadtfussballgraz.at/web/cms/wp-content/uploads/avatars/4/hannesf2.gif"

With your patch:
"/home/sites/www.stadtfussballgraz.at/web/cms/wp-content/uploads/avatars/4/hannesf.jpg"

It seems like that the absolute (local server) path to the image is used instead of the relative path.

I forgot to mention that also the preview-button is affected by this.

For the sake of completeness: Updating to BP 1.2.1 hasn't changed anything.

After looking for a solution after a few days I found out, that the upload path handling of WordPress (see "Settings" >> "Miscellaneous") causes this issue. My fix:

Clear "Store uploads in this folder"-path

Set "Full URL path to files" to absolute server path , e.g. "/home/_several_/_folder_/_levels_/wp-content/uploads"

I on the otherhand left my base the same at: wp-content/uploads
but also put the correct URL for the upload folder: ​http://www.theovc.org/wp-content/uploads
I upgraded to 1.2.1
Then I added JJJ's change on 389. Glad to report success!

Working as supposed to now!

I on the otherhand left my base the same at: wp-content/uploads
but also put the correct URL for the upload folder: ​http://www.theovc.org/wp-content/uploads
I upgraded to 1.2.1
Then I added JJJ's change on 389. Glad to report success!

Working as supposed to now!

I am inspired by your success! I have been having exactly the same problem and have started with a completely fresh install that did not help. I just logged into your blog and created an account, then uploaded a file and saw how it is supposed to work FOR THE FIRST TIME!

Now, if I can just get it to work on my site ...

Replying to gemineye:

After looking for a solution after a few days I found out, that the upload path handling of WordPress (see "Settings" >> "Miscellaneous") causes this issue. My fix:

Clear "Store uploads in this folder"-path

Set "Full URL path to files" to absolute server path , e.g. "/home/_several_/_folder_/_levels_/wp-content/uploads"

To clarify: I didn't apply jjj's patch to fix the upload issue.

Another post about this http://buddypress.org/forums/topic/avatar-uploading-to-wrong-folder

Obviously something's not quite right for all installs. Unfortunately we're not getting much technical detail about each install.

After upgrading to 1.2.4.1 I had to change "Store uploads in this folder" & "Full URL path to files" back to their default values (wp-content/uploads & empty string).

Uploading and cropping should be fixed in the 1.2 branch of code. Could use some testing but I've made some good progress today towards fixing it on all installs.

Just put through another avatar update. Closing this ticket as this *should be* fully resolved now. BuddyPress now uses the WordPress upload directory functions 100% to get what a user has set. I've tested backwards and forwards with single and multisite versions of WP and uploads appear fine.

If you're experiencing the issue from the top of this ticket, please reopen this ticket and supply as much info about your installation as possible.

I was interested in this since I remember a similar issue

I tried to sign up at theovc.org (site mentioned above) and at avatar crop stage, got a blank avatar (no image file)

Also just registered at BuddyPress.org and on the avatar upload stage, after clicking 'upload image', I get a blank screen.

Just though it's worth a mention!