[@lancewillett Participant 17 years, 2 months ago]

Hey Lars,

See this thread: “after login redirect to another page” for ideas and a plugin that provides this functionality.

[@lancewillett Participant 17 years, 2 months ago]

Hi Tutsie,

This type of change would typically be done with a plugin. Keep in mind that this isn’t a BuddyPress customization as much as it is a WordPress MU one.

I did a quick Google search for “change wordpress admin profile link” and found a few places you could start.

In this WordPress forum topic is some code that would change the behavior of the profile link (albeit for a different reason); this method of changing the admin behavior isn’t recommended, however, since it requires hacking a core file. A plugin would be much better since it doesn’t require changing the core file (and having to stress about updating your WordPress MU code later).

Depending on how much you want to work on this, you could download these two plugins: WP Hide Dashboard and Admin Menu Management, open them up in a text editor, and look at how they change the menus in the WordPress admin area.

Plugins do two things: (1) they provide a new functionality and (2) they hijack the normal WordPress behavior and perform the functionality described in the plugin instead.

Hope that helps…

[@lancewillett Participant 17 years, 2 months ago]

As of revision 1270 in trunk you can now disable the admin bar like this in your “wp-config” file:

define('BP_DISABLE_ADMIN_BAR', true);

That way you don’t need any of those custom overrides in your “bp-custom” file.

[@lancewillett Participant 17 years, 2 months ago]

@Seobrien — good point.

I will post some better/updated directions soon…

For now, the pertinent change to know about is switch from “wp-content/mu-plugins” to the new location for plugins, which is “wp-content/plugins/buddypress”. The “bp-custom.php” file goes inside that folder, and the languages files go inside “wp-content/plugins/buddypress/bp-languages”.

[@lancewillett Participant 17 years, 2 months ago]

@Modemlooper — right now you can’t change the blog avatar.

There is an open ticket in Trac for it: https://trac.buddypress.org/ticket/192, so it is in the roadmap for future versions.

[@lancewillett Participant 17 years, 2 months ago]

Don’t forget to turn the lights off.

[@lancewillett Participant 17 years, 2 months ago]

Sorry I misread your topic… I need to slow down!

You cannot currently change the blog avatars.

This appears to be a hot topic — see also:

https://buddypress.org/forums/topic.php?id=1262

https://buddypress.org/forums/topic.php?id=497

https://buddypress.org/forums/topic.php?id=798

https://buddypress.org/forums/topic.php?id=2046

There is also an open ticket in Trac for it: https://trac.buddypress.org/ticket/192

[@lancewillett Participant 17 years, 2 months ago]

Aron,

The backtick key on your keyboard is probably located at the top left, above “Tab” and below “Esc”. Add one backtick before and one after your code to format it here in the forum.

A nicer way to share code is to use a “paste bin” such as Pastie.org — it supports syntax highlighting and is easy to share: just add the URL to any forum post or email and anyone can go see it.

[@lancewillett Participant 17 years, 2 months ago]

A ha! Gotcha…. That is more complicated.

You can change the label by hacking a core file (not recommended). Do this by editing the following lines in “bp-core/bp-core-widgets.php”:

/* Site welcome widget */

wp_register_sidebar_widget( 'buddypress-welcome', __( 'Welcome', 'buddypress' ), 'bp_core_widget_welcome' );

wp_register_widget_control( 'buddypress-welcome', __( 'Welcome', 'buddypress' ), 'bp_core_widget_welcome_control' );

The more elegant and sustainable approach is to use a language file to modify the text. This would be a better approach overall since you can then change any label in one place (the language file) and not have to worry about an update to BuddyPress core files down the road.

For an example of how to use a language file to edit labels and messages, see my comments and suggestions in this thread.

[@lancewillett Participant 17 years, 2 months ago]

Take a look at your admin menus for BuddyPress and Site Admin.

If you are running an older version of BuddyPress (before revision 1311) look in Site Admin -> BuddyPress. Otherwise the latest trunk has a new top-level menu called BuddyPress (look in General Settings).

View an example of the avatar menu.

And… this probably isn’t a support topic, right?

[@lancewillett Participant 17 years, 2 months ago]

Where do I find the heading in the code base?

Seobrien, the widget content is stored in the database, not in any of the plugin or theme files.

Log in to your admin site, click Appearance -> Widgets, and look for a Welcome widget there.

Once you enable the widget, click “Edit” next to the Welcome title. That should open up the widget for editing, and you can enter any title and text you wish.

See a sample screenshot.

If for some reason you can’t edit the widget as normal, you can also access the content of the Welcome widget directly in the database, by looking in the “wp_1_options” table for an field with an “option_name” of “bp_core_widget_welcome”.

[@lancewillett Participant 17 years, 2 months ago]

Mypop, can you confirm with your host that they support remote procedure calls (and XML-RPC specifically)?

That error message basically means they are blocking RPC calls; probably for security purposes.

[@lancewillett Participant 17 years, 2 months ago]

OK, a clean install sounds like a great idea. Keep us posted!

[@lancewillett Participant 17 years, 2 months ago]

Are there any errors in your server logs?

