LH CRM creates no custom database tables. All data lives in each site’s standard posts, postmeta, terms and term_relationships tables, plus BuddyPress’s own tables. Uninstalling the plugin deletes nothing: uninstall.php only contains a commented-out purge.

Post types

Post typePurposeVisibility
lh-crm-formContact form configurationNot public; admin UI and REST
lh_crm_enquiry_postOne enquiry per submissionRegistered public with rewrite slug enquiry and archive enquiries, but its statuses are only public to users with edit_others_posts. Excluded from sitemaps and several LH SEO and listing plugins.
lh_frpt-post_typeForm Response templates (bundled library)Public; REST

An enquiry post stores the enquirer as post_author, its form as post_parent, the message as post_content (tag-stripped copy in post_excerpt), and an HTML-stripped “X enquired via Page on Site” string as post_title. Its post_name is set to its own ID.

Enquiry statuses

StatusLabel
lh_crm-new_enqNew (every enquiry starts here)
lh_crm-prog_enqIn Progress
lh_crm-pending_enqPending
lh_crm-res_enqResolved
lh_crm-clos_enqClosed

A New enquiry dated in the future is switched to core future status and returned to New by cron when its date arrives (see Cron jobs).

Contact form meta

Meta keyTypeDescription
_lh_crm-fe_full_name-hidestring1 hides the name field
_lh_crm-fe_message-hidestring1 hides the message field
_lh_crm-form_submit_buttonstringSubmit button label
_lh_crm-field_groupintegerBuddyPress xProfile field group ID
_lh_crm-default_categoryintegerDefault lh_crm-category term ID
_lh_crm-recipient_idintegerUser who owns the form’s enquiries (required to publish)
_lh_crm-group_idintegerBuddyPress group ID
_lh_crm-group_actionstringadd_to_group, email_invite or silent_invite
_lh_crm-bp_notification_recipientsarrayUser IDs for BuddyPress notifications
_lh_crm-notification_idintegerbp-email post used as the auto-reply
_lh_crm-response_idintegerForm Response post shown after submission

Enquiry meta

Meta keyDescription
_lh_crm-referenceRandom reference generated in the browser; a resubmission with the same reference returns the existing enquiry
_lh_crm-page_idPage the form was submitted from
_lh_crm-referrerBrowser referrer at submission time
_lh_crm-enquiry_notesStaff notes (exposed in REST, edit context only)
_lh_crm-status-{status}-atUTC time of the most recent move into each status. {status} is the full status name, so the real keys look like _lh_crm-status-lh_crm-new_enq-at.
_lh_post_user_agent-user_agentBrowser user agent at submission (bundled library, max 1000 characters)

Taxonomies

  • lh_crm-category: hierarchical enquiry category, one term per enquiry in the admin UI. It is registered with show_ui off, so there is no wp-admin screen for managing its terms; they are available through REST.
  • lh_post_ip_tax-ip (bundled library): the submitter’s IP address as a term (dots become hyphens in the slug). Terms can only be managed by users with update_plugins.

Users and BuddyPress data

  • Every enquirer is a WordPress user, matched or created by email. Submitted profile fields are saved as xProfile data on that user.
  • Group actions create normal BuddyPress memberships or invitations.
  • BuddyPress notifications use component blogs, action lh_crm-bp_notification-action, with the site ID as item_id and the enquiry ID as secondary_item_id.
  • LH CRM does not create BuddyPress activity items. The lh_crm-enquiry activity type is legacy, and no items of that type remain on the network. Until 1.5.15 an activity class still filtered every BuddyPress activity query for it; that class was removed. LH_Crm_plugin::return_activity_type() still returns the type name.
  • The initial cron run grants an edit_enquiries capability to every role with edit_others_pages. Nothing currently checks that capability.

Relationship triples (removed in 1.5.8)

Until 1.5.8, each enquiry was also written to the LH Relationships triple store as as:actor (the enquirer), as:target (the form), as:to (the form’s recipient) and schema:about (the page it was sent from), all with source lh_crm. Nothing read them, and an hourly resync kept re-inserting the same triples, so the integration was removed. Rows written before 1.5.8 remain in the triple store until they are cleaned up separately.