[Lance Willett]

Why not just use a group for this?

There isn’t a way to do this in BuddyPress without writing your own code to do it. You could use WP_User_Search to look up users, it is defined in /wp-admin/includes/user.php starting near line 637.

Here’s an example from http://www.clarksonenergyhomes.com/wordpress/2009/03/16/wp-get-users-by-role-function/ (found via Google).

function get_users_with_role ( $role ) {

// gets all users with specified role

$wp_user_search = new WP_User_Search( '', '', $role );

return $wp_user_search->get_results();

}

This type of user search is intended for use in Administration Panels, not on public-facing pages. So be sure you know why you’re exposing that information before you do it. I’d urge against ever showing a member’s user role publicly. It’d probably be much better to use a Group for those users and display them that way — based on their membership in a certain group instead of their user role.

[Lance Willett]

For blog posts, subscribe to https://buddypress.org/feed/.

The site-wide activity feed is https://buddypress.org/activity/feed.

[Lance Willett]

Hi Philpeter,

The language files go only in /wp-content/plugins/buddypress/bp-languages (do not create this folder, use the existing one) and should not be copied or placed anywhere else.

Move your “bp-custom.php” file out of /wp-content/plugins/buddypress/ and into /wp-content/plugins/.

If you are still having trouble, make sure the MO version of the file was created correctly.

[Lance Willett]

Kunal17,

Is there anything else in your “bp-custom” file? Also make sure there are no spaces before and after the opening and closing <?php> tags.

Could you post the entire contents of the “bp-custom” file to http://buddypress.pastebin.com/ so we can look at it?

[Lance Willett]

some Site Wide Activities phrases are still in English

Are you starting with a fresh install and empty database? If not, previous site-wide activity that is cached in the database will not be translated.

[Lance Willett]

What should this label be and where can I find mine?

You have to make it up — it doesn’t come from anywhere. Make sure the definition you choose and the language filenames match since that is how they are loaded.

define( ‘BPLANG’, ‘lance’ );

Ah, that was my mistake. The example should use ‘mysite’ there (I’ve fixed that, thanks for pointing it out).

[Lance Willett]

Socialpreneur, thanks for the note. I updated the Codex page to reflect this; when I wrote the tutorial the automatic upgrade wasn’t an option.

[Lance Willett]

@Kunal17

Is the bp-custom.php file something that I download or create?

You create it yourself, and place it in “/wp-content/plugins”.

What is the ‘mysite’ language translation as defined in the tutorial?

That is a sample definition that I used for the tutorial — you can use whatever you want. Just make it a label that makes sense to you and your site.

Still wondering about the command to convert .po to .mo. How is that run and from where?

Running that command requires that your web server have basic GNU gettext support — if you don’t know if it’s supported, ask your host (it’s pretty standard on most Linux servers).

Running this command also requires command line access to your server via a program like PuTTY (Windows), Terminal.app (Mac), or from inside an FTP program and requires that your server support “msgfmt”. If you do not know how to run commands like this, or don’t have command line access to your server, please see Translating WordPress for other software options for converting language files (like Poedit).

@Craig dean

Also not understanding the conversion of the po. to the mo. using the run command. Is it a ftp app command. Just not sure.

See me answer above. I also updated the Codex page with these notes.

@Mstoppay

my bp-custom.php file wasn’t loading. Once I moved it out of the buddypress folder and into the plugins folder the language change worked… anyone know why that is?

Yes, as of BuddyPress 1.0 the “bp-custom.php” should be placed in the “plugins” folder instead of inside the BuddyPress directory, as noted by Andy in this thread. Thanks for the reminder — I updated the Codex page to note the correct location.

Note also that if you use the “Automatic upgrade” option to update your BuddyPress install, make sure to backup your language files first since they could be removed during the upgrade process (see this thread).

[Lance Willett]

If you are comfortable with SQL and database lookups, you can find the relevant signups with a query like this:

SELECT * FROM wp_signups WHERE active = 0;

Then you can delete the signups that you want to reuse for testing.

[Lance Willett]

Woot WOOT!

OR, in the words of Bubb Rubb and Lil’ Sis: “Whoo whoo!”.

[Lance Willett]

Hi Scotm,

For custom CSS, it’s best to create a file called “custom.css” in your theme — see the “custom-sample.css” in the theme (you can copy that file, rename it to “custom.css”, and modify it).

For the border, you can probably use the #main element, like:

#main {

overflow: hidden;

border: 1px solid red;

}

The reason the border doesn’t go all the way to the bottom of the element in your current setup is that there are floated elements inside of it — meaning that the parent element does not wrap them. Using “overflow:hidden” is a nice way to wrap those floats.

[Lance Willett]

Thanks for the great replies and discussion! If the snippet blog is a possibility, one thing we’ll need to clearly document for the snippet authors is how to show syntax highlighting in their posts.

Paste bins make you choose from a dropdown menu, but that works for that one snippet. A blog post detailing a technical fix for something might have 3 or 4 such snippets in different languages (PHP, Apache file, INI file, CSS, HTML, etc).

I guessed by looking at the other Codex pages (and at the names of the included JavaScript files) that the Codex was using a syntax highlighter plugin that accepted the following shortcode:

