The Map View
A browse view can offer a Map alongside its list, showing the same results as pins.
Where to find it
Architect Panel → Layout & Pages:
- Browse Views — the builder — enable the map, choose a provider, write the pin template
Architect Panel → Integration & Connections:
- Postcode Lookup — the coordinates the pins use
Architect Panel → Security:
- Cookie Consent — the consent both providers require
It needs a location, not a distance
The map draws whatever the view returns, so a visitor need not have entered a postcode. Sorting and the radius filter are optional companions rather than prerequisites — but the view still needs a location field configured, because pins need coordinates.
Two providers
- OpenStreetMap, drawn with Leaflet, which is served from your own installation.
- Google Maps, which is already loaded for address autocomplete so there is nothing extra to install.
Each view can choose, or leave it blank to follow the installation-wide default. Setting it per view is useful when one catalogue is public-facing and another internal.
Choosing between them
OpenStreetMap avoids sending your visitors to a third party and has no usage billing. Google looks more familiar to most people and has better coverage of business detail. For a public directory the first is usually the better default; for an internal tool the difference rarely matters.
Both require cookie consent
This is the part to plan for rather than discover. Both providers are registered with the consent manager under preferences, so on a consent-enabled page the map is blocked until the visitor accepts.
That is correct behaviour and it has a visible consequence: a visitor who declines preferences cookies must get a click-to-load placeholder explaining why the map is not there, rather than an empty grey box. An unexplained blank area reads as a broken page, and they will not know that accepting would fix it.
Check this deliberately — decline the cookies yourself and look at the page.
The pin popup
Pins use their own template, falling back to the list card template when you have not written one. Write one: a card designed for a list is usually too big for a popup, and the useful content differs — a name, an address and a link is normally enough.
Markers are capped
Worth understanding, because it is visible on the map in a way it is not in a list. A browse view returns the whole table and the front end trims it, so an unbounded catalogue would put every record on the map at once.
The map draws the nearest set and reports how many were not shown. If that number is large, the answer is a filter or a radius rather than a bigger map — a map with two thousand pins is not more informative than one with fifty.
Records without coordinates do not appear
Unavoidably — there is nowhere to put them. That makes the map a good way to spot data quality problems: a catalogue that looks complete as a list and sparse as a map is telling you about its postcodes.
Test both providers if you offer both
They are different implementations behind one interface, and the ways they fail differ — a missing key, a blocked tile server, a consent state. If your installation uses both across different views, check both.
Worked example
A directory enables the map with OpenStreetMap and a short pin template showing the name, town and a link. Declining preferences cookies shows a click-to-load panel explaining that the map needs them. Switching a second, internal view to Google is a per-view setting and needed no other change.
Recommendations
- Write a dedicated pin template rather than reusing the card.
- Test the page with consent declined.
- Use filters to reduce pins, not a larger cap.
- Treat a sparse map as a data quality signal.