BuddyPress.org

UPDATE 2: I see that in 1.02 the filter is added to ‘bp_get_the_profile_field_value’, so I changed this in the line above, but still the links hang in there.

I also wanted to remove the linking in the profile fields, so I added the following line (given above by Fishbowl81) to bp-custom.php, which is in the “plugins” directory.

remove_filter( 'bp_the_profile_field_value', 'xprofile_filter_link_profile_data', 2);

The profile fields still have the links though. Is there something special I need to do aside from putting the line in bp-custom.php?

UPDATE: I believe that bp-custom.php should actually go in “mu-plugins”. Also, I did add the php script tags (<?php and ?>) around my code in this file. Still the links appear.

Hi mohitkro5,

It sounds like you’re trying to use WordPress shortcodes in Buddypress fields.

Where are you trying to embed your videos?

BuddyPress doesn’t allow WordPress shortcodes to work in profile fields, wire posts and group forum posts.

bbPress has a few plugins to parse videos.

I tried very hard to get this to work, and I can not get that code to work, even in the default template or even by creating a blank .php with pasting in the code listed above to upload to the mu-plugins directory.

First of all you should not be placing the code in mu_plugins. Either place it in your bp-custom.php file, create your own plugin that resides in /wp-content/plugins/, or put the code in your member theme’s functions.php file.

But, in the BP Profiles section, the users can simply change their login username to anything they want. This will obviously lead to database errors and people changing their usernames to cause conflicts.

Where do you see the option in BuddyPress to change your login username? The only option you have is to change your display name. This is an entirely different piece of datum.

Yes, when a user registers for a new account, if they choose to enter the exact same datum in the username field as the “Full Name” field, then that is their choice. But, this data is stored and used in different ways. The datum from the “Full Name” field gets placed in two different tables: it populates the display_name field in the wp_users table and it is recorded in the wp_bp_xprofile_data table corresponding to the meta field entitled “Full Name” in the wp_bp_xprofile_fields table.

When a user decides to edit their “Full Name” field via BuddyPress, the changes to that piece of datum have no affect on the login username field stored in the user_login field of the wp_user WordPress table.

So, on the same registration page, you have two questions requesting for what their username is going to be. This is quite ridiculous, and so far their is no way to shut that part off. Does anyone have any ideas?

This is not correct. These fields serve different purposes as detailed above. One field is the user_login, the other is the user’s display name.

The custom field values are found in wp_bp_xprofile_fields table whereas the actual datum for each field is found in wp_bp_xprofile_data table.

As far as how to output the data, this should give you some ideas: https://codex.buddypress.org/developer-docs/custom-buddypress-loops/the-profile-data-loop-bp_has_profile/

_cK_ is a tried-and-true bbPress plugin developer; not sure if she’ll step into the confines of BuddyPress! But if you don’t ask, you’ll never know!

It’s probably possible to extend Nicola’s BP-TinyMCE plugin to add a filter for profile fields as well… you’d have to bug Nicola about that.

Here’s a post which explains how someone added a filter to profile fields:

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

I might write a filter as well regarding this… we’ll see.

Thanks for that information R-A-Y.

Does anyone have any ideas how to take a BP-PRESS created profile field, and have the information placed within that BP-PRESS field automatically show up in the a posted wire or group forum post/message?

I think the real issue is that I am looking for something that will not just allow text, but html embedded images too. I mean alot of people that use signatures like to have their signature show their name, then a banner image under it. So, even using a profile field would be limited, because, it probably couldn’t allow embedding of images. I don’t think the BD-DEV’s tinymce works with profile fields in bppress at this time.

I have posted on BD-DEV’s website to see if Nicola Greco has any thoughts about this. I also posted on _CK_’s area on the bbpress showcase website to see if the plugin author of “BBPRESS Signatures” has any thoughts about converting their plugin to BP-PRESS.

I consider that the BP-PRESS Signature a very important plugin, and if this plugin ever gets created by someone, then I am positive that many of you will find it very useful for wires or group forum discussions. I mean look at PHPBB or Invision Pro Board, etc. Those forums thrive on signatures in their posts.

