BuddyPress.org

Does any of these instructions change for the newly released BuddyPress 1.0?

I got around to installing buddypress and it looks great but was bummed to realize that the forums don’t work right of the bat. Are there any updated (simpler) instructions now that ver 1.0 is out?

The WordPress MU language file should be in /wp-includes/languages/ and you can change the language in your admin section of your wpmu install.

The BuddyPress language file (buddypress-xx_XX.mo) should be in /wp-content/plugins/buddypress/bb-languages/ the xx_XX should be the same as on the file in /wp-includes/languages/ since BP gets the language setting from WPMU…

You don\’t have to edit anything in your wp-config.php file!

All of this is for WordPress MU 2.7.1 and BuddyPress 1.0. I don’t know how it is with older versions…

HTH

Regards,

RuneG

update: Tried too with BuddyPress v1.0 with the same results… 404 errors on the social slugs…

Anyone around knowing a good tool to export/import the database of WordPress MU/Buddypress so I’d not need to do all this manually? I know I’ll be making errors because there are minimally 10 blogs to move.

Kogigr now you have buddypress-el_GR.po and buddypress-el_GR.mo in /wp-content/plugins/buddypress/bp-languages/ right?

in wp-config.php insert on line #77

define (\’WPLANG\’, \’el_GR\’);

and save…

I think this should resolve (BP side), however, looks for the translation of MU in greek.

@Kogigr;

AFAIK, you have to use the same language in WPMU as in BuddyPress. BuddyPress gets the language setting from WPMU. There is some info about the greek WPMU translation here, but I don’t read greek, so it’s not necessarily the info you need

But you’ve named the file(s) right, you only need the .mo file in your bp-languages folder.

So basically you need to use the same language in WPMU that you want to use in BP. So get the greek WPMU translation, upload it to you WPMU install, and change the language in you admin section…

HTH

Regards,

RuneG

@Sgrunt: Was your problem by any chance related to which I’m still having, documented at https://buddypress.org/forums/topic.php?id=2314 ? I’m continuesly getting 404’s as soon as I use the old buddypress database on the new install. The “save” didn’t help at all..

The only known way of fixing this is manually inserting ALL articles and parameters by hand from one to another database requiring 2 builds to work parallel. This is heavy for just an upgrade .. what will it be with RC3 etc..?

Make sure you have re-selected the member theme in “BuddyPress > General Settings” and hit the save button, even if it is already selected.

i’ve the same issue: only the home page is displayed, but members, groups, profile pages…everything leads to a 404. I’m testing it locally with XAMPP.

I’ve made a manual upgrade, and i’m using default themes both for home and profiles.

this is the path of the theme i’m using: wp-content bp-themes bpmember

note: i’ve tried the solutions posted here: https://buddypress.org/forums/topic.php?id=2457 with no success

note: i’m running the wpmu 2.71 zip (downloaded 1 hour ago)

Good luck, Tony!

I’m setting this to resolved as this issues is related to WAMP and not BuddyPress.

BeLogical-

I am on skeleton component v1.1 and not v1.2.

Just to make sure, you do realize that we are talking about themes and not plugins here?

You are talking about the Skeleton Component for developing a custom plugin, not designing a custom theme. For a custom theme, you would want to use the Skeleton Theme.

Assuming that we are on the same page, then yes, there are significant differences between version 1.1 and version 1.2 of the Skeleton Component. You need to use the newest version. See the changes here: https://codex.buddypress.org/how-to-guides/creating-a-custom-buddypress-component/

@Timschmi

Hi Tim! I think that the plugin is looking good at the moment. Even if it’s only in it’s starting phase. Personally I would prefer a stronger integration, although this probably can be done with skins it would e neat if the wiki loaded inside bp much like group forums. But it’s hardly very important right now. I have a question though.

Will it be available for download soon or is the plugin not meant for the public? Looking forward to being able to tinker with it on my testinstall of buddypress.

PS. As the plugin works now each wiki can have a wire. The user experience is pretty much the same as a group except it does not have a forum. And if I understood everything correct the plugin is based on buddypress groups. The difference right now between placing the wiki inside a group making a “group wiki” and how it is now is that the current solution basically creates 2 types of groups, one with forum function and one with wiki function.

