Skip to:
Content

BuddyPress.org

Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#1970 closed defect (bug) (fixed)

Avatars failing to upload in WP-Single

Reported by: dennissmolek's profile DennisSmolek Owned by:
Milestone: 1.2.5 Priority: major
Severity: Version:
Component: Activity Keywords: Avatar, needs-patch
Cc: nuprn1, gemineye, DennisSmolek, decrawford, jossc

Description

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..

Attachments (2)

bp-core-avatars.patch (3.4 KB) - added by nuprn1 15 years ago.
wp-admin-includes-image.patch (1.7 KB) - added by nuprn1 15 years ago.

Download all attachments as: .zip

Change History (29)

#1 @DennisSmolek
15 years ago

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

Perhaps a setting stored in the DB?

#2 @DennisSmolek
15 years ago

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.

#3 @apeatling
15 years ago

  • Milestone changed from 1.2 to 1.2.1

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

#4 @johnjamesjacoby
15 years ago

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?

#5 follow-up: @nuprn1
15 years ago

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.

#6 in reply to: ↑ 5 @nuprn1
15 years ago

  • Cc nuprn1 added

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_)

#7 @nuprn1
15 years ago

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)

#8 @DennisSmolek
15 years ago

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.

#9 @DennisSmolek
15 years ago

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.

#10 @DennisSmolek
15 years ago

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

#11 @DennisSmolek
15 years ago

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

#12 @johnjamesjacoby
15 years ago

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?

#13 follow-up: @gemineye
15 years ago

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.

#14 in reply to: ↑ 13 @gemineye
15 years ago

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.

#15 @gemineye
15 years ago

  • Cc gemineye added

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

#16 follow-up: @gemineye
15 years ago

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"

#17 @DennisSmolek
15 years ago

  • Cc DennisSmolek added
  • Keywords HAS PATCH added
  • Summary changed from Avatars failing to upload in WP-Single to Avatars failing to upload in WP-Single HAS PATCH

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!

#18 @cnorris23
15 years ago

  • Keywords needs-patch added; HAS PATCH removed

#19 @cnorris23
15 years ago

  • Summary changed from Avatars failing to upload in WP-Single HAS PATCH to Avatars failing to upload in WP-Single

#20 @decrawford
15 years ago

  • Cc decrawford added
  • Component set to Activity

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 ...

#21 in reply to: ↑ 16 @gemineye
15 years ago

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.

#22 @DJPaul
15 years ago

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.

#23 @gemineye
14 years ago

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).

#24 @johnjamesjacoby
14 years ago

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.

#25 @johnjamesjacoby
14 years ago

  • Milestone changed from 1.3 to 1.2.5

#26 @johnjamesjacoby
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

#27 @jossc
14 years ago

  • Cc jossc added

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!

Note: See TracTickets for help on using tickets.