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.
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).wp_user_key, BuddyPress’s own user-meta storage for types extending BP_XProfile_Field_Type_WordPress.lh_uet-text for Touch Experience).lh_membership_required_field_has_value filter, which has the final say for anything stored elsewhere, such as a taxonomy.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.
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.)