WordPress posts and custom fields

Use a WordPress-backed Collection when your map should display posts or a custom post type already maintained in WordPress.

Connect the source

Open Database → Collections and create a WordPress post-type Collection using the available source choice.
Select the intended post type.
Review the returned fields, including post properties and available metadata.
Create a Query for the Collection.
Select that Query in the App Page’s Objects binding.

Do not copy posts into a local Objects table merely to make them visible in the editor. Keep WordPress as the source when WordPress owns the content.

Location and region links

Configure the source’s supported Location metadata to show post markers. The WordPress post editor’s MapSVG Location integration follows the selected map and its data source. Publish the relevant WordPress content and make sure the frontend visitor has permission to see it.

A post can also be associated with Regions. Use region links when a post belongs to a state or district but does not need an independent marker.

Regions themselves still cannot have Location fields. For a region-based design, connect posts to Regions and use the linked Object data.

Use custom fields

Nested post metadata can be available to field pickers and templates. Select an offered field rather than guessing its path. Where a custom path is supported, use the actual returned structure, such as post.meta.myField.

A Region Data rule can use a nested Region or linked Object field. Check whether your selected source is Regions or Objects before entering a path; the prefix determines where the rule reads data.

Verify public output

Test a published post with known metadata and a valid Location/region relation. Open the App’s frontend page while logged out. Private, draft, or otherwise restricted posts should not become public just because an administrator can see them in the editor.

If fields are missing, inspect the Query’s result fields and source schema before changing the template.