BuddyPress.org

@nonegiven Please keep your criticism constructive.

Just an updated. After upgrading Buddypress to 1.2.6 all my site-wide things started working again. Thanks for fixing this!

True, but sadly it is as Rich states; so I thought I’d throw a little humor into the fray

There are improvements to the site planned, you can follow them in the ninjas group.

I think the best solution is to have two separate .mo files with the interface translation and set the translation on wp-content/plugins/bp-custom.php (If you havent the file, create one) with the following code
$lang = substr($_SERVER, 0, 2);
switch ($lang){
case ‘en’:
define( ‘BPLANG’, ‘en’ );
if ( file_exists( BP_PLUGIN_DIR . ‘/bp-languages/buddypress-en.mo’ ) ) {
load_textdomain( ‘buddypress’, BP_PLUGIN_DIR . ‘/bp-languages/buddypress-en.mo’ );
}
break;
case ‘es’:
define( ‘BPLANG’, ‘es’ );
if ( file_exists( BP_PLUGIN_DIR . ‘/bp-languages/buddypress-es.mo’ ) ) {
load_textdomain( ‘buddypress’, BP_PLUGIN_DIR . ‘/bp-languages/buddypress-es.mo’ );
}
break;
}
Check that the filenames are the same

This code detects automatically the browser language and defines the language.

Follow this article to find more about this
https://codex.buddypress.org/buddypress-site-administration/customizing-labels-messages-and-urls/

24 tabs always open in opera and 17 in FF but I am chocked full of that RUM stuff 8 gils worth

i believe it is something they are trying to work on/fix https://buddypress.org/community/groups/buddypress-org-ninjas/

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

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

Template Pack needs to be updated… I’m not sure who’s in charge of that plugin as of right now.

Ping @djpaul!

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/ ]

@paulhastings0 @paulhastings0 @paulhastings0

Test please, you dragged this up

@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

If @paulhastings0 can confirm it works, I’ll put it in.

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

I Just installed a fresh copy of wp 3.0.1 and bp 1.2.6 and received a 500 error using

System Linux
PHP Version 5.2.12
Server API CGI

When I switch my php version to 4.4.8 buddypress installs fine then I switch back to 5.2.12 I start to get the 500 errors again.
I am running this install on a shared hosting platform which I do not have access to the apache error logs to really figure this out. I was wondering if anyone else is having this same issue.

Could you write in a recent tread ? This one was opened 8 mounth ago.
MrMaz posted today to announce v. 05 !!!

@mrmaz , Could you please revise the Create a Link page. Categories are smushed together and like Microsoft Notepad when text isn’t wrapped to the page. It makes it difficult for users to add links in an orderly way.

Instead, could each category be on a new line? Thank you.

Thinking the issue lies with:

/messages/messages-loop.php

bp_message_thread_last_post_date()

function lives in:
/buddypress/bp-messages/bp-messages-templatetags.php: line 288

would guess at the filter

bp_format_time(get_date_from_gmt(

is possibly to blame but will have to see if the ticket sheds light on it