BuddyPress.org

@grosbouff For the purpose of your plugin, bp_profile_group_has_fields gets in the way. The purpose of bp_profile_group_has_fields in the default theme, is that it will skip over any group of fields that have no values filled in when inside the profile loop.

I think what you want to use is bp_field_has_data().

I also don’t think that this is a bug. All of those functions are doing exactly what is expected.

Can you explain in more detail what you need these functions to do?

Without a lot of custom coding, I don’t think you’re going to be able to make this work with xprofile fields. Those fields can only store data when they have been defined in the wp_bp_xprofile_fields table, but if they’re dynamically generated, that’ll be hard to do. It might be more straightforward to save the data as usermeta.

I guess I’m assuming that you want to save the field data in the bp database tables. Or are you just hoping to display the checkboxes on the profile page, and have them handled by another script?

In either case, as long as you can add fields to the profile page (which you could do either by hardcoding or hooking to the edit screen at bp_after_profile_field_content), you should be able to grab the $_POST data after xprofile edits are saved (at xprofile_screen_edit_profile) and then do whatever you want with it.

I would like to know as well.

@stwc and everyone else.

I’ve been experiencing problems with spammers constantly, I would get about 11 a day, (at the minimum). I’ve tried several things, reCaptcha, email activation, email domain blocking, etc etc and nothing seemed to help with the bot spammers.

All they were doing was creating users with a few profile fields filled out, so there was no big issue, it was just annoying seeing so many fake users on the site.

So all I did out of the suggestions here was enter the code provided for the .htaccess file :

# BEGIN ANTISPAMBLOG REGISTRATION
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .yourbpsignupslug*
RewriteCond %{HTTP_REFERER} !.*yourhomedomain.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://die-spammers.com/ [R=301,L]
# END ANTISPAMBLOG REGISTRATION

And it seemed to have worked. For the signup slug, I used wp-signup.php. And so far, for about a day and a half now I’ve only found 1 bot spammer. Drastically reduced, but not quite fixed.

But we’ll see. I’ll post back if there is any change, or after a few days of no spammers.

I was also having this problem in clean installs of WP 2.9.2 + BP 1.2.3. I finally tracked the cause down to this: https://trac.buddypress.org/changeset/2882/trunk. Basically there’s a defect in the script that inserts the initial row into the xprofile fields table (wp_bp_xprofile_fields). A workaround (if you have SQL access) is to run these 2 statements:

ALTER TABLE wp_bp_xprofile_fields modify order_by varchar(15) not null default ”;
INSERT INTO wp_bp_xprofile_fields (id, group_id, parent_id, type, name, description, is_required, can_delete)
VALUES (1, 1, 0, ‘textbox’, ‘Name’, ”, 1, 0);

After I executed those statements, it shows my group members.
Note that the changeset also added a default for order_by, so I’m guessing that caused problems as well.

If you need a sidebar widget in author’s blog then you could use
https://wordpress.org/extend/plugins/bp-profile-widget-for-blogs/

I just talked things over with Andrea; I’ll be releasing a plugin shortly with the code snippets posted above.
I’ll add private message username overrides as well. Is there any other place where display names are used?

However, I do see some benefit with leaving the “Name” field on the registration page. The name gets displayed on a BP profile – eg. http://testbp.org/members/andy/profile/.

Also Twitter does something similar; they add the “Name” field to the sidebar of each profile.

FYI, first name, last name and nickname fields are not added to the registration page unless you manually created them as xprofile fields. Look at testbp.org’s registration page for an example: http://testbp.org/accounts/

OK, monster essay ahoy. This is a big part of why I think ‘forums’ are an important component of the overall experience, no matter what we call them.

Here’s the meat from a couple of comments I made before on this subject, here on this very forum:

I think web community, more perhaps for people who are not so much of the disposable, in-the-moment, ritalin-riddled, post-it-and-forget it generation, needs to have feet solidly planted in not only the ongoing ephemeral stream of conversation, but also in a more long-term, permanent ’space’ of shared history, shared interactions that are performed in public and can be gone back to, interactions that more than any set of xprofile fields or avatars build a mutual understanding between users based on personality and past discussion. Build, in other words, community.

