BuddyPress.org

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.

Have you tried this? https://buddypress.org/forums/topic.php?id=2445

It worked for me

No, not yet. Future versions you would be able to, but I’m not aware of any timescale for this yet.

Justin-

I assume you’re running BuddyPress v1.0. If so, please carefully read the section entitled “Upgrading the Theme files” on this BuddyPress Codex page.

A few questions:

1. Are you using the public release of BuddyPress–version 1.0?
2. Are you using a custom theme?
3. Did you read the section entitled “Upgrading the Theme files” in this BuddyPress Codex link?

Hi DJPual-

I’m currently using (with success) the reCaptcha plugin on a dev site. I used hints from these two BP forum threads:

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

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

I hope that helps!