BuddyPress.org

Have you done the basic first steps – deactivating your plugins, and switching to the bp-default theme – does the problem still persist in this case?

reset? what exactly do you mean? I trust you’re not going to tell us you edited the default styles directly are you? if you did, then rename your adjusted files to default-custom.css and copy a fresh set of default files in from a new download, then you can remove them afterwards and revert back to your custom files.

Later you will want to create a child theme so reverting can be done by changing themes in the backend.

looks like a child theme to me, is it yours? in other words are you responsible for the customisations, in which case you know that nothing vital has been altered or left out.

What portion / section of the uploaded image is saved given that you say you haven’t got the crop window whay area does get saved.

This has to almost certainly be a JS issue, with JS disabled the whole mechanism handles pretty badly, and really needs flagging as something to look at one day.

please read the documentation !

BuddyPress Codex

Are you running a custom theme or default theme? if a custom one have you tried running bp-default and seeing if the issue still occurs.

Not sure what that SC represents, but if that is your upload view then clearly you’re not running the default theme? if that is actually the image, not sure what to suggest.

Always check the the docs/codex to see if there are any guides that cover a question:
https://codex.buddypress.org/extending-buddypress/building-a-buddypress-child-theme/

To link your logo to homepage open up a header file bp-default or a wp default header file and have a look at the markup where the logo is set, although isn’t the logo already linked if you’re using the default theme?

I don’t know much but I think one nice option would be to comment out or remove the Blog creation details section from the register.php file of your theme.

register.php file residence : yourtheme/registration/register.php

blog creation details section on register.php would be approx : from line no. 169 to line no. 201

or simply comment out line no. 173
or the line with

<?php _e( 'Blog Details', 'buddypress' ) ……

and line no. 175
or the line with

<input type="checkbox" name="signup_with_blog" i …………………….

This may solve your issue with keeping the blog registration open but stopping new people from registering it from the register page of your site.

where would I create bp-custom.php? I want to use that one as I haven’t decided upon a final theme yet so I’d rather go with bp-custom.php

You are probably best to find a suitable WordPress theme, and then use the BP template pack to make it compatible with BuddyPress.

Have a Google for WordPress Magazine themes

@r-a-y :

p.s. I do agree with you on a number of things here –

yes: new features as theme options (opt-ins, not outs), and yes: it’s probably part of a wider jigsaw – a well developed Codex would have helped, as would a much clearer / better signposted buddypress.org (invitations to test 1.2. and how to, were only obvious to a knowledgable few – which may explain the small uptake).

I do hope you’re wrong re: 2010! [Although standard WP does have the benefit of not forcing so much presentation / content on your design – most of it being dealt with in the theme]

We have two clients for whom the layout / content of the activity stream is absolutely critical – we’ve been through many many design revisions (down to the pixel level!) to get it right for them. These things are important.

WP also gives a clear warning over functions being deprecated, with advice well in advance as to alternatives to use.

Wordpress will most likely build on top of 2010. They will not make a theme called 2011, unless the design is radically different.
Much like Kubrick to 2010 was a totally different design.

For example, P2 adds features on top of their theme all the time and I think a lot of people appreciate that.

Maybe new features should be a theme option…

@r-a-y – sure, we can get rid of them with some additional work on sites in development, but what about the installed sites – who’s going to schedule, manage and pay for their modifications?

As you know, BuddyPress has real world 3rd party implementations – it’s not just in the realm of coders, who only maintain and support their own site.

If the client hits the upgrade button (which the admin system will be encouraging them to do), they will be left with a site that doesn’t look like they want (and in some cases, will have multiple buttons and areas that simply don’t work anymore).

Surely, the whole point about a child theme is the exact opposite – it’s not expecting things to change – it’s expecting the parent to stay working as expected when the core is upgraded – to provide us with a safe consistent level of abstraction.

The client has paid for a site they want, designed the way they want – not to have it change on the arbitrary design whims of a 3rd party they’ve never met.

What will happen when WordPress bring out a new design for their default theme? Will they overwrite 2010 and thereby change the look / behaviour of every child based on it? Of course not, they will they introduce it as a new theme, and 2010 will happily continue to function.

Make sure your functions.php looks like this:

`<?php
/* Disable default themes header stuff */
define( ‘BP_DTHEME_DISABLE_CUSTOM_HEADER’, true );
?>`

The whole point of having a child theme is inheriting all the cool, new features of the parent theme; I think we shouldn’t be making comments after the fact BP 1.2.6 was released. The core team asked many times for testers to the 1.2 branch; some did test, but many did not.

Like it’s been stated, secondary avatars can be removed by getting rid of the filter. I do agree that blog avatars shouldn’t be used since you can’t even declare a blog avatar yet. However, you can get rid of that quite easily by duplicating the secondary avatar function and removing the “blogs” case.

The following code will work in your theme’s functions.php:

`function ray_secondary_avatar_fix() {
remove_filter( ‘bp_get_activity_action_pre_meta’, ‘bp_dtheme_activity_secondary_avatars’, 10, 2 );

// add the following if you still want secondary avatars, but omitting the blog one
function my_bp_dtheme_activity_secondary_avatars( $action, $activity ) {
switch ( $activity->component ) {
case ‘groups’ :
case ‘friends’ :
// Only insert avatar if one exists
if ( $secondary_avatar = bp_get_activity_secondary_avatar() ) {
$reverse_content = strrev( $action );
$position = strpos( $reverse_content, ‘a<' );
$action = substr_replace( $action, $secondary_avatar, -$position – 2, 0 );
}
break;
}

return $action;
}
add_filter( ‘bp_get_activity_action_pre_meta’, ‘my_bp_dtheme_activity_secondary_avatars’, 10, 2 );
}
add_action( ‘init’, ‘ray_secondary_avatar_fix’, 9 );`

I do agree that there should be a better changelog for changes made to bp-default. Maybe in the codex?
[ EDIT: changelog created here – https://codex.buddypress.org/extending-buddypress/bp-default-theme-changelog/ ]

@chouf1 –

It’s a baffling decision by the core team – I don’t know why they thought it was reasonable to break the design of every child theme that’s been based on the bp-default parent.

bp-default was not a standalone theme, it was a parent to hundreds of child themes. There was a responsibility to keep it delivering what those child themes had been built to expect.

As @chouf1 says, if this couldn’t be done – the upgrade should have been clearly labelled with a strong unequivocal warning.

It wouldn’t be too late, if they fixed this immediately, and upgraded bp-default so it maintains it’s existing behaviour. If they want to add new features, put them where they belong – in a new theme – don’t change the behaviour of the existing one.

@johnjamesjacoby

@intimez – Just checked Private Messages for Friends Only and the plugin still works fine on BP 1.2.6.

BP 1.2.6 made some changes to the way buttons are rendered.

If you modified the member header in your child theme, you’ll need to look at the changes made to /members/single/member-header.php and apply them.