BuddyPress.org

@modemlooper Thank you! That did it.
get_the_author_id() as well as bbp_get_reply_author_id() seem to both work just fine.
get_post_author_id() and $bp->displayed_user->id don’t seem to work for me though.

Made some progress with this, but still need help. I figured that I could simply add something like this underneath the avatar:

However, notice the hard-coded “10” there which is an ID. This needs to be the ID of each user in the replies table and it changes with each table row inside the “loop-single-reply.php” file. I don’t mind changing the template file and keeping a record for it when upgrades come, but how do I know the ID of each user in the bbPress posting loop?

Actually I think it is impossible without modifying the core files. Any character limit or other custom validation is lost in the edit profile page, and since the $error is a local variable on xprofile_screen_edit_profile, there is no way to set it. Can you confirm that @djpaul?
I don’t know if this is planned for future releases, but I could help build a better validation code for user registration and edit profile. Adding a character limit to fields would be nice.

@djpaul thanks for the reply
I found what is going on: xprofile_check_is_required_field bypasses if user is administrator, that’s why I was able to save required fields empty.
Now I am trying to hook xprofile_check_is_required_field to a bp-custom function called check_and_validate that also checks the fields for a character limit (another very important missing security feature I pointed out on another post.) But somehow it is not working.. any ideas on how to do it?

By the way Paul, how can I submit tickets on bug tracking? I’ve been messing around with buddypress a lot lately and found a couple.

I have the fields working now. There are still some things I’m looking to resolve, but I’m making good progress.

I’m in despair for such a solution right now. So, I think it’s better to have all custom fields mandatory while members can decide whether to hide or show them in public such that they can edit any fields later if they want to. Also, re-register from front end all manually created profiles from dashboard. This is the most plausible solution to me at this time.

Thanks for your time.

thanks for taking the time looking at my problem mate. No, indeed it’s not broken but I want to have the unfilled fields present in the user profile if they want to edit it later on. Also, what do you think about users created from dashboard but still only have the name field displayed in their public profile? While this is also the only existing field which this particular user can edit?

Please hover on the 1st and 2nd user to see the difference. The 1st one was created from the dashboard “add user” while the second one had registered from the registration form. I can’t understand why those created from dashboard don’t have the custom fields in their profiles???

Here is the story Paul. I run a normal buddypress install on my website http://tinyurl.com/cuq6axy. If you go to the 2nd menu item in the main top nav (sorry it’s in French), you’ll see a list of users. The admin of the site did add a bunch of these users from the WP dashboard. But when a user is published in this section from buddypress, it doesn’t display the extra custom fields created nor does it carry the unfilled fields (for later editing) from the registration form which is here http://tinyurl.com/9aqtbez. How can I synchronize all the fields and make them appear on these users profiles or when they edit their profile they still have the fields which were not mandatory but not filled still appear?

Does this explanation makes sense to you or anyone there?

No, the custom profile fields don’t appear in the user’s profile page if they want to edit and add the extra info. That’s the issue. If I create a user from the front end, I have all the filled up fields but if created from dashboard from admin, I only have the name and this is the only field that I can see.

I’m also experimenting another issue here. When a user creates his profile and doesn’t enter info for the non mandatory fields, he doesn’t have the blank fields again in his profile if he wants to fill them later. Only the fields which are marked “required” appear (those he has filled up). How can all the custom fields be present in his profile for later editing???

A real headache right now and if you can help, this will be a real heal for my sore brain

btw, if i go to /members/username i can see their profile (with no imported fields just username and avatar )

Thanks
1. AMU is a plug-in called Add Multiple Users which https://wordpress.org/extend/plugins/add-multiple-users/ It enables a CSV import of users. [Sorry for not being clearer in the OP].

2. Users added manually – ie using the WordPress new user screen – and users Registering using the front end – work fine in BuddyPress – [both those entered before and after doing the CSV import with AMU) ie the user has a profile page and can edit it.

3. All the users imported using AMU have all fields complete including first, last, nick and display names. The only empty fields are www, jabber and AIM.

4. Users from both the CSV import and the manual user added from the Users_Add_New_Screen screen are added to a BP groups using @boonebgorges‘ Buddy Press Group Management plug in. All appear in the group member list (and all members lists) but the ones bulk entered using CSV file do not have profiles.

I’m going to try doing another import and see if I get the same result.

We actually have a pretty limited number of users, who are paired as mentees and mentors. We want each mentor/mentee to be able to select their corresponding mentee/mentor from the list to make sure the spelling is the same. We also want to show linked pairs in another section, which is another headache all to itself.

The first name and last name are stored as xprofile fields because I needed the privacy and user controls that Buddypress provides. Role is also stored as an xprofile field because we’re using our own defined roles (mentor and mentee).

Looks like I’m going to have to get deep into the SQL to do this – was just hoping there was something easy I’d missed!