Where GatherPress puts things: which post types and taxonomies it registers, which meta keys it writes, the one custom table it creates, and the REST routes it exposes.

This is a reference for reading and extending the data, not a guide to any one feature. For how to put these features on your own post types rather than GatherPress's, see post type supports.

Neither slug is load-bearing. GatherPress checks post_type_supports() rather than comparing post types, so a companion plugin's own post type gets the same behavior by declaring the same supports. Code that hardcodes gatherpress_event is code that breaks for those users.

Two are public. The rest are internal plumbing, hidden from the UI, and are prefixed with an underscore to say so.

The three RSVP taxonomies are on comments, not posts, because an RSVP is a comment. The RSVP docs cover that in full.

_gatherpress_venue is not venue-specific machinery. It is produced by the gatherpress-shadow-source support, which keeps one hidden term per published post of a given type, in lockstep with its slug and title. Any post type can declare it (productions, organizers, sponsors) and get the same event-tagging behavior. The leading underscore on a term slug (_my-venue) is what distinguishes a real shadow term from a sentinel like online-event.

gatherpress_datetime is the canonical value the editor and REST write. The events table is derived from it and is what queries read.

The two limit keys are enforced server-side on every write, including from WP-CLI. An RSVP asking for more guests than gatherpress_guest_limit allows is not rejected. It is clamped, and the caller still gets a success response.

Five keys are editor-writable, registered show_in_rest so they can be bound to blocks through core/post-meta: gatherpress_address, gatherpress_latitude, gatherpress_longitude, gatherpress_phone, gatherpress_website.

Eight more hold the structured address the geocoder derives from gatherpress_address: gatherpress_house_number, gatherpress_street, gatherpress_city, gatherpress_county, gatherpress_state, gatherpress_postcode, gatherpress_country, gatherpress_country_code. These are readable over REST but not writable. REST writes are silently stripped, because the geocode cron owns them. Write gatherpress_address and let the cron fill the rest.

Both lists exist as constants (Venue\Meta::EDITOR_WRITABLE_FIELDS and ::STRUCTURED_ADDRESS_FIELDS) and are the single source of truth. Read them rather than retyping the keys.

RSVPs are comments of type gatherpress_rsvp. Their extras live in comment meta:

Custom field answers are covered in the RSVP docs, including the schema they are validated against and how a companion plugin supplies one.

The status is not in comment meta. It is a term. Reading it with get_comment_meta() returns nothing.

Three keys, all written from the user's own profile screen and all optional:

GatherPress falls back to the site's own settings for any that are unset, so nothing needs to be seeded when a user is created.

Admin list tables also store per-user screen options under the usual {$screen}_per_page convention. That is core's mechanism, not GatherPress's, but it is user meta the plugin leaves behind, so uninstall accounts for it.

GatherPress creates exactly one table, {$wpdb->prefix}gatherpress_events, in Setup::create_tables() via dbDelta():

CREATE TABLE {$prefix}gatherpress_events (
    post_id            bigint(20) unsigned NOT NULL default '0',
    datetime_start     datetime NOT NULL default '0000-00-00 00:00:00',
    datetime_start_gmt datetime NOT NULL default '0000-00-00 00:00:00',
    datetime_end       datetime NOT NULL default '0000-00-00 00:00:00',
    datetime_end_gmt   datetime NOT NULL default '0000-00-00 00:00:00',
    timezone           varchar(255) default NULL,
    PRIMARY KEY  (post_id),
    KEY datetime_start_gmt (datetime_start_gmt),
    KEY datetime_end_gmt (datetime_end_gmt)
);

The table does not replace the meta, it serves a different job. gatherpress_datetime post meta is the canonical value: it is what the editor and the REST API write, and it is the representation that travels with the content. The table is derived from it, and exists for querying and scale.

Every event query is a date-range query: upcoming, past, between two dates, ordered by start. wp_postmeta stores values as longtext with no useful index, so a range comparison means casting every row. Indexed datetime columns turn that into a normal range scan, and keep doing so as an install grows.

The two stay in step automatically. On wp_after_insert_post, Event\Setup::set_datetimes() reads the gatherpress_datetime meta and writes the table row from it. Update the meta and the table follows; nothing has to write both by hand.

Event\Query joins the table into WP_Query through the standard SQL clause filters, so the usual query API keeps working and blocks and Query Loops behave normally. Nothing reads the table directly.

The GMT columns are what queries sort and filter on. The local columns exist for display, so a listing does not have to convert every row back.

On multisite the table is per-site: every site in the network gets its own.

Everything is under the gatherpress/v1 namespace, defined as GATHERPRESS_REST_NAMESPACE.

A few notes for anyone calling these:

• /event/rsvp-form is deliberately public. Open RSVP means a visitor who is not logged in can respond, so the permission callback lets everyone through and the validation happens inside. Treat its input as untrusted, because it is.
• /event/nonce is same-origin only, checked with Utility::is_same_origin_request(). It exists so cached front-end pages can fetch a fresh nonce; it is not a general-purpose token endpoint.
• The event routes are registered from a single array in Event\Rest_Api::get_event_routes(). Adding one means adding an entry there, not another register_rest_route() call.

GatherPress also extends core's own REST responses rather than replacing them: venue meta is exposed through register_post_meta( ..., 'show_in_rest' => true ), so the ordinary /wp/v2/gatherpress_venue endpoints already carry it.

• Post type supports: putting these features on your own post types
• RSVP system: the comment storage, statuses, providers and flags in detail
• Settings architecture: where settings are stored and how they travel
• Hook reference: every filter and action, generated from source