Data storage architecture & hierarchy

Property Hive is built using standard WordPress data structures wherever possible. This makes it highly extensible, theme-friendly, and compatible with other plugins that rely on the WordPress data model.

This article provides a technical overview of how Property Hive stores and organises data, including its use of custom post types, post meta, taxonomies, options, and custom database tables. Developers should read this before working with hooks, custom templates, imports, or integrations.

Overview of the Data Model

At the core, Property Hive uses:

Custom post types (CPTs) for major record types such as properties, contacts, appraisals, viewings, offers, and sales.

Post meta for most structured fields.

Taxonomies for classification such as property types, availabilities, parking, locations and more.

WordPress options for plugin-wide settings.

Custom tables where necessary.

This model allows developers to use familiar WP_Query patterns, template hierarchy, and meta APIs while also extending the system via hooks.

Custom Post Types

Property Hive introduces several CPTs. The exact list may vary depending on which add-ons are enabled, but the core plugin typically includes:

Properties (property)

This is the most important CPT. A property record contains:

  • Address information
  • Department (i.e. sales, lettings or commercial) specific information
  • Descriptions
  • Media (photos, EPCs, floorplans)
  • Marketing information
  • Branch/office association

Properties are displayed on the front-end using the archive-property.php and single-property.php templates unless overridden.

Contacts (contact)

A contact represents:

  • Applicants
  • Owners (i.e. vendors)
  • Landlords
  • Potential owners and landlords (i.e. owners and landlords getting an appraisal/valuation)

A single contact can have multiple roles internally (e.g. both an applicant and a landlord). Contacts link to properties through related CPTs like enquiries, viewings, offers, and sales.

Other CPTs (Depending on Features Used)

These CPTs support CRM-style functionality:

  • Offices (office) - branch information including contact details
  • Appraisals (appraisal) – valuation or market appraisal records
  • Viewings (viewing) – booked viewings, attendees, outcomes
  • Offers (offer) – offers made on properties, including financials and negotiation notes
  • Sales (sale) – progression of accepted offers through to completion

Each CPT has its own meta structure covered below.

Post Meta Storage

Most structured data in Property Hive is stored as post meta using the standard WordPress postmeta table.

Examples of post meta stored on a property include:

_price, _rent, _bedrooms, _bathrooms, _reception_rooms, _address_street, _address_two, _address_postcode, _featured  

Developer Notes

You can retrieve meta as normal using:

get_post_meta( $postid, '_meta_key', true );

When editing frontend property templates a global $property object will also be available for an easier way to obtain this post meta, as well as helper functions such as getting the price or address but pre-formatted. For example:

echo $property->bedrooms;

or

echo $property->get_formatted_price();

To register additional fields you can use our free Template Assistant add on.

Taxonomies

Property Hive uses taxonomies to categorise and filter properties. This enables:

  • Efficient front-end filtering
  • Simple management from the WordPress dashboard
  • Consistent structure across imports and feeds

All the custom fields found under 'Property Hive > Settings > Custom Fields' are stored as taxonomies. This includes:

  • Availability
  • Property Type
  • Location
  • Parking
  • and more

WordPress Options

Global configuration values are stored using the WordPress options table.

These include settings such as:

  • Default department
  • Display settings
  • Front-end behaviour (sorting, pagination, map settings)
  • API keys (e.g. Google Maps)

Options are accessed using WordPress functions like get_option().

Custom Database Tables

Property Hive generally avoids custom tables to remain WordPress-native, but certain features and add-ons create them where appropriate–for example:

  • Email log/queue
  • Property import and export logs
  • Other add ons may create tables as needed for performance or compatibility