BuddyPress.org

@Peterverkooijen

I don’t believe it is the standard. Facebook and LinkedIn at their core are just name directories so they wouldn’t work without real names, but I can’t think of any other sites that use real names by default. Every forum I’ve ever seen uses “user names,” and so does every other major site I can think of (Twitter, MySpace, Youtube, Digg, Reddit, WordPress, Blogger, Google, Yahoo, etc., etc.). The reason the user/real name issue is so confused with BP is because they have no privacy controls. If BP did it would make perfect sense to use a “fake user name” in public and keep your real name private for friends only.

On top of everyone’s ideas, be sure to check out how to correctly attach your plugin to bp_init:
https://codex.buddypress.org/how-to-guides/make-your-plugin-buddypress-aware-v1-2/

Because of the way that WordPress loads plugins, its possible that bp_init is firing before your plugin has added the hook. If that’s the case, your function is safe to run and needs to be called directly as a fall-back.

Have you tried @jeffsayre‘s Hook Sniffer to see if your hooks aren’t being recognized in the right order? Last time I had a problem like this, Hook Sniffer solved it in five minutes. https://wordpress.org/extend/plugins/wordpress-hook-sniffer/

@emiline220

Why dont use this plugin, it allows “permissions” to be set for xprofile fields:
https://wordpress.org/extend/plugins/bp-profile-privacy/

Works great!

Wouldn’t it be cool for a plugin to remove wp-signup.php and xmlrpc.php from a BuddyPress installation in a way that these changes would be kept through an upgrade of WordPress (which now of course replaces the deleted files)?

@Erich73 it gets better than that.

Check out the opportunities for naughty fun it creates…

https://core.trac.wordpress.org/attachment/ticket/13866/display-name.jpg
https://core.trac.wordpress.org/ticket/13866
https://trac.buddypress.org/ticket/2445

^F^

There will be a dev chat this next week, on Wednesday 30th @ 19:00 UTC.

IRC: irc.freenode.net
Channel: #buddypress-dev
Web-based IRC client: http://java.freenode.net/

We’ve had very few questions for the last few sessions, which is why they haven’t happened (if nothing to talk about, there’s nothing to talk about). Post on the agenda on this thread.

Again, if you’ve got a question you aren’t sure can go in the agenda because you haven’t posted before, feel free to check with me (paul at byotos.com, Twitter, on the forums here, smoke signals, etc) or any of the other forum moderator team.

Create a new xProfile group in the wordpress dashboard; any fields not in the “Base” group will, by default, not appear on the registration form.

FYI, I did start something over on the bpdevel site about this back in May:
http://bpdevel.wordpress.com/2010/05/05/summary-of-may-5th-dev-chat/#comment-254

Feel free to add to the writeboard.

From LPH’s list, I view #2, #3, and possibly #6 as vital.

Use a WordPress plugin like “Mail From”:
https://wordpress.org/extend/plugins/mail-from/

I do not want to speak for Jeff, but I recognized from his posts on this Forum that he knows a lot about Privacy-stuff.

I guess Jeffs Privacy-Features could have been build into the Core-Code already and would have added value to BP.
Let him allow to build his basic-features into the Core-Code and give him the chance to make some money on top of that by providing a plugin which gives “Advanced Privacy Features”.

The same goes for the Events-Plugin which probably only would have needed a bit of support from the Core-guys to get it properly running ?

No Plugin and Core-Code will be 100% perfect from the beginning, but with building this stuff into the Core-Code (with having the ability to activate / deactivate those features in the backend) and therefore having the benefit that many BP-webmasters will have the chance to test those features and providing lots of feedback and for coders providing patches on each of those features in order to improve it.

I guess that is what this article says (read it again !):
http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/

Just apply “continuous deployment” to BuddyPress.

Currently there are many coders working on their own Plugins and are the “Gatekeepers” of their own little walled garden, but think about “Crowd-Sourcing”:
Why not providing a TRAC-tool, which gives all the talented coders on this Forum the chance to commonly work TOGETHER on a specific BP-feature (e.g. Privacy, Front-End-Blog-Posting, Events, etc.) ?

Step out of your own tunnel-vision and take the bigger-world-view and EVERYBODY will benefit.

I’ve thought long and hard about how to address this thread after seeing the conversation so far. I’ll do the best I can.

Ever since I was given the opportunity to work on BuddyPress full time I’ve put every ounce of energy I have into the project. It has gone from nothing – literally fifteen lines of code to something that powers a number of large sites and a whole array of smaller ones. The community has sprung up since then and has grown fast, but it would not exist first without something that people enjoy using and want to discuss.

That has always been my number one priority, build something that people want to use. Without that we have nothing and all the work around the project is in vain. I am not a trained project manager, but up until now I’ve done my best to help the community flourish and feel part of the process.

Now, yes, I haven’t been working as much on BuddyPress for the past three months – anyone using Trac will notice that. I’m no longer spending all my time developing the next version of BuddyPress. I’m working on some features for WordPress.com, helping out with other tasks around WordPress along with continuing to develop the project. The hope is that some of the features I work on for WordPress.com can merge there way back into BuddyPress in future versions or as separate plugins.