Based on those database values I’d say that it’s clear that when you create a new group it’s not creating a new forum in bbPress, otherwise your new group would also have a meta_key with a value of “forum_id” and your bp_forums table would have a new entry as well.

This might be a hard one to track down as it could be a problem with your host/server and not with BuddyPress/bbPress.

Just as a matter of being thorough… did you follow Trent’s steps or the steps in the forum component readme file?

When I did my setup I used the readme file steps and everything worked smoothly. Nothing against Trent’s tips and tricks, but I found that if I followed the readme steps it worked fine.

Do you have a way to try the same setup on a different server or maybe on your local machine?

[@lancewillett Participant 17 years, 2 months ago]

and even created new forums

Have you tried creating a brand new group and enabling the forum for it? I only see one group on your site. You could try creating a new group, enabling the forum, then test again.

Since the issue is with an existing forum/group connection, it could be that BuddyPress thinks the forum exists (with a certain “id”) which doesn’t exist in bbPress any more.

If you look in the “wp_bp_groups_groupmeta” table in your database, find the “group_id” for the group you are testing, and then look in the “bp_forums” table and see if the same id is being used there for a forum (look at the “forum_id”).

[@lancewillett Participant 17 years, 2 months ago]

I looked at your site, and in the one group (Test group7), I am seeing the forum (http://mypartyonparty.biz/groups/test-group7/forum). Looks like it’s working… did you try adding a new forum topic yet?

[@lancewillett Participant 17 years, 2 months ago]

Mypop, when you are in the MU admin area — go to the last menu item (it should be labeled “BuddyPress”). Click “Component Setup” and make sure that bbPress Forums is enabled.

Then click the link in that same admin menu that says “Forum setup”, and make sure the settings there are correct.

I noticed when I recently upgraded my BuddyPress to the latest trunk (rev 1324) that those forum settings were empty, so I had to enter them again (URL, username, and password).

[@lancewillett Participant 17 years, 2 months ago]

BeLogical – do you have a link to view your site? It could be as simple as a missing CSS rule for the “selected” class, meaning the PHP code is working fine in the theme but the selected element isn’t getting any specific styles.

[@lancewillett Participant 17 years, 2 months ago]

You should be using the new BP_PLUGIN_DIR constant, which was introduced in revision 1303 for moving to MU 2.7.1 support.

Something like:

define( 'BPLANG', 'spots' );

if ( file_exists( BP_PLUGIN_DIR . '/bp-languages/buddypress-' . BPLANG . '.mo' ) ) {

load_textdomain( 'buddypress', BP_PLUGIN_DIR . '/bp-languages/buddypress-' . BPLANG . '.mo' );

}

[@lancewillett Participant 17 years, 2 months ago]

Timothy, the best thing to do is to disable *all* your plugins and strip the install down to the very basics.

Then add each plugin back in one by one and test after each one to see when it breaks. Otherwise it’s going to be hard to troubleshoot if you have some many different things going on.

[@lancewillett Participant 17 years, 2 months ago]

Thanks for the clarification. I think there are two types of typical WP/WPMU/BuddyPress users: (1) like to run the latest bleeding edge on everything and (2) like to have a stable release that is easy to update.

Depending on the client and site, I fit into both categories.

And yes, “svn switch” is awesome — that’s how I update my normal WordPress.org installs every time a new release is ready (tagged). That workflow (svn switch with tagged releases) is a perfect setup for type 2 above since it’s mostly worry-free.

[@lancewillett Participant 17 years, 2 months ago]

Again, from now on BuddyPress will ONLY work with WPMU 2.7.1+ so please use the 2.7 branch from the WordPress MU SVN repo. Link: https://trac.mu.wordpress.org/browser/branches/2.7

I’ve been using the 2.7 tagged release for MU, not the branch. Are you saying that going forward BuddyPress requires keeping our MU installs up to date with the 2.7 branch rather than using a tag (2.7.1 doesn’t have tag yet I noticed)?

Using the tagged releases is what I always recommend for normal WordPress installs since it’s usually a nice stable release with a clean cutoff at a version number, and doesn’t get committed to generally. But it looks like MU devs (Donncha) don’t tag as often as WordPress.org devs do, so maybe it’s a bad idea to rely on tags for MU.

[@lancewillett Participant 17 years, 2 months ago]

I changed Wire to Wall, see my notes at https://buddypress.org/forums/topic.php?id=1877#post-9953.

[@lancewillett Participant 17 years, 2 months ago]

I also noticed a similar behavior here in this very form where I’m typing (forums, edit topic).

If I post a topic, then edit it, more slashes are added each time I edit. For example, if I edit the same post 3 or 4 times, I’ll end up with \\\\\\\\\\\\\\\it's instead of just it's.

[@lancewillett Participant 17 years, 2 months ago]

One tip from trying to set this up myself: if your wp-content directory isn’t set to a certain permission level (755 or more likely 777), you’ll have to create the cache directory yourself before the object cache can be written the first time.

To test, load your site after enabling the object cache and see if a directory called cache is created in wp-content. If it isn’t, create it and set permissions for it:

mkdir cache; chmod 777 cache;

Load your site again to make sure that files are getting created inside of the cache directory.