[@rogercoathup Participant 16 years ago]

Which theme are you using? Does it work OK if you switch to the bp-default theme? Are you sure your theme has been written to make use of the slugs?

[@rogercoathup Participant 16 years ago]

could it be because the BP_DEFAULT_COMPONENT doesn’t exist…. what is ‘updates’?

Delete your define for the default component – does it work now?

[@rogercoathup Participant 16 years ago]

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?

[@rogercoathup Participant 16 years ago]

search these forums, this is discussed lots of times.

Can your site send standard WordPress admin emails, e.g. if you create a new user in the admin panel, does it send an email to you as site admin?

If not, you need to configure your WordPress mail correctly, before proceeding with BuddyPress

[@rogercoathup Participant 16 years ago]

That sounds like a general WordPress question – have you looked in the general WordPress Codex documentation?

I don’t know anyone who uses those wp-admin screens to edit files. For large scale development, you should really be working on a local copy in an editing environment before publishing to your server.

[@rogercoathup Participant 16 years ago]

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

[@rogercoathup Participant 16 years ago]

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

[@rogercoathup Participant 16 years ago]

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.

[@rogercoathup Participant 16 years ago]

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

[@rogercoathup Participant 16 years ago]

@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

[@rogercoathup Participant 16 years ago]

We just went with a loop like this:

`
<?php $args = array (
‘action’ => ‘new_blog_post’,
‘max’ => 20); ?>

<?php
while (bp_activities() ) : bp_the_activity(); ?>

<?php $blog_id = bp_get_activity_item_id();

if ((int)$blog_id == 1) continue; ?>

`

@boonebgorges has talked about adding ‘exclude’ parameters to some of the loop functions, which could make this much neater – I don’t know the progress / state of that work

[@rogercoathup Participant 16 years ago]

hats off to @Chouf1 – a. for solving it, and b. for ‘tagging’ the thread as solved – we should all get into that discipline (although a button to do it automatically would be nicer)

[@rogercoathup Participant 16 years ago]

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.

[@rogercoathup Participant 16 years ago]

@hnla – posting simultaneously !

[@rogercoathup Participant 16 years ago]

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.

[@rogercoathup Participant 16 years ago]

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

[@rogercoathup Participant 16 years ago]

p.s. we have the problem in 1.2.5.2 as well

[@rogercoathup Participant 16 years ago]

@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?]

[@rogercoathup Participant 16 years ago]

@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

[@rogercoathup Participant 16 years ago]

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.

[@rogercoathup Participant 16 years ago]

Yes, there is a BuddyPress primary site … where you’d run a BuddyPress specific theme, that lets you view members directories, group directories, member profiles, etc.

[@rogercoathup Participant 16 years ago]

Look in the documentation on this site about installing BuddyPress in a secondary blog.

That tells you how to do this

[@rogercoathup Participant 16 years ago]

Provide more details about your configuration and your problem.

If you mean you want to allow members to create blogs, you’ll need to ensure you have WordPress multisite setup

[@rogercoathup Participant 16 years ago]

It’s not a question of whether you like it or not, the problem is that it breaks the design of existing sites – because their themes are using bp-default as a ‘much touted future proof’ parent theme.

You expect bug and compatibility fixes in a theme upgrade, not presentation and design changes.

If you’re changing the actual design, you’d expect that in a new theme. Much as you’ll expect WordPress to release 2011, and not simply overwrite 2010 with something different that changes the look of every child theme based on it.

[@rogercoathup Participant 16 years ago]

@djpaul –

Can we happily run the 1.2.5.2 default theme (and children thereof) on the 1.2.6 core? Thereby allowing all our existing child themes to continue to behave the same without any mods at all?

And, as a corollary to this… is there an install option for 1.2.6 that won’t overwrite the 1.2.5.2 theme (other than copying it somewhere pre-install, and then re-instating)?