Forum Replies Created
You need to wrap the code Andy provided in php tags. At the very top of the file, type:
Then at the bottom, type:
Make sure there are no spaces after that last angled bracket. Save the file with the php extension and you\’re good to go.
If this is not clear, open up any BuddyPress file and look at the php tags.
No temple necessary. A small shrine, however, might be nice.
So is this the official announcement of the unofficial plugin, or the unofficial announcement of the unofficial plugin?
I’m not officially at liberty to say. Unofficially I’m confused too!
To use this unofficial version of the skeleton component, you should at least be running WPMU 2.7.1 beta1 and BP r1324 (although you’ll probably be okay if you just have r1303 installed). But, you should at least by aware of this important change: http://trac.buddypress.org/changeset/1316
I’ll keep the package posted at the above location until it is either proved a disaster or is found useful and becomes an official BuddyPress package (Hint Hint).
We did not make changes through a subversion controlled environment. I did not deem that necessary. We did, however, comment all of our changes and started each comment or comment group with “v1.2_URC1:”. So, you can search on that phrase and see where we’ve made changes.
Andy, it would be great if others with more intimate knoweldge of the inner workings of BuddyPress and the recent changes could look at this unofficial version of the skeleton component. I’d be more than happy to transfer it to your domain to use as is or alter as necessary.
See this post in the thread Robert linked to: http://buddypress.org/forums/topic.php?id=1994#post-10563.
You need to be using the WPMU branch.
Makes sense. I was wondering if you were trying to symlink.
It seems that you have your path to the BP plugins incorrectly setup. In the error message, it lists the path as /wp-plugins/buddypress/. It should be /plugins/buddypress/
From R1303, BuddyPress plugins were moved out of the /wp-content/mu-plugins/ directory and into the /wp-content/plugins/buddypress/ directory.
I’ve tried it on MU 2.7 and MU trunk
If you simply updated to the recent BP trunk without following this notice ( http://buddypress.org/forums/topic.php?id=1994 ), then you will have all sorts of issues.
Am interested in utilize Amazon\’s S3 for storage of all user uploaded media content.
Are you going to stream the media from Amazon\’s S3?
Yes. We plan on streaming all rich media content. We have not yet got to the stage where we are actively working on this aspect of our sites, but it is in the plan.
We are waiting to see how BuddyPress\’ Album component evolves. We hope that it moves beyond static media and allows the incorporation of a variety of rich media formats.
Actually, there is another plugin on BPDEV that allows admins to pick groups to feature.
Each of these plugins call different functions. So although much of the code is similar in principal, my plugin cannot be used to feature a group nor can the featured group plugin be used to feature a member.
We have two social network sites (one with a semantic web component) that we\’ll be hosting on slicehost. We plan to utilize Amazon\’s S3 for storage of all user uploaded media content.
As the sites grow, we may also use Amazon\’s CloudFront for a more robust content delivery network. I do not see us using Amazon\’s EC2. Slicehost combined with S3 will give us more than enough control over our costs, bandwidth utilization, and server load.
For one of these sites, we are also experimenting with HyperDB, the replacement database class to the standard WPDB.
I prefer Slicehost over MediaTemple. Given your stated requirements, a 1GB slice will work fine. You\’d probably even be okay with a 512 slice. In fact, you can start with 512 and upgrade if you find it is insufficient.
By the way, here is a Slicehost forum thread you may find useful: http://forum.slicehost.com/comments.php?DiscussionID=1082&page=1#Item_0
You say it\’s jquery function, but above code comments out jquery and prototype as default. Perhaps this is the reason why?
I never answered your question about jQuery being used for avatar cropping. If you look for the bp_core_add_cropper_js function, you\’ll see it exists in the file bp-core-cssjs.php. That function relies upon jQuery to do the avatar cropping.
You may want to also contact Joe Tan ( http://tantannoodles.com/ ). He is the one who made the Amazon S3 WordPress plugin I linked to in your other thread on this topic.
He already knows the technology and may be able to more easily adapt and expand his S3 plugin.
If you have not yet done so, you should update your trac record with your findings.
Also, it does appear that in a future version of this component file, the avatar size limits will be configurable by the admin. In bp-core-avatars.php, see the TODO comment:
/* Define settings for avatars. [TODO] This will eventually end up as admin configurable settings */
define( 'CORE_AVATAR_V1_W', apply_filters( 'bp_core_avatar_v1_w', 50 ) );
define( 'CORE_AVATAR_V1_H', apply_filters( 'bp_core_avatar_v1_h', 50 ) );
define( 'CORE_AVATAR_V2_W', apply_filters( 'bp_core_avatar_v2_w', 150 ) );
define( 'CORE_AVATAR_V2_H', apply_filters( 'bp_core_avatar_v2_h', 150 ) );
Okay, no problem. I’ll finish my 1.2 version of the skeleton and work with that until an official version comes out.
Yes, that does make sense.
If you look at bp-core-avatars.php, it sets the small avatar version at 50 by 50 and the large at 150 by 150. So, if your source image is smaller than 150 on at least one of its dimensions, you could have issues with the large avatar creation.
Do you see the black bar only on the large avatar version?
Well, okay then. You have the same GD library that I’m using.
Have you always had this problem or did it start happening after you updated BuddyPress?
The function that takes care of avatar cropping is a jQuery function. I’m not sure, but I think it relies upon PHP’s GD library. Perhaps this could be your issue.
I’m all out of ideas on this one. Andy or someone with more inside BP knowledge will have to take it from here.
I’m going to wait for a response from Andy but I may have all the code changed over soon enough. In other words, I’ll have my own version 1.2.
I realize that there is no way that the skeleton component can be kept in sync with trunk, but it has almost been 2 months since v1.1 was released so I thought it was time to ask.
I do know what you mean!
I’ve tried recreating your problem. I develop on a Mac and cannot replicate this issue in either Safari of Firefox (tried multiple versions of both). I’m running WPMU 2.7 and BP r1286.
Are you developing locally? Or are you on a remote server?
Has this always been an issue? Or could you properly crop before but not since a recent BuddyPress update?
I also assume that you cleared your browser’s cache and cookies, relaunched your browser and tried again. In years past, some people had issues with avatar cropping in IE. That trick seemed to usually work. However, since you’re also seeing this behavior in Firefox, that’s probably not what’s happening here.
Finally, which version of PHP are you running? Can you also check which version of the GD library is installed?
Okay, I looked at the screenshots again. It does indeed seem like you selected a square image.
On more thought, I guess it would not be possible to select anything but a square image using this feature. So, you select a square area of your image but it chops off a part of the selected area.
I assume this happens with any image you try. Have you tried using a different browser?
I saw your screenshots in trac. Please tell me if I understand what you’re trying to do.
Based on those screenshots, it appears you are trying to crop an avatar and make it a non-square size. Is that true?
If so, avatars (as used in the WordPress world and many other places) have a square dimension. That is why the extra black bar got added to your crop. The Image processing code for changing your avatar is set to output a square-dimensioned image.