The issue we have, and the whole reason behind this thread is that I’m still far too large of a percentage of BuddyPress as a whole. When I slow down or have other priorities the whole project suffers. It should not be like this, the community should not look to me as the final word or the only bringer of direction or progression. If I’m not around for a while BuddyPress should continue to flourish and move forward. JJJ is doing his best to help balance this, but he is only one guy, and a busy one.

To quote a past line from a certain Mr Mullenweg “the best way to dig a hole is to grab a shovel and start digging”. Discussion is great, but to see any change we need action. If you want a new feature or something changed, write a patch. Submit it to Trac, keep consistently writing patches, answering tickets and fixing bugs. I guarantee you will end up with commit access. Right now we have only 10% of tickets with patches, that’s not even close to enough.

If you hate the new site (I agree it’s a mess) then design some mockups, write some HTML wireframes, tell me how much it sucks and your plans to change it. Start a community discussion, but with the goal of a plan of action. I am more than willing to provide access to people who want to get stuck in, but endless forgotten lists of what needs to be improved will not change things.

If you want to write posts for the BuddyPress blog then start writing them, they will be published. If you want to have your say on the direction of the project as a whole then show up and ask your questions at the BuddyPress meetings bi-weekly (there has been a serious lack of questions lately, why?).

Action, action, action. There are many people in the community doing a great job, but if we’re going to reduce the dependency on the core devs then we need more people to step up and start digging.

It doesn’t matter if you install WP or BP first.

The only thing you have to take into consideration before upgrading BP is to deactivate any other BP plugins you’re currently using:
https://codex.buddypress.org/getting-started/upgrading-from-10x/

If you’re upgrading from WPMU 2.9.2 to WP 3.0, read this guide by Pete Mall:
http://developersmind.com/2010/06/17/upgrading-wordpress-mu-2-9-2-to-wordpress-3-0/

It’s also a good idea to backup every step of the way. Before upgrading to WP 3.0, backup. Before upgrading to BP 1.2.4.1, backup.

BP 1.2.5 should be out soon which should hopefully fix these avatar problems.

“There is almost no benefit whatsoever of Friends within BuddyPress …”

Buddypress was supposed to be social networking added to blogging. Friends could form groups and work together in blogs. Friending itself is probably most relevant for internal email. The one thing you need to make that work is beefed up member management beyond default WordPress:

– full real names instead of anonymous meaningless usernames
– extendable, flexible member data fields
– ways to manage member lists
– ways to manage member roles
– ways to manage relations between members
– privacy and security controls on member data
– front-end functionality for members to manage their own profile data
– front-end functionality for members to manage their relationships
– etc.

None of these points get the attention they deserve. Again, if you have the three solid elements (1) members (“users”), (2) posts, (3) comments, all the rest is just a matter of displaying the data in different views, including forum view.

The shift in focus from blogging to the old-fashioned bbpress forum structure further derailed the project. Adding social networking to blogging should have been the main focus.

“the best setup is having either Forums or Activity.”

I use neither. I’m trying to structure my custom 1.1.3-based theme around member profiles, blogs and groups with group blogs. My activity stream just reflects what’s happening on the profiles, blogs and groups; it’s not a discussion thread in itself – I think I originally broke the ajax and had to remove reply buttons etc…

That is part of WordPress core. I suggest you disable BuddyPress; if you have the same problem, then it’s something to do with your WordPress install rather than the BuddyPress plugin. Let us know how you get on.

Yes, there is.

https://codex.buddypress.org/how-to-guides/changing-internal-configuration-settings/
Put this in your wp-config.php

define( 'BP_ENABLE_USERNAME_COMPATIBILITY_MODE', true );


@kevin
As Greg’s said; the reason is that enabling multisite loads more code which needs more memory.

@kevin,

check out this link http://wpmu.org/daily-tip-fatal-error-exhausted-memory-size-when-upgrading-to-wordpress-3-0-heres-the-fix/

@ajamison5579; We’ve had some fun with themes too, and just getting used to what exactly is WP controlled, and what’s BP controlled! (Bit of a nightmare, to be honest, but it all seems to work ok in the end).

To use a standard theme you need the BP Template Pack (at https://wordpress.org/extend/plugins/bp-template-pack/). In the end I pulled the guts out of a BP template to give us a very simple Facebook-like look (http://lincme.co.uk) If you have a peek you’ll notice that a lot of BP stuff went under the knife, as it’s way to complicated and busy looking for many people. As some have said elsewhere, this site is too.

As to your final question above; the default BP theme has all the code templates you require (of course) and you can clone it, modify the CSS info so it doesn’t clash, and hack away. Any template files you use override the default ones, so you can pull files out and just modify the bits you want to. And the CSS, of course. Have fun!

Add; To clone the BP theme, create your own folder such as wp-content/themes/my-theme, then copy all the files from wp-content/plugins/buddypress/bp-themes/bp-default into your new my-theme folder. Be sure to modify the header content of the style.css file so WP/BP recognises it as a new theme.