#7162 closed feature request (fixed)
xprofile field support for WordPress Profile Fields
Reported by: | DJPaul | Owned by: | imath |
---|---|---|---|
Milestone: | 8.0.0 | Priority: | strategic |
Severity: | normal | Version: | |
Component: | Extended Profile | Keywords: | has-patch has-unit-tests commit |
Cc: | lmoffereins@…, needle@… |
Description (last modified by )
WordPress has a number of unloved Profile Fields inside wp-admin user profiles, such as:
- Website
- Biographical Info
- First / Last Name
- Nickname
Let's add a special kind of xprofile field that displays this data, and saves updates back to where-ever WordPress is storing them. Let's make this work for fields added by third-party plugins or site customisations, too.
Attachments (3)
Change History (39)
#4
@
8 years ago
As always, easy ideas are never easy.
I experimented with an approach where we would not mirror data from usermeta (i.e. nothing in our xprofile_data table).
A problem I found is with bp_has_profile()
. It's hide_empty_fields_default
parameter will not return our "biography" field (for example) because we don't have a value stored for it, which means it doesn't get rendered into the template loop.
so... because adjusting the SQL would involve at least one JOIN (or a seperate query), this seems a bit sub-optimal, so it's probably going to have to be syncing WP usermeta. :o
so... we can probably overhaul xprofile_sync_wp_profile
and xprofile_sync_bp_profile
at the same time, which currently "syncs" nickname/first/last name back and forth. This hasn't been touched since v1.0.0 and it's always been a bit crappy, so it feels like time.
#5
@
8 years ago
@DJPaul Please look at my BP XProfile WP User Sync plugin. which currently works seamlessly with CiviCRM WordPress Profile Sync as well, so that First Name and Last Name propagate throughout the CiviCRM - WordPress - BuddyPress ecosystem. Please keep this thread up-to-date with your thinking and progress - there are quite a few sites that implement (most of) this already :)
#6
@
8 years ago
Leaving this here as a note for myself, going to discuss in dev chat next week: #2225
This ticket was mentioned in Slack in #buddypress by djpaul. View the logs.
8 years ago
This ticket was mentioned in Slack in #buddypress by mercime. View the logs.
8 years ago
#9
@
8 years ago
My experiment branch for this is was https://github.com/paulgibbs/buddypress/tree/xprofilewp-fields
#10
@
8 years ago
FYI: It was mentioned in the chat that bbPress does profile fields:
- An example implementation is here: https://gist.github.com/ntwb/c70caf5a0aa9d3062a6d
This ticket was mentioned in Slack in #buddypress by imath. View the logs.
4 years ago
#12
@
4 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Contributions to Under Consideration
This ticket was mentioned in Slack in #buddypress by vapvarun. View the logs.
4 years ago
#15
@
4 years ago
I think including a feature to change nicename along with first name and last name at frontend profile edit section will be a good addition and will keep info sync with WP.
#16
@
4 years ago
- Keywords has-patch needs-unit-tests added; needs-patch removed
Hi!
7162.patch is my suggestion to add this feature to BP xProfiles. I've used @DJPaul's initial work to start including the wp-biography
field type to the WordPress fields managed from the site's front-end thanks to the xProfile component.
I believe I've found a way to avoid mirroring WordPress data into the xProfile data table: in BP_XProfile_ProfileData::get_data_for_user()
if the field value is not found into the cache, there's a fallback to use an empty value to "avoid future cache misses". In this part of the code I'm checking the User Meta cache or the displayed WP User one for the user_url
(this information is stored into the $wpdb->users
table) to include the field value of the WordPress field.
Here's a screenshot about the wp-textbox
field type. This type is a bit more elaborated than the wp-biography
one as when you select it, you need to select one of the available info you want to display from the complementary metabox.
The link in this case is made using an xProfile field meta. @netweb I believe User contact methods should be included if a Plugin adds some (I haven't tested yet).
I added some specific behavior for WordPress fields, it doesn't support:
- the "require" feature (as this information is not required by WordPress)
- the custom visibility, as these fields are public (eg the description can be seen into the Author WP template)
- the "autolink" feature. If it doesn't make sense to have this feature for the
wp-biography
field, it might have more sense to have it the first name/last name. Maybe this is something we can improve later :)
To save field values I think we should use wp_update_user()
as it handles $wpdb->users
fields as well as $wpdb->usermeta
fields. To avoid running this function more than one once, I'm using the buddypress()->displayed_user
global object to keep a track of edited WordPress fields and only update fields once we're out of the edit loop.
@vapvarun About the user_nicename
field, I believe it's a sensitive case because we are using it to build the user domain. So I believe we should avoid editing it too much. I'm fine with exploring a new signup field to allow users to have a login that doesn't appear into the URL (to improve security) asking new users to define their domain but this probably needs to be discussed into another ticket.
Feedbacks welcome ❤️
This ticket was mentioned in Slack in #buddypress by imath. View the logs.
4 years ago
#18
@
4 years ago
@imath Wow - thanks for putting this patch together.
I notice that it causes significant changes in the way that the WordPress First Name & Last Name fields sync with BuddyPress. Thanks for the early heads-up. I'm going to need some time to digest what the implications are for BP XProfile WP User Sync but I'm looking forward to retiring that plugin in favour of this functionality.
#19
@
4 years ago
Thanks for your feedback @needle
Maybe we could leave the choice to users, I believe it would be easy to include a filter to let you disable the feature for users using your plugin.
#20
@
4 years ago
@imath I would rather defer to BuddyPress for this functionality - there are a number of irritating issues with the plugin (e.g. custom xProfile Fields do not persist during plugin upgrades and therefore there's a risk of data loss) so I'm looking at ways to defer to your code when BuddyPress 8 is detected - assuming this makes the cut. I'm going to look into this in more detail next week.
#21
@
4 years ago
Sure, if you find possible improvements or ways we can help you do the transitioning (hooks etc..) don't hesitate to share them ;)
This ticket was mentioned in Slack in #buddypress by imath. View the logs.
4 years ago
This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.
4 years ago
#24
@
4 years ago
7162.2.patch improves first version of the patch:
- using JavaScript to show/hide metaboxes according to whether the field type support the corresponding feature (eg: switching to wp-textbox is hiding the required, custom visibility and autolink metaboxes).
- Not restricting feature customization to WordPress Field types so that it can be used in #4747
- Introduce the new parameter
hide_field_types
for the xProfile loop to make it possible to hide a list of field types from the loop. I've added this to avoid having the WordPress fields in both regular WP Admin profile/WP Admin extended profile.
Next step is to add unit tests. Feedbacks & patch testing are always welcome!
This ticket was mentioned in Slack in #buddypress by vapvarun. View the logs.
4 years ago
#26
@
4 years ago
- Keywords has-unit-tests commit added; needs-unit-tests removed
7162.3.patch is adding unit tests and is fixing some issues I missed in previous patches. It better handles ways to get data field values.
I'm confident about committing it. So I'll start doing so tomorrow with code that will help @vapvarun to progress on #4747.
#31
@
4 years ago
- Owner set to imath
- Resolution set to fixed
- Status changed from new to closed
In 12872:
#32
@
4 years ago
@imath Sorry for not getting back to you with feedback before now.
Just letting you know that I tried the 7162.3.patch
earlier and it doesn't seem to be working for me. I added the WordPress User fields as before, but the Extended Profile screen didn't show them.
I just tried SVN trunk with the latest commits and it appears to have the same issue for me. Am I missing something?
Added the Profile Fields as above. Note, the title seems to be "Edit Ground", but that like it's a weird translation bug because I'm using English UK :)
Back end shows the fields fine.
No sign of them on my Extended Profile, nor on any other user's Extended Profile.
I'll have a dig around the code tomorrow.
#33
@
4 years ago
Hi @needle
Thanks for your feedback.
That's an expected behavior. I think we don't need to add these fields into the WP Admin/Extended profile as they can be edited from the regular WP Admin profile. It seems weird to me to be able to edit the same fields in 2 different tabs of the same page in a way. See last bullet point of this commit [12869].
If you go on front end you should be able to find the fields and edit their values ;)
I'll soon write a full developer note to explain how these new profile field types behave.
#35
@
4 years ago
That's an interesting point. Technically speaking that's not the same information. The Name field is in fact synchronized with the WP Display Name. The Display Name can be First Name + Last Name, the Last Name + the First Name, the nickname etc.. So it's ok to keep all these. What you can do is rename the "Name" field into the xProfile Admin screen by "Display Name" or "Name to Use in your profile's header".
The Name field is something we'll probably need to talk about in the future. For 8.0.0, if it's generating some confusion we can eventually rename it for something more like "Display name". But I believe this should be discussed/fixed in another ticket because we are not using these new Profile types to generate it.
Really interesting. Reminds me of the BP XProfile WP User Sync plugin.