Home → Plugins → Store Locator for OpenStreetMap
A locator for shops, showrooms or pickup points — built on Leaflet and OpenStreetMap, so there is no Google Cloud account, no credit card on file and no per-view billing for showing a map.
The locator is not a shortcode dropped into a container. It is a first-class Bricks element: its own place in the elements list with its own icon, thirteen controls in the panel, and a map that renders live in the editor and redraws on every change. For a team working in Bricks that is the difference between configuring a map blind and seeing the result straight away.
Map with pins, address search and “near me” — plus a category filter and clustering once there are many points.
Works outside Bricks too — the same locator goes in with a plain shortcode on any theme, and the generator assembles it for you.
Locations are ordinary posts with their own category, so whoever runs the site adds them like everything else — with a map right in the edit screen.
Bulk geocoding for lists imported in one go, and a locations list showing the resolved coordinates.
A settings panel in four tabs and a shortcode generator — a closed list of options instead of a box for arbitrary code.
The public OpenStreetMap geocoder allows one request per second and forbids heavy use. A busy shop needs its own instance or a paid provider — we say so before the rollout, not after the first block.
Leaflet ships with the plugin rather than loading from someone else’s CDN. The page will not break because a third party turned a server off.The idea came from a rollout for a company in the Netherlands, where a locations map had to work without Google Maps. What we learned there about a shop with many locations came back here as a plugin written from the ground up.
The architecture, the naming and the structure were written here, so every change happens at the source — a new feature or a fix needs no guessing at what someone else meant. On an urgent fix that is the difference between an hour and a week.
The front end is plain JavaScript, the data goes over the REST API rather than admin-ajax, and the repository holds exactly the files that reach the server. Nothing has to be compiled to ship a fix.
Every lookup goes through a repository, so moving to a dedicated table at a few thousand locations is a class swap plus a migration — not a rewrite of the plugin.
Coordinate lookups pass through our own proxy with a cache and a one-request-per-second limit, exactly as the service’s terms require.
The stylesheet is split into a layout layer that always applies and a skin that a single setting turns off. Controls inherit the page typography, and the buttons accept a class from the theme.
Every decision described above has a test of its own — the PHP and JavaScript suites run with a single command, no database and no WordPress install. Yet none of them caught the three things below.
The element vanished without a trace. On a page rendered from a Bricks content template it did not appear at all — no HTML, no PHP error, nothing in the console. No unit test catches that; a rollout on a live site did.
A map that looks broken but is merely empty. A default centre near zero lands in the Gulf of Guinea — flat blue that everyone reads as tiles failing to load. A detail that ends in a phone call saying the map is broken.
Several hundred tests do not replace one click. Four builder controls were dead despite a full JavaScript suite passing. That is why a manual check list is part of the release plan rather than a good intention.
We can roll this locator out for you, or write a Bricks element for your specific case. Tell us how many points you have and where the list comes from.
Describe your case →Or by e-mail: info@asymetria.com.pl