[@boonebgorges Keymaster 16 years, 2 months ago]

@crashutah – That’s right. But chances are that most of your modifications will only take place in a handful of template files, so it’s still way better than having to migrate changes over to a wholesale copy of bp-default. To give you a frame of reference, even a fairly heavily themed version of BP 1.2.x like on http://commons.gc.cuny.edu inherits something like 60-70% of its template files from bp-default.

[@boonebgorges Keymaster 16 years, 2 months ago]

When BuddyPress is updated, changes are often made to bp-default, either to fix bugs, make styling tweaks, or support new features. If you are not inheriting the version of bp-default that is bundled with BuddyPress (in other words, if you copy the entire theme into wp-content/themes and use that instead), then you either won’t get these updates, or you’ll have to manually apply them.

Using a child theme is great in this way. If you use a child theme, you are only supplying the files that you plan on changing, while the rest of the necessary template files are automatically inherited from the parent (in this case, bp-default). This is an especially good idea if you’re only going to make small, CSS-ish changes to bp-default.

[@boonebgorges Keymaster 16 years, 2 months ago]

That’s exactly what bp-moderation does.

[@boonebgorges Keymaster 16 years, 2 months ago]

Eric – You don’t have to, as long as you’ve got them in the correct user_id directory. BP doesn’t store avatar information in the database, it just looks for files in the appropriate directory.

[@boonebgorges Keymaster 16 years, 2 months ago]

One thing you might try is making sure that your modifications get applied later in the process. Change your add_action line to

add_action( ‘bp_init’, ‘erocks_change_bp_tag_position’, 999 );

It’s a long shot, but it might work.

[@boonebgorges Keymaster 16 years, 2 months ago]

How are you reordering bp_nav items to begin with? You might try putting the following code right after you call the global $bp:

echo '

';

print_r($bp->bp_nav);

echo '

';

That’ll show you all the items in bp_nav.

[@boonebgorges Keymaster 16 years, 2 months ago]

It looks to me like you were storing images in the buddypress/bp-themes/bp-default directory, which gets overwritten whenever you upgrade BuddyPress. It’s a good idea to create a child theme for bp-default and to make all of your edits there. I see you’re using one called BuddyPress Colours Aqua; you should store all footer images in that directory, so that you don’t overwrite them when you upgrade BP.

[@boonebgorges Keymaster 16 years, 2 months ago]

Check out messages_new_message() in buddypress/bp-messages.php.

[@boonebgorges Keymaster 16 years, 2 months ago]

If you have a relatively short list of specific URLs that you would like to run over SSL, you should be able to write redirect rules in your .htaccess file.

I was going to give you a sample of how to do that but I realized that I generally suck at rewriterules. Maybe someone else can jump in with some help writing the wildcard rule.

The login widget is trickier because it appears on every page; unless you want the whole site run under https, it’ll be hard to make it visible to the user.

[@boonebgorges Keymaster 16 years, 2 months ago]

I’ve looked at the bp-dev autocomplete plugin before and I think that it wouldn’t take too much work to bring it up to date. Much of the buddypress functionality has changed since that plugin worked, but the javascript would for the most part be completely reusable.

[@boonebgorges Keymaster 16 years, 2 months ago]

I’m surprised to hear that the members are still able to log in, even if they don’t click on their activation link. That shouldn’t be the case.

In any case, you might start your search for the activation key message in bp-core/bp-core-signup.php. The function bp_core_signup_user() creates the activation key and hands it off to bp_core_signup_send_validation_email(), which creates the email. The content of that email message is filtered, so that you should be able to change the message without hacking the core files.

[@boonebgorges Keymaster 16 years, 2 months ago]

@nit3watch is right that Firebug is your friend

The reason why the admin bar doesn’t obey your content width is because it’s not technically in your content. If you view the source of your page, you’ll see that the markup for the admin bar is actually in your footer. Your best bet is to do what @nit3watch suggested and apply styles directly to #wp-admin-bar.

