BuddyPress.org

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.

This change is not documented nor annouced in the update post on the BP blog.

About this “some minor tweaks to the included theme”, nobody knows what to do,exactly to retrieve or edit this gravatar. Except here in this tread, which will be buried in the next 3 days in the deepness of this forum
I consider this a bit unfair to find such a picture at this strategic place represented by the SWA page without any permission ! This change can also (as already mentionned) compromise some fine tuned template skills. And what to say about breaking long discuted graphical convention ?
I want at minimum have the possibility to change it, like i can do it for my group avatar for ex.

In 2009, we could choose to use wavarar, gravatar or monsterID from within the admin.
Since 1.2.2 or so, Gravatar is gone (silently) from the admin interface. Now he’s back via SWA….

What do we do(and think) tomorrow, if suddenly Gravatar.com send us an advertising icon instead of a graphic abstract as actually ?
What the sense of all those thousands of millions of icons flying around the web ?
Only to have pretty links or to organize some juicy statistics and server consumption ? The non GPL part of the trick i guess….

ok… two solutions:

1. the nasty hacky – adding define (‘BP_DISABLE_ADMIN_BAR’, TRUE) in our theme’s functions.php

Why nasty hacky: well it inserts inline CSS into our footer to hide the adminbar and remove the padding; that’s nastiest enough in itself, but it also uses !important to override anything we actually want to do – even nastier.

2. the cleaner – adding remove_action( ‘init’, ‘bp_core_add_admin_bar_css’); in our theme’s functions.php

That does the job!

Unfortunately, we have to add that in the functions.php of any additional theme we want to use. Let’s get all this presentation stuff in the default theme where it belongs (not in the core)… I’ve said this a lot recently.

It should be in the theme not in core files but it needs to load at ‘init’ ? or does it? is it that it must load before theme loads

follow up – it’s actually being added in the function:

bp_core_add_admin_bar_css()

in bp-core-cssjs.php

I can’t help but think this should be in the default theme, not in the core files.

@chouf1 – yes, I know where the adminbar.css file is. Coda is my friend

The question was, why is adminbar.css being included in other themes (even none child ones) on a multisite network? What’s injecting it, and how do we turn it off.

e.g. My theme doesn’t explicitly link to adminbar.css, here’s the snippet from the header.php:

`

<link rel="stylesheet" type="text/css" media="all" href="” />
<link rel="pingback" href="” />
<?php
if ( is_singular() && get_option( ‘thread_comments’ ) )
wp_enqueue_script( ‘comment-reply’ );

wp_head();
`

No explicit inclusion of adminbar.css!

But, here’s what actually gets rendered in the browser:

`

`

The unwanted link to adminbar.css has been injected.

I assume it must be something in wp-head() doing it – is there a hook to turn it off?

Hi Roger,
the admin bar is constructed in bp-core/bp-core-adminbar.php
the css file for this is in bp-themesbp-default_inccssadminbar.css

notepad++ is my friend

@clojel

You shouldn’t really mod the core files, as they’ll be overwritten if you upgrade. Is there any filter you can hook on to instead as an interim solution?

Certainly though, this should be added to the trac as a potential bug to be looked at.

We have the same problem with child themes in secondary sites – we’ve turned off the admin bar, we don’t have any admin bar css being included in our child theme, but still it pulls in admin bar css code from bp-default and inserts the unwanted padding.

[As an aside: does anyone know where the code is that’s injecting the admin bar css include into the header of child themes? Is it a hook on wp-footer?]

@whitbyglennk
There is no WP ethos of free software for all. With all the licensing discussions going on, most people have completely misunderstood what it was all about. Free (as in the GPL software license) only means that any further development of GPL software has to be published under the same license (if the software is being released) and that, once you have the software, you can do whatever you please with it. Free does not mean, though, that you can get access to this software without paying. It’s perfectly ok to charge for GPL software.

Most developers, who charge for a plugin or premium themes, still give back to the community by answering questions in forums or uploading other plugins and themes to the WP repository. For some plugins 50+ hours have been spent on development. That’s a lot of money and time right there, but people still expect not to pay anything.

I guess we’ll be seeing more and more paid plugins and themes crop up over the next year. It’s not a bad thing, it’ll give users more choice (there usually is a free alternative around somewhere) and if someone buys a plugin/theme, then afterwards you can expect great support, which does not always happen with a free plugin.

Just me 2 cents

bp-default/functions.php:252
define( 'HEADER_IMAGE_HEIGHT', 125 );
and css tweaked accordingly….

Don’t forget to make these change from within a child theme

@hnla – I think I’d class it as a bug, as it breaks child themes on existing sites
… or perhaps just a deprecated / implementation changed without clear warning mistake

Glenn… there is nothing new in charging for premium themes, it’s not a BuddyPress phenomenon… there are hundreds of people selling premium themes for WordPress (e.g. WooThemes, ThemeForest, …), and even more sites that are completely bespoke developments costing many thousands of pounds.

If you don’t like what people are providing you for free, you don’t have to use their work. If you don’t like the price of their paid for work, don’t buy them. You can take the bp-default theme for free and extend it as you want.

As I explained in one of your other threads about availability of themes, BuddyPress is extremely difficult to create distinctive generic themes for – it’s no wonder that some people charge a few pounds for their themes.

Please check over yesterdays threads as this issue has been covered in two threads and you’ll find the answers there. t’s not a bug but you will need to make some changes to your child theme files.