BuddyPress.org

I think this capability is something important that is missing in bp groups. The concept of group and its integration with bbpress are certainly expanding the users interaction within bp groups; yet the privacy of groups discussion is not assured.

Firstly, is there a quick fix to autohide all bp groups forum from bbpress forum? I have not enabled group forum support because of this issue; and currently only using a separate install of bbpress integrated with wordpress as a place for general forum discussion. Hiding the whole forum is certainly not a totally acceptable solution especially when there are thousands of existing topics that are already there and not associated with any groups.

Secondly, what is the code to check if the logged user is a member of a group with forum id that can be done from bbpress with deep integration; this could be added in bbpress to limit access to group topics where the logged in user is not a member.

rgds

I also use the email login plugin, but generate a username from the fullname using Javascript (link is for blogname from blog title, but the principle is the same). I think that’s a cleaner solution that avoids a lot of the issues you ran into.

As for your other question, here are a few places to start:

1) Make a Gender field and a Enter the Competition field in Dashboard > BuddyPress > Profile Fields. Make sure they’re required on registration.

2) If by “top nav menu” you mean the thing that floats across the top of the screen, you can add to it by creating a button inside of a php function, then using add_action to attach the function to the bp_adminbar_menus hook. See buddypress/bp-core/bp-core-adminbar.php to see how it works in the core code.

3) Use a plugin like JJJ’s https://wordpress.org/extend/plugins/bp-member-filter/ to create the filters that will populate the pages that the “Men” and “Women” dropdowns will point to.

https://wordpress.org/extend/plugins/bp-member-filter/

The first way is for users that may have been registered before BuddyPress was installed. They can still login, post comments, and use the forums, but if they never edited their profile and set their display name(fullname), BuddyPress won’t find them.

The second is if a user edits their profile from the WordPress side (firstname, lastname, nickname) without changing their BuddyPress display name. At that point the two will be out of sync.

It’s possible to hook into the save profile action of WordPress and change the BuddyPress display name when the user changes their WordPress nickname, but some sites may want a combo of the firstname/lastname while others may want to use the nickname, and others still may not really even care or use either. From that perspective it makes sense to not have BuddyPress try to interfere too deeply with syncing profile fields that might not have a direct 1 to 1 relationship with each other.

Please, don’t cram BP full of this type of features! Leave them to third parties; basic free plugins, sophisticated paid plugins, external apps with a plugin interface, etc.

There are already so many WordPress plugins available. Why not start with adapting and extending those, instead of reinventing the wheel within BP.

Please core developers, concentrate on the core! Make sure it’s clean, solid and secure. Concentrate on APIs that make it easier for third parties to hook into BP.

Photo albums may be core to some, but not for everybody. I can think of dozens of other applications that could be core to someone; event management, mailing lists, groupware, file sharing, paid membership levels, video galleries, group video editing, chat rooms, video conferencing, shopping cart, credit card payment bridge, mobile apps, geolocation … etc.

https://wordpress.org/extend/plugins/buddypress/download/

First is a WordPress thing, latter is BuddyPress.

For the first, check out some of the suggestions at the bottom of the https://codex.wordpress.org/Nofollow page

http://www.interconnectit.com/719/migrating-a-wordpresswpmubuddypress-website/

Good luck

This is great, thanks for spreading the word about mojofiti, anyone wanting to know more, work with us, get our code, or collaborate in any way, please reach out.

haloid – I wrote a plugin for group invitations that uses the same autocomplete code as the messaging system to allow group mods to invite any member to a group: https://wordpress.org/extend/plugins/invite-anyone/. So it’s definitely possible to extend BP to do what you’re asking. I haven’t looked at the code for messaging, but if it’s anything like the invite code, it’d be pretty easy to do. A quick glance at bp-messages.php makes it look like you could probably alter BP to do what you want it to do by finding the function messages_ajax_autocomplete_results in bp-messages.php, commenting out the code that populates $friends, and replacing it with a list of all site members (you could use exactly the code I use in the Invite Anyone plugin).