[@boonebgorges Keymaster 16 years, 2 months ago]

@alcina22 I went through this myself not too long ago (moving from a bp-sn-default based theme to BP 1.2) and I ended up rebuilding the child theme to be dependent on bp-default. It was an annoying and somewhat difficult process, but in the end I think it’s better to be dependent on bp-default (which is guaranteed to get developer attention, and which is just generally much easier to work with than bp-sn-parent).

[@boonebgorges Keymaster 16 years, 2 months ago]

Cool, I’m glad to be wrong about this one!

[@boonebgorges Keymaster 16 years, 2 months ago]

There are some known problems with BuddyPress and “almost pretty” permalinks like index.php/blahblahblah. I know that @djpaul was looking at it at one point. In any case, it’s probably a BP problem at this point.

[@boonebgorges Keymaster 16 years, 2 months ago]

Guillaume – To the best of my knowledge, bp_get_activities does not currently support multiple arguments like you’d like it to.

[@boonebgorges Keymaster 16 years, 2 months ago]

It’s a bit tricky because, as far as I know, the group blog doesn’t really know that it’s associated with a particular group. From the point of view of the blog, it’s just a blog with multiple authors. Your best bet is probably to modify or hook into the groupblog plugin to make sure that, after it creates a new blog for the group, it also saves a piece of metadata in the wp_x_options table that associates the blog with a group. That way, in the post loop, you can use that metadata to get the group’s avatar.

[@boonebgorges Keymaster 16 years, 3 months ago]

Sorry to bump an old thread, but I wrote a plugin that begins to address the issue: http://teleogistic.net/code/buddypress/bp-external-activity/

[@boonebgorges Keymaster 16 years, 3 months ago]

Yeah, sounds like a bug. BP_ENABLE_MULTIBLOG implementation is a little incomplete at the moment. trac.buddypress.org with the same login credentials

[@boonebgorges Keymaster 16 years, 3 months ago]

Try commenting out the add_action line in the plugin itself to make sure that it’s the code that is actually causing the problem. If not, then that’s why remove_action doesn’t work.

Otherwise, no, you shouldn’t need to wrap the remove_action in anything.

[@boonebgorges Keymaster 16 years, 3 months ago]

I don’t know of a good sitewide activity widget, but you can look at the code inside of buddypress/bp-themes/bp-default/activity/activity-loop.php (the if ( bp_has_activities…. stuff). Using that as a basis, you can build your own sitewide activity display.

[@boonebgorges Keymaster 16 years, 3 months ago]

Search the plugin files for something that looks like:
add_action( 'bp_nav_items' .....
‘bp_nav_items’ being the operative code here.

If you find something, let’s say
add_action( 'bp_nav_items', 'add_discussion_tab_function' );
copy that line, change ‘add_action’ to ‘remove_action’, and put it in the functions.php file of your theme. That should make sure that the tabs don’t appear.

[@boonebgorges Keymaster 16 years, 3 months ago]

What happens when you try to post? Are you able to *view* forums?

What does it say when you go to Dashboard > BuddyPress > Forums Setup?

[@boonebgorges Keymaster 16 years, 3 months ago]

Mark – just try putting that code somewhere in sidebar.php of your theme. You might need to wrap it in the appropriate divs in order to get it to display in a widget-like manner.

[@boonebgorges Keymaster 16 years, 3 months ago]

It looks like this could possibly be done. Technically speaking, each profile must correspond to a user account. But conceivably, you could build a piece of functionality that allows one user to edit another user’s profile. The key function is bp_is_my_profile(), which is checked when the profile edit screen is brought up. By default, bp_is_my_profile() only returns true if the profile belongs to the logged in account. But the output of the function is filtered. So you could do the following two things to work around the default limitation: (1) Create some sort of interface that allows other individual accounts to “own” (or be “authorized editors of”) other accounts’ profiles, probably storing that information in a piece of user metadata; (2) Filter the output of bp_is_my_profile to check against that user metadata and return true if the logged_user is an authorized editor of the displayed_user.