BuddyPress.org

If your blog is at wordpress.COM you can’t install plugins. – I didn’t know that. This notice: http://en.support.wordpress.com/plugins/

Just a note to say you don’t have to be a coder to participate in dev chats. Want a say? hop into the dev chat, that’s the place to hammer out things like where the development is headed.

And the main devs need a break too. Often, they were plowing through trac & dev and the forums here faster and more often than the main dev of wordpress. Slowing down does not mean dying. It means they get tired. Tired devs make mistakes. they also have a big job – half the users want faster dev, the other half doesn’t. Vocal people want this change, two months later, more vocal people want the last change ripped out. See the problem there?

Do you want the devs to dev or just get pulled all over by lots of forum threads?

So. Without trying to speak for Andy or JJ or channel Jane too much, grabbing a shovel means get dirty. And like I said at the start, there’s more to do than just code. Want to influence development? Show up at the dev chat. Hammer out the details for what’s next (baby steps). Roll up your sleeves. Give them a chance to breathe and think long term beyond putting out fires.

non-code ways to help:
– post tutorials in the main blog or your own
– help new users
– if you’re answering the same things all the time here in the forum, write it up in a codex page. Point people to that.
– test plugins
– submit trac ticket or comment on exisiting ones, even to say “yeah it broke for me too” or “I can’t reproduce this”
– say thanks

Also, it’s nice outside. Play a round of golf, cuddle a puppy. There is actually more to life than code.
(and yes, I make living from this code – my mortage depends on it. )

Much love for all,
me

If your blog is at wordpress.COM you can’t install plugins.

Hi, welcome to BuddyPress.

BuddyPress is a WordPress plugin and available for download within your WP admin panel. Within plugins, click on “add new” and search for buddypress. You can install it from there.

BuddyPress Documentation: https://codex.buddypress.org/home/

Also, there are a few things to be aware of – depending upon the version of WordPress and Hosting. For example, in your .htaccess, you may need to increase the amount of memory alloted to php.

A few steps and cautions
1. Make sure you have the database and files backed up.
2. If possible, practice on a local site or developer site before you try this on your live site.
3. Deactivate your other plugins first.
4. Check your permalink structure
5. Download and activate the buddypress plugin.
6. A new panel should appear in your WP-admin panel
7. Activate the default buddypress theme.
8. Activate forums (if you are interested)
9. Test your site
10. Activate one plugin at a time – and verify the site after each activation

Come here and find extensions – ask questions – etc

@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.