You can follow the current posts that I made:

On BD-DEV:

http://bp-dev.org/forums/topic/the-signature-plugin

and on _CK_’s area in the bbpress showcase website:

http://bbshowcase.org/forums/topic/bbpress-signature-convert-to-bppress

I truly hope that we will be able to see something like this type of plugin in the near future.

Thanks for everyones replys and thoughts.

Everyone is always very quick to advertise the benefits of a single-sign on service, or a go-between to allow users to sign into your website using any number of different credentials, but there are a few major flaws with this idea, and they are going to become extremely apparent very soon.

The first MAJOR flaw I see in this design, is that all it takes is one website to put up password stealing/sniffing code, and now you’ve given your twitter password to anyone with access to the sites malicious intentions.

The second MAJOR flaw I see from a developers standpoint is that you as a site administrator no longer have control over the user data that is using your website. This means tracking down a problem user that creates an account with their facebook, you ban them, their google, you ban them, their open_id, you ban them, etc… That, along with the fact that these user registrations tend to add their own cryptic names into your database fields; now you’re forced to try to know who “fb8288373” really is, when had they registered the normal way, you could see they are “johnjamesjacoby.”

From a user perspective, I don’t plan on using Facebook for the rest of my life, so when I delete my account in a few years, that means I can no longer use your site without creating a new profile.

Also, if I’m logged into facebook on my computer, and close facebook, and then my girlfriend walks over to a site and clicks on facebook connect and continue, it logs her in as me because I am still logged into facebook. Now I’ve registered at a website that I didn’t want to register at, and I have no way to delete that account, and who knows what kind of information they’ve decided to store about me by this point…

Quite frankly, I can’t wait for this trend to die. It’s a headache waiting to turn into a brain tumor in my opinion.

Thanks Boone!

Using your filter helps to delink sensitive information like first name, last name, etc.

I have one question though, let’s say I filter two fields named “First Name” and “Last Name” from search linking, and let’s say I have a user with a first name of “John” and a last name of “Smith”.

If someone uses the search term “john” or “smith” on the BP member directory page, would BP return a match for John Smith?

Hello. I’ve started to work on it since a few weeks.

It starts to be interesting.

*are things not started yet or **planed for a even more later

TYPES & CATS

-customizable types and categories, nestables

**customizable fields for posting/showing classifieds in it

MODERATION :

-decide wether or not to allow public viewers

-decide wether or classifieds needs validation before being published

-*grant a user moderator for all classifieds or by type / category

SITE VIEW

-search, explore, filter (by categories, days, **custom fields)

MEMBER VIEW

-show my published classifieds

-show my- awaiting moderation [author/moderators only]

-show my unactive

-watched : when you click a button on a classified, it will be in your profile and you’ll be notified if someone posted a on the wire or if the author modify it +*watched types & cats

-single classified : see details, author, see & post on the wire, see watchers

MEMBER OPTIONS

-*email notifications for new classifieds, classifieds by type,category

-*email for new posts on wire (watched classifieds)

-**email for new classifieds of friends

-*filters for home page

POSTING

– user needs to agree terms & conditions (only once) before posting

-fields : title, description, type, category

-****customizable fields

-****photos

-enable wire

-*enable email notifications when editing (for watchers)

…maybe i’ll start with this

I also have to say that it is a huuuge work and I’ll probably open a project page with a PAYPAL button to encourage me (need it).

I’m not a professional coder but i’m trying to do the best possible.

Today i’ve almost finished the admin part.

Proud to say that I’ve find something to dynamically (jQuery) add types/cats and edit,order (nested!!),delete,save them. It works !!!

<img src=”http://img53.imageshack.us/img53/420/classifiedssetup.jpg&#8221; alt=”classifieds setup” >

First off, I do sympathize with your frustration on finding an acceptable set of solutions to your questions. Without writing the code for you, it is difficult to point you in the proper direction. There have been a number of options presented, that while being a compromise to your ultimate, desired solution, could produce satisfactory results.

