What it does

Adds a predefined Event Location custom field for GeoDirectory event post
types. When you add it to the event CPT’s form fields, the app’s generated
add/edit event form shows a dropdown of your published venue listings plus a
leading “No venue – enter address below” choice.

• Venue selected — the event is linked to that listing (cp_link_posts,
  the same link the wp-admin “Link Posts” field writes), and on save the event
  inherits the venue’s coordinates, address, and GD location bucket. On iOS the
  address field is hidden while a venue is selected.
• No venue selected — the address field applies; the entered address is
  saved and geocoded (with progressive fallbacks) so the event still lands on
  the map and calendar.

Editing an event pre-fills the dropdown from the linked venue, and changing the
selection re-links the event. Explicitly switching an event back to
No venue removes the link so the entered address takes over.

Setup

1. In wp-admin go to GeoDirectory → Settings → Events → Fields (the
   screenshot panel with Standard / Predefined fields).
2. In Predefined Fields, click Event Location to add it to the form,
   position it above the Address field, and save.
3. That’s it — the app’s add/edit event form picks the field up on the next
   main JSON refresh. No app update is required.

When the Event Location field is on the form, the Address field is no longer
force-required (a venue selection supplies the location instead).

Platform behavior

• iOS evaluates the field’s conditional logic: the address field is shown
  only while “No venue” is selected.
• Android doesn’t yet act on dropdown-driven conditional logic, so it shows
  both the venue dropdown and the address field. The address is labeled “Only
  used when no venue is selected above.” and the save logic makes the venue
  win when one is picked.

Hooks

• mam_gd_event_location_post_types — post types offered the Event Location
  predefined field (default ['gd_event']).
• mam_gd_event_venue_post_types — post types whose listings count as venues
  (default: every GD post type except the event types).
• mam_gd_event_venue_choices — filter the generated choice list beyond the
  built-in geofilter scoping.

Geofilter scoping

When geofilters are active (mam_geofilters_is_active / mam_use_geofilters),
the venue list is automatically radius-scoped around the request’s lat/lon —
the same coordinates and radius setting (tsl-setting-geofilter_radius,
default 10 miles) the listings pipeline uses. Users only see venues in their
selected area, so they can’t link an event to a venue their app never
displays. A request without coordinates falls back to the full venue list
rather than an empty dropdown.

How it works (under the hood)

• mam_gd_event_venue_field registers the predefined field via
  geodir_custom_fields_predefined and builds the venue choice list (post IDs
  as string values, venue titles as labels).
• The add/edit listing form generator
  (mam_gd_add_edit_listing_form_handler) emits the field as a select,
  attaches a show-when-empty conditional-logic rule to the Address field, and
  pre-fills from the listing’s venue key on edit.
• On save, the submitted value is resolved to a venue post ID (numeric IDs and
  venue titles are both accepted — the platforms differ in what they submit),
  the cp_link_posts row is upserted, and the existing venue-coordinate copy
  runs. An unresolvable value never unlinks an event; only a deliberate
  “No venue” selection on an edit does.

Verify

1. Add the field, refresh the app’s data, and open Add Event.
2. Pick a venue, save, and confirm the event card shows the venue and the event
   appears at the venue’s map location.
3. Edit the event, switch to No venue, enter a street address, save, and
   confirm the event’s map pin moves to the geocoded address.

Re-verify whenever the GD Events addon changes its custom-field handling, the
cp_link_posts table schema changes, or the app form engine’s conditional
logic changes.

Metadata