and here’s another:

Different users use sites in different ways, of course, and the Activity stream is certainly one user story that shouldn’t be ignored. But, as I’ve said so many times before over the past almost-a-year, forums, in one sense or another, have a sense of permanency for users, a ‘virtual place’ they can return to, and I believe should be the anchor of a site like this and many others, where the ongoing stream of activity and making-friends for superfans and power users is less important than information being discoverable and discussion interactions being aggregated rather than just fading away. I am growing more disenchanted with the apparent lack of attention being paid to what I believe for many is essential for a successful community site — a featureful forum setup that is the steady beating heart of the swirl of activity.

Yes, I know the bbPress option is suboptimal as a solution, but it’s what we have to work with, and it can’t be ignored or passed off to bbpress.org, because we’re not running bbPress, we’re running an interface free, bbPress-plugin-incompatible fork of it, in essence if not reality, and I really do believe that more attention needs to be paid to the limitations of it as a component of BP and ways to make it work for community-building and user satisfaction.

Anyway, back to Activity. On true social network sites (whatever that means, exactly), it makes some sense that things are ephemeral, that interactions disappear beneath the fold, because, hey, it’s all about interacting with people, socially.

But the focus of this site (and most sites I might consider building with BP) is not just making friends and having a grand old social time. It’s sharing information, asking questions, discussing solutions, offering and asking for assistance, and it’s important that the interface those interactions be structured discoverable for people who are going to have the same questions in future as BP adoption grows, and the toolset for creating them be rich, both from the administration and user-facing perspectives.

How many times do we see the same questions being asked, basic or otherwise? To answer my own question, a lot. That’s just human nature in part, certainly, but it’s also, I think, because the tools we have for using these forums are vestigial, and people just don’t have the information they need at their fingertips. User confusion and frustration will kill a community faster than goatse images. We’re all so used to using this app that I think we lose sight of just how daunting it is for new users. The site I’m building for an existing community on a different platform has taught me that, very quickly.
—

Some sites, some userbases NEED structure for conversation. This site we’re on right now is an example, as I outlined above.

Now the irony here is I was able to go back and find those comments (having to use Google because the BP site search didn’t work, I note) because they were made as parts of conversations in a permanent, permalinked — forum-style — framework.

Consider a possible taxonomy of user activity and interactions on websites (a huge project, of course — I’m just trying for a sketch here).

At the bottom the very bottom would be simple records of activity.

Next higher would be Facebook-y pokes and friend-button mashings and things like that — non-verbal pings, basically, but deliberate.

Next up would be status broadcasts — Tweets, or personal activity updates here. Verbal, but basically free-floating.

Next would be comments on other people’s activity or posts or pictures or whatever. Comments ‘on’ something, in other words — focused activity, verbal, but let’s call it transitive, in the sense that there is an ‘object’ being commented on.

Next would be discussions, like the one we’re having here. Threaded or unthreaded, paginated or not, they are multi-person, ongoing interactions about a subject or subjects. This is the kind of interaction we think of as occurring in forums structures, mostly, although that term is used to describe a wide range of structure.

Now I want you to notice that there’s a leap in cognition, in interaction, in format, and in permanency in that last step. It’s a step up to actual discussion rather than commenting ‘on’ things, it’s a step up to engaging with multiple people, it’s a step up to threads (and possibly threaded conversation, but that’s a implementation detail) and pages, and most importantly, it’s a permanent interaction for the first time as we climb the ladder of the hierarchy.

A ‘forum’ discussion is something people will return to, to add to, or just to re-read, to get information from, to learn more about the people involved or the subject being discussed. It is part of the fabric of community because it is permanent. It is the bedrock of virtual permanency, to coin a phrase.

‘Social’ networking, people seem to forget, is about people. And it’s through the history of interactions in structured discussions that we learn about other people in a web community and decide if we want to be ‘social’ with them or not. This structured, searchable, historical record of activity and interaction is utterly essential for building real community. That’s forums.

