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 type | Purpose | Visibility |
|---|---|---|
lh-crm-form | Contact form configuration | Not public; admin UI and REST |
lh_crm_enquiry_post | One enquiry per submission | Registered 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_type | Form 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.
| Status | Label |
|---|---|
lh_crm-new_enq | New (every enquiry starts here) |
lh_crm-prog_enq | In Progress |
lh_crm-pending_enq | Pending |
lh_crm-res_enq | Resolved |
lh_crm-clos_enq | Closed |
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).
| Meta key | Type | Description |
|---|---|---|
_lh_crm-fe_full_name-hide | string | 1 hides the name field |
_lh_crm-fe_message-hide | string | 1 hides the message field |
_lh_crm-form_submit_button | string | Submit button label |
_lh_crm-field_group | integer | BuddyPress xProfile field group ID |
_lh_crm-default_category | integer | Default lh_crm-category term ID |
_lh_crm-recipient_id | integer | User who owns the form’s enquiries (required to publish) |
_lh_crm-group_id | integer | BuddyPress group ID |
_lh_crm-group_action | string | add_to_group, email_invite or silent_invite |
_lh_crm-bp_notification_recipients | array | User IDs for BuddyPress notifications |
_lh_crm-notification_id | integer | bp-email post used as the auto-reply |
_lh_crm-response_id | integer | Form Response post shown after submission |
| Meta key | Description |
|---|---|
_lh_crm-reference | Random reference generated in the browser; a resubmission with the same reference returns the existing enquiry |
_lh_crm-page_id | Page the form was submitted from |
_lh_crm-referrer | Browser referrer at submission time |
_lh_crm-enquiry_notes | Staff notes (exposed in REST, edit context only) |
_lh_crm-status-{status}-at | UTC 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_agent | Browser user agent at submission (bundled library, max 1000 characters) |
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.blogs, action lh_crm-bp_notification-action, with the site ID as item_id and the enquiry ID as secondary_item_id.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.edit_enquiries capability to every role with edit_others_pages. Nothing currently checks that capability.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.