Isn’t the whole point of Buddypress to turn the WordPress base into something more user-centric?

Yes and no. As I already said two posts above:

WPMU is not designed as a user-centric platform. It is blog-centric. BuddyPress puts the focus on the user.

But, BuddyPress is still a layer that rests on top of WPMU, not the other way around. BP relies heavily on certain WPMU functions to handle much of the user registration process. And WPMU requires that the username field be populated (I realize that you know that).

This thread is NOT about the username issue.

I understand that. But what I quoted from your past post was about the username field and that is what I specifically answered in my last post.

This particular thread is entitled “How to use full name, first name + last name“. Burt already provided an answer to this question above via this thread where he shows you how to do exactly this in code.

I’ve understood all along in the various threads that you’ve started on this range of related topics that you want another option, some other way to insert your desired datum into the user_login field, or use newly created fields to allow registering users to enter their firstname and lastname, or that you want a way for users to enter their email for login, or a way to use BP’s xprofile table to display fname and lname in various ways and places, or a way to rearrange fields on the registration form, and that you hate WPMU’s concept of username and want a different option. I get all of this.

Others (including myself) have tried to be as helpful as possible in each of those threads, often rehashing the same answers. I don’t say this to be mean; I say this because we’ve tried to explain in multiple ways and multiple times that what you are after is not possible at this time without hacking the core (in some cases) or writing your own custom plugin(s).

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

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

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

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

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

How does Buddypress handle first name + last name?

It does and it doesn’t. There are no firstname and lastname fields in BuddyPress unless you create them as Mike Pratt explained above. BuddyPress has its own mandatory registration field that by default is called “Full Name”. Look in the BuddyPress submenu group in WPMU’s backend. Go to “BuddyPress > General Settings > Full Name field name”

Now, there is a function in bp-xprofile-filters.php called xprofile_sync_wp_profile() that will take the datum from the “Full Name” field and split it into a pseudo firstname and lastname and then insert that as meta data into the wp_usermeta table, but it can only do that if a user actually edits their fullname field to include a more than one-word name. So if a user does not edit that field, there will not be any fname/lname wp_usermeta entries for that user.

Buddypress puts a default first x-profile field Name on the registration form; is it possible to replace that with separate first name + last name fields?

You can change the “Full Name” field name to whatever you want but you cannot remove that field from the registration page nor edit it to be something other than a single textbox field–at least not without hacking the core. Look under the “Basic” field grouping in “BuddyPress > Profile Field Setup” to see what I mean.

Or is there already a native solution for first name + last name in WPMU that Buddypress could tap into? (Nicola Greco: ‘… you could replace it with the wp built-in name & last name, or use xprofile fields fot that …”)

In this post above, I explained that if you want to go this route, you’ll need to pull data from two records in wp_usermeta to extract the firstname, lastname combination. If you do not feel comfortable coding this yourself, you could hire a coder to write a simple function to do just that. But be aware, as I explained above, it is possible that not every user will have firstname and lastname meta date.

From your OP:

Default Buddypress is fine for teens/tweens who want to use their anonymous username, but it’s not suitable for a more grown-up business network, for example.

BuddyPress seems perfectly acceptable for business users. There are many professional, adult-based sites that are successfully attracting users to their BP sites. Mike Pratt’s site is a great example, for one.

I’ve been using my full name on this site from day one. It did not bother me that I had to use a single username when registering because I knew I had the option to fill out my full name for display purposes later. It also allowed me to brand BuddyPress.org with my unique name, creating a useful URI in the process.

In fact, the single username approach is what many sites use to allow users to brand themselves. Twitter, youtube, FriendFeed, Delicious, Digg, LinkedIn, and many more all require a unique, single-word username. Of course, some of these then allow you to (or even require) that you use an email for subsequent logins. This is in BP’s future as well.

In the not too distant future, there may be an option to allow users to sign on with their email address via OpenID or another protocol. See the BuddyPress Roadmap and read about the Open Stack.