Just to finish off the taxonomy, I’d say the top of the ladder would be blog posts, at least if they are ‘written’ things intended to be read by others and then possibly responded to. Notice that they are, in a way, the flipside, functionally, of the reply-to activity, being the mover rather than the response.

Now this is getting ridiculously long, but I don’t believe in ignoring honest questions even from people who insult me, so let me just wrap it up (and there’s more to say, but I have things to do) with this:

Where else other than a forum would I be able to write a longform comment about a complicated subject, as part of an ongoing discussion? We don’t have to call it a forum if we don’t want, but this STRUCTURE, this type of format, is the only one available to us, even at a conceptual level. It’s not something we can omit across the board. I suggested earlier, and I stand by my suggestion, that it’s ridiculous to suggest such a thing.

The forum style of community member interaction is an integral part of the hierarchy of ways that users will interact online, a way that they expect to be able to interact, and a way that is entirely reasonable for them to expect. It is not only useful for some functions (such as user-to-user support here at buddypress.org, or sharing information (ie code and tips and stuff in the case of bp.org)) that many if not all sites will be providing, it is the organic way that ongoing web community builds a foundation, that users come to know one another, and as such is the essential key for true ‘social networking’ among people who do not already know one another.

I reckon.

I’m researching the same thing. Found this thread on the topic as well:
https://buddypress.org/community/groups/creating-extending/forum/topic/profile-field-setup-for-groups/

No easy solution so far, but an outdated plugin has turned up.

I’m interested in doing this as well. Would love to be able to add additional fields to a Group Profile besides the default “Group Name,” “Group Description”. A tool like the Dashboard > BuddyPress> Profile Field Setup would be awesome. I’m guessing the only solution would be to edit the current group admin form that handles this and the group template page.

My 2 cents: In my custom theme I try to consolidate everything around blogs and groups. I’m still on 1.1.3.

Blogs are of course WordPress strength. I’m trying to get to a social network with a greater emphasis on content, where possible via RSS and with front-end posting on blogs and groups to lower the threshold.

For the social networking aspect I need profile pages for members and some ways for members to interact with eachother, via internal mail, friending/following, joining eachothers groups and blogs.

Groups are Buddypress’ killer app imho. Buddypress has the potential to become a real collaboration platform around content, with endless real world applications in businesses, organizations and associations.

Buddypress has all the basic elements to achieve this, but the following are still huge annoyances and don’t look like they will be fixed any time soon:

– Member management is all over the place, in different pages under wp-admin, different database tables and different places on the front-end. Adding custom member data fields and integrating them with outside applications is complicated and inflexible. By design (!) there is no built-in way to reliably store separate firstname and lastname, which makes out-of-the-box BP useless for most businesses and organizations. There is little validation on sign-up form fields.

– No built-in privacy/security.

– Built-in forums are increasingly clashing with commenting on blogs and wires and the social networking structure. There is no reason to have old-fashioned forums in a next generation social network. You might as well integrate a WELL-style bulletin board system. Having a single sign-in option for people who want to use a forum on the side is great, but please stop weaving forums into Buddypress.

What Buddypress needs imho:

1. Consolidated member management; all member data stored in one place in the database, one page in wp-admin, one member profile page with “edit account settings” on the front end.

2. Content-focused member profile pages. Members should be able to use their profiles to introduce themselves and showcase their blogs and groups.

3. Conversation around blog posts and (threaded) blog comments, ideally with front-end posting like P2. There is no reason to have blog posts AND forum topics AND wire or whatever it’s called. Group blog should be a built-in feature.

4. End-user-friendly control over their groups and blogs, including privacy/security and front-end admin.

Summary:

– Members
– Blog posts
– Threaded comments

Presented in:

– Profile pages
– Blogs
– Groups

Just try one condition… one xprofile field, and see if it works.
Also make sure all the xprofile fields you’re checking are blank.

It’s working fine for me.

OT: You’re using BP 1.1.3?