An estate agency template, and what property search needed from the collection table

[havenswift-hosting]

We have built an estate agency site template on EmDash 1.0 and published it under MIT.

• Repository: https://github.com/havenswift-hosting/terrasuite-emdash
• Live demo: https://emdash.terrasuite.uk/ (420 properties, Node and SQLite)

A property collection of 27 fields, a filtered search, a property page, a page per town, and a seed so there is something to look at on the first run. One stylesheet, no framework, no webfont.

Why it reads the collection table

getEmDashCollection() filters by field value and by taxonomy term, but it has no range operator, so "between 150,000 and 600,000" and "at least three bedrooms" cannot be expressed at all. A sandboxed plugin's ctx.storage.query() has ranges, but only on declared indexes, with a single sort, 100 rows a page, and no way to ask whether a multi-valued field contains a value.

Estate agency search is ranges plus set membership and almost nothing else, so the template reads the collection table directly as trusted site code. That turned out to be a pleasure rather than a workaround, because EmDash has already done the hard part: every collection gets a real SQL table with a real column per field. /search?engine=api on the demo runs the same page through the content API instead and lists the filters it had to drop, which is a fairer way to show the difference than describing it.

What the indexes are worth

EmDash indexes the system columns it owns and nothing on the fields a collection declares, which is the right default for a CMS that cannot know what anybody filters on. Measured at 20,000 properties, ten filters, ordered by price:

Index	Median
none	4.0 ms
leading with the price range	2.1 ms
seeking by town	0.75 ms
covering, so the table is never read	0.09 ms

The covering one is (deleted_at, status, dept, town, price, beds, baths, built_area, pool, availability, property_type, id, slug, title). Same shape at other sizes: 0.015 ms over 1,000 properties and 0.226 ms over 50,000. It is in scripts/install-indexes.mjs with the reasoning next to it.

Two things that caught us out

Worth recording in case they save somebody a morning:

1. An image field stores the whole MediaValue, not the media id. We joined media.id = featured_image, which matched only the rows our own demo loader had written. It stayed invisible until a property page rendered <Image image={p.featured_image} /> as src="01M3MY...", because the cards build their own URLs and kept working.
2. Behind a reverse proxy, set EMDASH_SITE_URL. Without it getPublicOrigin() falls back to the internal request URL and writes http://127.0.0.1:4321/... into the src and srcset of every image <Image> renders. Again, property pages only.

Neither is a bug in EmDash. Both were quiet enough to survive a review, which is the only reason they seem worth mentioning.

Listing

If a property or real-estate template would be useful alongside blog, marketing and portfolio, we would be glad to contribute it. emdash-cms/templates says it is auto-synced and closes external PRs, so we have not opened one there. Tell us the route you would prefer and we will follow it.