But for now, your options are limited and if you want to change things you must code your own custom solution or hack the core.

There is not much more we can do, but as I said in my last post, if the username concept bothers you so much, you’ll have to go to the WPMU forums and see what solutions might be in the works–if any.

Ok, I fired up the debugger to see what could be the problem. Here’s what I found: The problem occurs only if you’re using a translated BP and is caused by the last line of code (bp-xprofile.php):

// Concatenate the values.

$date_value = $_POST['field_' . $group->fields[$j]->id . '_day'] . 		      $_POST['field_' . $group->fields[$j]->id . '_month'] . 						  $_POST['field_' . $group->fields[$j]->id . '_year'];



// Turn the concatenated value into a timestamp

$profile_data->value = strtotime($date_value);

strtotime() expects a date in english language (e.g. 2February2008), but in the translated BP version the month is also translated (e.g. 2Februar2008).

@emreth

To add additional profile fields, you need to navigate to the BuddyPress submenu grouping in WPMU’s backend. If BuddyPress is installed and activated, this submenu group is found at the very bottom of the menu column.

So, go to

BuddyPress > Profile Field Setup

and set up the additional fields you want.

By default, when you activate BuddyPress, all of its components are activated. To selectively disable a component, you go to

BuddyPress > Component Setup

You need to log into WPMU’s backend as site admin ( /wp-login.php), and then go to

Site Admin > Options > Allow new registrations

and set the options you want.

Also I am unable to create an extended profile like shown in some of the demos. It only allows me change the “base” and avatar. I can’t put birthday, location, etc.

To add additional profile fields, you need to navigate to the BuddyPress submenu grouping in WPMU’s backend. If BuddyPress is installed and activated, this submenu group is found at the very bottom of the menu column.

So, go to

BuddyPress > Profile Field Setup

and set up the additional fields you want.

Andy, see this ticket: https://trac.buddypress.org/ticket/803

I have filed this ticket in trac to report this bug.

This has not yet been implemented. As this thread has not seen any activity for 4 months, I would suggest searching the trac and see if it was ever added as a feature request / enhancement ticket. If not, you can add it yourself!

You login to trac using your BP.org credentials.

As a side note, the reordering of groups would need to exclude the first field group as it is the grouping of fields that appear on the signup page.

Update:

By the way, I should have provided a little more detail. Whereas I call this a bug, technically what is happening is all profile data, except URLs, are filtered to make them searchable–unless the field data has more than 5 non-comma separated words in a row (don’t ask why that limit, I don’t know).

So, if you hover your cursor over the field value, you’ll see this toward the end of the link:

?s=

This creates a search link for the keyword or phrase which when clicked on should perform a search that brings up related results. Of course, on a development site, you more than likely will not have any relevant results.

Whereas in general I like the idea of making data searchable via links (it’s sort of like tags), this implementation is flawed. At a minimum, it should not be linking the user’s “Full Name” field as the best search result for that is for the viewer to stay exactly where they currently are–on that member’s profile. Also, linking radio button groups or checkbox selections seems unnecessary. The data in these types of fields is often too specialized to be of much meaning in a search. Furthermore, the code arbitrarily excludes phrases over 5 words long. Finally, clicking on one of these links can be confusing to users as it sends them to the members homepage without explaining what is going on. Only in very large sites will any relevant results be returned.

It might be nice if there was an administrative option to not make profile fields clickable.

I have not yet figured out an appropriate patch to the filter function. But, when I do, I’ll add it to this trac ticket.

In the meantime, if you wish to simply deactivate this “feature”, you could use a remove_filter() call to disable the offending filter.

@jensenrandy-

I’ve actually just isolated the bug. Interestingly enough, bp.org (this site) also has this bug. I suppose you could call it a feature, but creating links to what seems like nothing is a bug to me. Go into your profile on this site and look for yourself.

Of course the clue was in the linking text I highlighted in my first post–but I failed to notice. I can get the profile fields to work properly by commenting out a certain filter. I’m trying to determine the proper patch. I’ll post the bug ticket number back here when I have it all figured out.