Andy, if you could confirm a few of those “authoring” details it will be a big help I think. The most common languages needed would probably be something like:

• Plain text
• Apache
• Bash (command line)
• CSS
• HTML
• INI file
• Javascript
• MySQL
• PHP

The bash, Apache, and INI would probably be displayed OK with “plain text” — but we should just make sure that the plugin the blog uses for syntax highlighting does the other languages well.

[Lance Willett]

Hey Bpress-tr,

Good eyes! Please post this to Trac as a new ticket: https://trac.buddypress.org/newticket. Log in with the same user and password as here on BuddyPress.org.

[Lance Willett]

Vito687 – have you search a bit here on the forums for a possible solution? This seems to be a common problem and there are a lot of threads with helpful hints, like https://buddypress.org/forums/topic.php?id=1960.

Some things to check:

• GD library support on your server
• .htaccess file is in place and doesn’t have lines commented out
• Errors in your server logs
• file permissions

I know you’ve tried looking at the last two already, but it’s still good to try everything again, especially if you’ve changed a few settings but didn’t check the other items afterwards.

[Lance Willett]

Kenneth,

Make sure you are putting the MO language file in the right place — it goes in “{your-buddypress-install}/bp-languages”. Also make sure it’s named correctly with “buddypress-” and the WPLANG locale definition (like “fr_FR” for French).

Then make sure you have defined your language in “wp-config.php”.

You can see all the details at Translating WordPress.

That page explains:

Set WPLANG inside of wp-config.php to your chosen language. For example, if you wanted to use French, you would have:

define ('WPLANG', 'fr_FR');

[Lance Willett]

Here are the instructions from Burt to test your host/server setup for XML-RPC support.

Follow this link to download the XML-RPC test that Burt created: http://ourcommoninterest.org/downloads/xmlrpc-sayhello.zip

The test consists of two files. The first file is a bbPress plugin that you activate in the bbPress plugins area that acts as a XML-RPC server and responds to a simple “say hello” type call. The second file goes in the root of your MU setup.

This test bypasses all the “bbpress_live/discover_pingback_server_uri()” stuff that might be giving you problems. If this works then the issue is most likely in that area and could be a host/server problem.

To load the test, first install the “oci-bb-sayhello.php” file to your bbPress install root in a folder called “my-plugins” (create the folder if it doesn’t exist). Then log into bbPress and activate the plugin. Next, drop the “oci-bp-sayhello.php” file into the root of our MU install so that you can navigate to it easily. Then load “your-site/oci-bp-sayhello.php” in a browser and see what the output is.

There are several possible points of failure if the test fails to authenticate the BuddyPress user that is created for the connection between BuddyPress and bbPress.

1) The BuddyPress connection username/password isn’t the same as the username/password that exists in bbPress. That username/password is stored in “wp_site_meta”.

2) The bbPress user is not an administrator.

[Lance Willett]

Michael, can you find the original bug/ticket you created and paste a link to it? Otherwise it’s hard to track down.

[Lance Willett]

Reprocessor, also take a look at the WP Hashcash plugin — it can help block the spam signups.

[Lance Willett]

@Socialpreneur, I didn’t design it — Tim Bowen of Creative Slice did the visual theme modifications. But thanks! It’s a strong community and BuddyPress has been the perfect fit for us.

[Lance Willett]

Ah — you mentioned RC1. Then yes, the BuddyPress plugins would be in “mu-plugins” still.

Write in new language to msgstr within buddypress.pot and save as buddypress-spots.mo

Make sure you are creating the MO file from a PO file, which is in turn a copy of the POT that is bundled with BuddyPress.

Your “bp-languages” directory should look something like this:

buddypress.pot

buddypress-mysite.po

buddypress-mysite.mo

If you have trouble editing the POT or PO in a text editor, you can use special software also — see https://codex.wordpress.org/Translating_WordPress and look for “Translation Tools.” In my opinion those are overkill for this type of thing, though.

[Lance Willett]

@Seobrien — wrong instructions, maybe? Follow my link: https://codex.buddypress.org/developer-docs/customizing-labels-messages-and-urls/.

There is no mention of “mu-plugins” in the page, and you have to make sure the “spots” part of the file name to match your own site’s nickname or label.

[Lance Willett]

Follow-up: I’ve posted a better instruction set with code examples: Customizing Labels, Messages, and URLs.

[Lance Willett]

For anyone interested in customizing labels and messages (like renaming “Wire”) for example, I’ve posted a full instruction set with examples to the Codex: Customizing Labels, Messages, and URLs.

[Lance Willett]

Ezra, Seobrien, Timothy, and others interested in customizing labels and messages — I’ve posted a full instruction set with examples to the Codex: Customizing Labels, Messages, and URLs.

[Lance Willett]

Ezra,

When you are editing the language file (after copying the POT to a PO), you will see two lines for each entry: a msgid and a msgstr — the message id and the message string. For example:

msgid "Group Wire"

msgstr "Group Wall"

The important thing is to only edit the message string, not anything else. The message id, as well as the lines above it that indicate which file and line the entry belongs to, are essential for the language translation to work and should not be touched.