Better still would be to build it into a plugin. Wouldn’t be too hard. If I get a chance in the next few weeks, I might take a look at it.

Re WP 3.0 officially

From the trenches – https://wordpress.org/support/topic/345127?replies=176

From the Lead Devs/Commiters – http://wpdevel.wordpress.com/

From Trac

– https://core.trac.wordpress.org/ticket/11644

– Core Changesets

– Core Revision Logs

No sweat, huh

If no one writes an oEmbed plugin for the BP activity stream in the first few weeks after BP 1.2 is up, I’ll take a look.

MrMaz has created BP-Links which allows for easy submitting of rich media content. It’s not possible (yet) to use it in the activity stream but he said he would look into it when BP 1.2 is released.

You can find the plugin and more info here;

https://wordpress.org/extend/plugins/buddypress-links/

It does exactly what you say; Fill in a link to youtube/flickr and it detects the video or photo. The newest version of his plugin (not out yet) allows fetching images from ANY site with images on it, so that will be even more awesome!

Killer plugin which will only get better

I don’t understand your issues with member management? WordPress MU provides excellent member management tools, and BuddyPress rides on the back of this. What is it that you need so desperately?

What is your solution to the main question of this thread? I have given my hack, but it doesn’t work for Dan Butcher.

Also if the member management tools are so great, can you answer how to display basic profile information anywhere in the theme?

My main issue with member management in BP is that there is no built-in consistent way to store firstname+lastname, as I’ve explained over and over to the annoyance of many on this forum. It makes it much more difficult to integrate third party scripts that do require firstname + lastname, like mailing list ListMessenger in my case.

Commercial membership plugins apparently create their own members table to not be stuck in WP’s built-in users management. If WP had a more solid solution that would not be necessary.

WordPress provides a decent base, but over the years bits and pieces were apparently added in different tables – nickname, display name, first name, last name, … – and BP added xprofile on top of that without synchronization with wp_usermeta. But I’m repeating myself again…

Just trying to help so you’re not completely ignored.

I’m ignored anyway.

I don’t understand your issues with member management? WordPress MU provides excellent member management tools, and BuddyPress rides on the back of this. What is it that you need so desperately?

Why not do the following (as we have) …

1. username

2. 1st name

3. last name

4. display name (the bp required field)

Because it’s not necessary. The goal should be to keep the registration form as short and simple as possible and not annoy new users.

Look at the registration process on Facebook, LinkedIn, etc. Most have:

First Name:

Last Name:

Email:

Password:

I use a javascript trick generate the username from the fullname in a hidden field – I can use email as username thanks to this plugin. Since BP has a built-in fullname field I’m stuck with splitting that out in firstname and lastname.

I have considered using fullname for firstname and creating a field_2 for lastname, but that causes all kinds of other issues.

Unfortunately there is no check/validation on what’s entered in the fullname field. The input is also not cleaned up to get capitals on the first letters and small caps on the rest. So the input could be anything, often just a first name or even ladiesman269.

Which undermines any reason of having that required fullname/display field in the first place…

All you have to do is create a function that writes the xprofile field values for 1st and Last name over to the WP table, in addition to setting the “display name value accordingly.

You have to do that straight from the registration form, to make sure that the data is there where/when you need it. That is basically what my function does. If you can get it to work. Apparently it doesn’t for Dan Butcher.

Now, with the (lame) fact that WP user table is actually different (not sure why it wasn’t co-opted for BP purposes)

That had mystified me since last Spring, but here’s Andy’s reason.

Buddypress (actually wordpress entirely) works bad on Windows. For example, windows doesnt have mod_rewrite, which is a neccesity for Buddypress.

Switch back to a LAMP environment. Or find a really good coder that wants to re-program wordpress for a Windows environment.