BuddyPress.org

Thanks! It works. The whole code will be:

`function my_formatter($content) {
$new_content = ”;
$pattern_full = ‘{(\[raw\].*?\[/raw\])}is’;
$pattern_contents = ‘{\[raw\](.*?)\[/raw\]}is’;
$pieces = preg_split($pattern_full, $content, -1, PREG_SPLIT_DELIM_CAPTURE);

foreach ($pieces as $piece) {
if (preg_match($pattern_contents, $piece, $matches)) {
$new_content .= $matches[1];
} else {
$new_content .= wptexturize(wpautop($piece));
}
}

return $new_content;
}

remove_filter(‘the_content’, ‘wpautop’);
remove_filter(‘the_content’, ‘wptexturize’);

remove_filter( ‘bp_get_the_topic_post_content’, ‘wptexturize’ );
remove_filter( ‘bp_get_the_topic_post_content’, ‘wpautop’ );

add_filter(‘the_content’, ‘my_formatter’, 99);
add_filter(‘bp_get_the_topic_post_content’, ‘my_formatter’, 99);`

I am going to have to dredge up this topic again as I have gone through the process of completely reinstalling wordpress 3.5 and the latest version of buddypress 1.6.3 to a fresh new Ubuntu server with only my custom theme, database and alterations to buddypress that were not in the buddypress core file (obviously since the old one has been nuked) and I am still getting a 404 response (from within our wordpress page, not an apache 404) whenever I try to edit, sticky or delete a topic in the forums.

this is still the case even with the default buddypress theme.

This is a buddypress set up to do groupt forums, not sitewide and I do not have bbpress running at all (though interestingly enough, when bbpress was running alongside buddypress, I was not getting our site’s 404 response, but was getting a new topic form and the notification of “Oh bother, there are no topics here” – 0r something like that)

would really like to get this figured out as it is pretty critical and I don’t know how else to debug this (there has to be *some* clues as to why this is happening.)

thanks in advance.

Thank you @mercime.

A small follow-up question on user sign-on/registration. As you clarified, there is a unified login for all wp and bp/bb components. Does it mean that the user profiles (wp profiles and bp extended profiles) are also unified/sync’d?

With regards to the twenty twelve – Buddypress compatibility, let me elaborate my set-up a little.

Twenty twelve is not compatible with buddypress out of the box (like bp-default theme is), so one needs to use bp-compatibility-pack plugin (or can be done manually) to copy-paste buddypress specific .php templates and other files to the theme directory. This also includes buddypress style sheet (bp.css) which seems to be a copy-pasted part from bp-default style.css.

Thus, when you make twenty twelve compatible with buddypress (I am doing this on child theme of twenty twelve), the styles of buddypress components resembles to bp-default (rather than twenty twelve). If one deletes all the css from bp.css, one gets plain styles (these are twenty twelve styles but as there is nothing in twenty twelve styles for bp, they are as good as plain). Fixing these plain styles would be like making a completely new theme from scratch (like styling _s theme) for bp component pages/sections. There doesn’t seem to be a simple workaround about this.

thanx issue solved with the update to 1.4.5

Oops. Trying again:

/**
* In WP 3.5+, get_blogs_of_user() is much slower than in previous versions. As
* a result, if you have a certain number of blogs, running get_blogs_of_user()
* will create a memory timeout. This is a particular problem because
* get_blogs_of_user() is called on every page, because of the toolbar.
*
* Ideally, there would be a way to short-circuit get_blogs_of_user(), or even
* to prevent WordPress from calling get_blogs_of_user() while loading the
* toolbar. But there is not. As a workaround, this function intercepts a key
* step in get_blogs_of_user() – the get_user_meta() call that gets all of a
* user’s metadata. If we determine that this request is coming from
* get_blogs_of_user() (which we do by examining the debug_backtrace(), a truly
* awful technique), AND that it’s one of the generic meta queries used by
* get_blogs_of_user(), AND that the current user has more than 75 blogs, THEN
* we strip all of the blog capability keys from the array of metadata,
* tricking get_blogs_of_user() into thinking that the current user has no
* blogs at all.
*/
function bbg_admin_bar_hack( $check, $object_id, $meta_key, $single ) {
// Only fire when looking at get_user_meta() with no params
if ( ! $meta_key ) {

// check to see whether this came from get_blogs_of_user()
$db = debug_backtrace();
$is_get_blogs_of_user = false;
foreach ( $db as $dbk => $dbv ) {
if ( ‘get_blogs_of_user’ == $dbv[‘function’] ) {
$is_get_blogs_of_user = true;
break;
}
}

if ( $is_get_blogs_of_user ) {
// Get the real metadata, but don’t recurse
remove_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );
$meta = get_user_meta( $object_id );
add_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );

// How many blogs does this user have?
static $blog_count_of_user;
if ( ! isset( $blog_count_of_user ) && is_user_logged_in() ) {
$blog_count_of_user = 0;
foreach ( $meta as $mk => $mv ) {
if ( ‘capabilities’ === substr( $mk, -12 ) ) {
$blog_count_of_user++;
}
}
}

// We only care about those with counts > 75
if ( $blog_count_of_user > 75 ) {
static $clean_keys;
if ( isset( $clean_keys ) ) {
return $clean_keys;
} else {
foreach ( $meta as $mk => $mv ) {
if ( ‘capabilities’ === substr( $mk, -12 ) ) {
unset( $meta[ $mk ] );
}
}

$clean_keys = $meta;
return $meta;
}
}
}

}

return $check;
}
add_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );