#1970 closed defect (bug) (fixed)
Avatars failing to upload in WP-Single
Reported by: | 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)
Change History (29)
#2
@
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
@
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
@
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:
↓ 6
@
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
@
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
@
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
@
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
@
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
@
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
@
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
@
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:
↓ 14
@
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
@
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
@
15 years ago
- Cc gemineye added
For the sake of completeness: Updating to BP 1.2.1 hasn't changed anything.
#16
follow-up:
↓ 21
@
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
@
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!
#19
@
15 years ago
- Summary changed from Avatars failing to upload in WP-Single HAS PATCH to Avatars failing to upload in WP-Single
#20
@
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
@
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
@
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
@
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
@
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.
#26
@
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
@
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!
I deleted all files and uploaded 2.9.2 and a new BP install.. issue still there..
Perhaps a setting stored in the DB?