@prefix sioc: . @prefix dc: . @prefix dcterms: . @prefix xsd: . @prefix content: . @prefix rdf: . @prefix rdfs: . a sioc:Post ; dc:title "Required details" ; dcterms:identifier 152688 ; dc:modified "2026-10-28T16:08:04Z"^^xsd:dateTime ; dc:created "2026-10-28T11:34:18Z"^^xsd:dateTime ; sioc:link ; sioc:has_creator ; sioc:has_container ; content:encoded """

Part of: LH Membership

Before someone can accept the terms and apply for membership, LH Membership checks that their required details are actually stored. Each organisation decides what is required, without code.

What counts as required

Given name and surname.
Every field marked required in the site’s onboarding xProfile group, the group chosen in the LH Membership settings. To change an organisation’s requirements, tick or untick Required on its fields under Users > Profile Fields.

How a value is found

Many field types keep their value in user meta rather than the xProfile table, so a field counts as filled if any of these has a value, checked in order:

xprofile_get_field_data(), which also covers field types that redirect it (LH Profile Page’s phone, address, gender and birthdate).
The field type’s wp_user_key, BuddyPress’s own user-meta storage for types extending BP_XProfile_Field_Type_WordPress.
User meta, or a site-specific user option, named after the field type, the convention LocalHero’s custom field types follow (e.g. lh_uet-text for Touch Experience).
The lh_membership_required_field_has_value filter, which has the final say for anything stored elsewhere, such as a taxonomy.

Where it is enforced

Required Info (Confirm Details). Saving only records the user as having confirmed their details once every required value is stored; otherwise it lists what is still missing.
The accept form. The T&Cs accept form is shown only to users who have confirmed their details and are missing nothing. Everyone else gets a link back to Required Info.
Recording consent. On the server, an acceptance from anyone still missing a detail is refused and they are redirected to Required Info, whatever page the post came from. This stops a stale or replayed page, or a direct post, from recording consent.

An administrator approving an application in wp-admin is not affected. Users who accepted before 2.97.0 with details missing are left as they are.

Hooks

lh_membership_missing_required_details ( array $missing, int $user_id ): the missing details, keyed, with readable labels. Add or remove entries to change the requirements in code, for example a club’s team choice.
lh_membership_required_field_has_value ( bool $has_value, BP_XProfile_Field $field, int $user_id ): whether a required field has a value, for storage the checks above do not cover.
lh_membership-user_consent-accept_refused ( int $user_id, array $missing ): fires when an acceptance is refused.

The check itself is LH_Membership_confirm_details_class::get_missing_required_details( $user_id ), which returns an empty array when the user is complete. (Since 2.97.0; user-meta storage since 2.97.1.)

"""^^rdf:XMLLiteral ; sioc:content """Part of: LH Membership Before someone can accept the terms and apply for membership, LH Membership checks that their required details are actually stored. Each organisation decides what is required, without code. What counts as required Given name and surname. Every field marked required in the site’s onboarding xProfile group, the group chosen in the LH Membership settings. To change an organisation’s requirements, tick or untick Required on its fields under Users > Profile Fields. How a value is found Many field types keep their value in user meta rather than the xProfile table, so a field counts as filled if any of these has a value, checked in order: xprofile_get_field_data(), which also covers field types that redirect it (LH Profile Page’s phone, address, gender and birthdate). The field type’s wp_user_key, BuddyPress’s own user-meta storage for types extending BP_XProfile_Field_Type_WordPress. User meta, or a site-specific user option, named after the field type, the convention LocalHero’s custom field types follow (e.g. lh_uet-text for Touch Experience). The lh_membership_required_field_has_value filter, which has the final say for anything stored elsewhere, such as a taxonomy. Where it is enforced Required Info (Confirm Details). Saving only records the user as having confirmed their details once every required value is stored; otherwise it lists what is still missing. The accept form. The T&Cs accept form is shown only to users who have confirmed their details and are missing nothing. Everyone else gets a link back to Required Info. Recording consent. On the server, an acceptance from anyone still missing a detail is refused and they are redirected to Required Info, whatever page the post came from. This stops a stale or replayed page, or a direct post, from recording consent. An administrator approving an application in wp-admin is not affected. Users who accepted before 2.97.0 with details missing are left as they are. Hooks lh_membership_missing_required_details ( array $missing, int $user_id ): the missing details, keyed, with readable labels. Add or remove entries to change the requirements in code, for example a club’s team choice. lh_membership_required_field_has_value ( bool $has_value, BP_XProfile_Field $field, int $user_id ): whether a required field has a value, for storage the checks above do not cover. lh_membership-user_consent-accept_refused ( int $user_id, array $missing ): fires when an acceptance is refused. The check itself is LH_Membership_confirm_details_class::get_missing_required_details( $user_id ), which returns an empty array when the user is complete. (Since 2.97.0; user-meta storage since 2.97.1.) """ ; sioc:topic . rdfs:seeAlso . rdfs:seeAlso .