Where listing data lives in WordPress
Business Directory stores listing fields differently from GeoDirectory — there are no per-type detail tables. The content class reads:
| Concern | Storage |
|---|---|
| Base fields (name, description) | The wpbdp_listing post |
| Custom fields (address, phone, website, email, city, state, ZIP, hours, contact) | wpbdp form fields in postmeta, via wpbdp_get_form_fields() / WPBDP_Form_Field->value() |
| Categories / tags | wpbdp_category / wpbdp_tag taxonomies |
| Images | WordPress attachments (post_parent) + _wpbdp[images] + thumbnail id |
| Coordinates (our Haversine source) | Flat lat / lon postmeta |
| Coordinates (Google Maps module) | _wpbdp[googlemaps][geolocation] — a serialized object {lat, lng, field_hash} |
| Derived city/region (fallback) | _mam_bd_city / _mam_bd_region postmeta |
| Business hours | The MAM Business Hours custom field type, stored as MAM hours JSON |
Field mapping to app slots
Fields are matched to the app’s structured slots (street, city, state, ZIP, phone, website, email, hours, contact name) by field name/tag heuristics, with per-slot bd-field-{slot} admin overrides (settings page → Listing tab).
Derived location (single-address sites)
Most Business Directory sites ship one free-form Address box and no City/State fields. When a City/State field isn’t mapped, the content class and the GeoFilters contributor fall back to _mam_bd_city / _mam_bd_region, which the geocoder writes from the geocode response’s structured components on every app-side save (and the GeoDirectory converter writes from GD’s structured columns).
Coordinates and the field_hash rule
The app-side save writes both flat lat/lon (SQL-usable, our Haversine source) and the Google Maps module’s serialized geolocation object. Writes to the module object must include a valid field_hash (WPBDP__Google_Maps::field_hash()) or the module re-geocodes over them. The save handler suppresses the module’s own save-time geocoding so there is a single coordinate writer and no drift.
Per-listing keys sent to the app
Alongside the base title/description/image, each listing row carries (non-exhaustive):
id,lat,loncity_state_zip— a formatted location labelphoto_array— the gallery (suppressed on the detail screen when Hide photo scroller is on)searchIndex— text-search sourceraw_business_hours+hours_one_line— from the MAM hours JSON (both apps consumehours_one_line)claim_status+can_claim— real state when the Claim Listings module is active, placeholders otherwise- category/subcategory data, social platforms, contact fields
Mobile JSON flags
Set via mam_get_phone_data_before_send (frozen contract — do not rename):
| Key | Meaning |
|---|---|
track_views |
View tracking on |
report_favorites |
Favorites-sync UI on |
hide_remove_all_favorites |
Hides “remove all favorites” |
data_has_search_index |
Content type supports text search |
use_category_in_search_results |
Category names included in search hits |
do_not_sort_picker |
Suppress alphabetic sort on geofilter pickers |
favorites |
Array of the user’s favorited listing ids (from mam_user_favorite_posts) |
geofilter_default_name |
Default city label |
Related articles
- Business Directory content types
- Recipe: Configure the Business Directory settings page
- Business Directory integrations
Metadata
| Field | Value |
|---|---|
| Article type | JSON Key Reference |
| Plugin slug | mam-business-directory |
| Category | App Content |
| Audience | WordPress admin, PHP dev |