As a wikis main function is often to document something it is usually tied to something. A community or a project, or if you will, a group. The nature of this documentation is fairly static and in depth, as in once the documentation is done it covers most aspects on the subject and changes very little. A wiki page is often written by many people.

Compared to that a blog is quite different. While a blog can be tied to something else it is tied much more loosely and can in fact stand on its own. The nature of a blogpost also differs from a wiki page in many ways. They tend to focus on the specialised and recent. You seldom return to a blogpost to edit it, you write a new one instead. A blogpost is often written by one person.

This is why I think merging the two different types of groups so that wikis appear inside groups instead of having them appear inside their own group category would be preferable.

While running blog on your own makes perfect sense, doing the same with a wiki does not. Especially on a social network site. If you simply just want to use a wiki-engine, simply just install one.

This is just some reflections I had on the plugin.

But then again elloandfriends is your project and you know best what kind of solutions will work for it. I also have no idea of the technical difficulties involved. But as for the plugin as such I think it would be more user friendly and create less confusion with wikis integrated in groups.

@Andrea_r, Thanks for your wisdom!

BTW. What’s the term to refer to WP ( single blog) ’round these parts?

Looks like it’s time to investigate moving from WP to WPMU.

We’ve been developing profiles with Cimy Extra Fields… and have put a fair amount of work into the Member Profile Fields…

http://nbnetwork.org/directory

Some of our users are not ‘active website users’ per say, so the Web Team updates the profiles for them. Seems like there’s no way for admin’s to do that in the Buddpress profile system.

That said, BP is doing what we’ve been trying to do all along, and doing a much better job of it!

” so we’re left with two choices: 1) Switch to WPMU/BP or 2) Install WPMU/BP in a subdirectory.

My first question is this: Am I right about our two choices above?”

Yes.

Switching the whole thing over to WPMU is actually not so bad. The biggest worry there is plugins. Depending on what ones they are, and which ones are a dealbreaker, you will need to test them somewhere ahead of time before even deciding which option to pick.

posts, comments, users, the theme itself and ad placement – ALL those can be *exactly* the same in WPMU.

“The only drawback we have with installing WPMU/BP in a subdirectory is that we’d lose the ability to pull in BP features onto the homepage of our current site such as recent blog activity, avatars, etc. Is that correct or is there some way for the two to communicate even if on separate installs?”

Actually, you can do that. We did it here on http://wanderlustandlipstick.com, a client site. Note it’s not a BP site, but the main site is a single WP install and the WPMU part is under /blogs/. With some lightweight custom code, we pulled in avatars & recent posts to the front of the main blog.

Overall, your choices are pretty much 50/50. The big kicker here is how you want your URLs to be formed in the end.

If you want or don’t care about an extra folder name in the URL where WPMU will live, then it may be “easier” to have it as an add-on, and share databases to share users.

Personally, I’d lean towards moving the whole site to WPMU. Do the move in a dev environment, then in a low-traffic time planned ahead with full notice, make the switch to the new WPMU site (at the same URL basically).

Hi Todd,

I’m in the same boat as you.

Wondering about the same sort of issues…

Mic

Weblog Tools Collection Community http://midout.com

Yes, of course. You can do anything you want. Suggest you read https://buddypress.org/forums/topic.php?id=1632

Arturo, Andy Peatling is the main (only?) developer behind BuddyPress. He should know when he says something like that.

do you have wpmu in greek? save the lang file buddypress-xx_XX.po and the same .mo

xx_XX is language_COUNTRY for example it_IT (italian_ITALY).

bp-groups.php line 1005, right?

'content' => apply_filters( 'bp_groups_created_group_activity', sprintf( __('%s created the group %s', 'buddypress'), $user_link, '<a href="' . $group_link . '">' . $group->name . '</a>') . ' <span class="time-since">%s</span>', $user_link, $group_link, $group->name )

As Arturo’s suggested, check you are working from the .pot file that comes with 1.0. It’s possible it was changed since an older version thus your translation not being applied.