xprofile field support for WordPress Profile Fields

[DJPaul]

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.

[Offereins]

Really interesting. Reminds me of the ​BP XProfile WP User Sync plugin.

[DJPaul]

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.

[needle]

@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 :)

[DJPaul]

Leaving this here as a note for myself, going to discuss in dev chat next week: #2225

[DJPaul]

My experiment branch for this is was ​https://github.com/paulgibbs/buddypress/tree/xprofilewp-fields

[netweb]

FYI: It was mentioned in the ​chat that bbPress does profile fields:

• It does so using ​https://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

• An example implementation is here: ​https://gist.github.com/ntwb/c70caf5a0aa9d3062a6d

[vapvarun]

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.

[imath]

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 ❤️

[needle]

@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.

[imath]

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.

[needle]

@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.

[imath]

Sure, if you find possible improvements or ways we can help you do the transitioning (hooks etc..) don't hesitate to share them ;)

[imath]

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!

[imath]

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.

[imath]

In 12868:

Field Types can now declare supported features & field visibility

• Edit the JavaScript file used by the xProfile Create field Administration screen to handle Field types requirements by showing/hiding screen metaboxes according to feature supports and to get ride of some jQuery deprecated methods.
• Improve the xProfile Field API to take in account xProfile Field Types declared feature supports by adding two new methods to get (BP_XProfile_Field->get_field_type_supports()) & check (BP_XProfile_Field->field_type_supports( $feature_name )) the field type supported features.
• The xProfile Create field Administration Screen Metaboxes displayed to set the field properties can now be disabled by the Field Type using the static variable $supported_features. See tests/phpunit/assets/bptest-xprofile-field-type.php for an example of use.
• Improve the xProfile Field API to take in account the xProfile Field Types visibility property to use as default field visibility. NB: setting this Field Type visibility and its allow_custom_visibility feature support to false, a Field Type can now enforce the visibility to use for a field.
• Introduce a new xProfile Fields loop argument $hide_field_types to avoid displaying fields according to an array of Field types. To customize this new argument you can use the bp_before_has_profile_parse_args filter for existing xProfile loop. For instance you can avoid to list xProfile fields according to their type from the WP-Admin/Extended profile screen checking the corresponding Administration Screen ID.
• Add PHP unit tests to verify these improvements are working the right way.

Props DJPaul, Offereins, needle, netweb, vapvarun

See #7162

[imath]

In 12869:

Prepare the xProfile component to handle the WordPress field types

• Add a cache group to cache usermeta IDs by user IDs to avoid requesting information more than necessary when it hasn't been updated.
• Edit the Profile field sanitization filter bp_xprofile_escape_field_data so that WordPress fields are escaped the way WordPress does.
• Add the two new Field types wp-biography & wp-textbox to the available ones. See bp_xprofile_get_field_types().
• Introduce the bp_xprofile_get_field_type() function to get the fied type of a field thanks to its ID.
• Introduce a new filter bp_xprofile_set_field_data_pre_save. This filter returns false by default. You can use it to avoid using the Profile data DB table to save a field value by returning a WP_Error object or true. This filter is used by the WordPress field types to avoid duplicating the corresponding usermeta values into the Profile data DB table.
• Introduce the bp_xprofile_get_wp_user_keys() function to inform about the supported WordPress fields (first_name, last_name, user_url, description and potential WP contact methods).
• Edit the BP_XProfile_ProfileData methods to fetch field data so that they now try to fetch data within the usermeta table if the xProfile field has a WordPress field type.
• Deprecate the BP_XProfile_ProfileData::get_value_byfieldname() as it's no more used into BP Core code.
• Edit the function used to output the fields into the WP Admin/Extended profile screen so that WordPress fields are ignored as they can be updated from the WP Admin regular profile.

Props DJPaul, Offereins, needle, netweb, vapvarun

See #7162

[imath]

In 12870:

Introduce the base class for WordPress xProfile fields.

BP_XProfile_Field_Type_WordPress uses [12868] improvements to specify the features & visibility the wp-biography and wp-textbox fields support. It hooks to bp_xprofile_set_field_data_pre_save introduced in [12869] to handle field values persistency. It also handles fetching field values during a profile loop and caching these field values for a latter use.

Props DJPaul, Offereins, needle, netweb, vapvarun

See #7162

[imath]

In 12871:

Introduce the wp-textbox xProfile field type's class.

BP_XProfile_Field_Type_WordPress_Textbox deals with the following WordPress usermeta keys, as a text input is used to fill their values:

• first_name,
• last_name,
• user_url,
• and potential WP contact methods.

It contains a specific metabox callback to let Admins select the WordPress usermeta key the field will specifically deal with.

Props DJPaul, Offereins, needle, netweb, vapvarun

See #7162

[imath]

In 12872:

Add the wp-biography xProfile field type's class & unit tests

• BP_XProfile_Field_Type_WordPress_Biography deals with users description (Biographical information) as a textarea is used to fill its value.
• The PHP Unit tests suite now includes 5 more tests about updating/getting WordPress xProfile fields.

Props DJPaul, Offereins, needle, netweb, vapvarun

Fixes #7162

[needle]

@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.

[imath]

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.

[needle]

@imath Okay, that makes sense. But then wouldn't it make sense that only the "First Name" and "Last Name" fields appear on the front-end "Edit Profile" screen? I get all of them:

[imath]

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.

[needle]

For 8.0.0, if it's generating some confusion we can eventually rename it for something more like "Display name"

@imath I think this is a good idea.

Thanks for all your work on this feature - it's going to be a great improvement.