Craft CMS and estate agency

Property entries, cached templates and several sites sharing a layout

Craft estate agency builds are bespoke, which removes the usual worry about an update overwriting your layout and replaces it with two others. Property entries are imported from somewhere else and move faster than anything else on the site, and one Craft install commonly runs the sales site, the lettings site and a branch or two from a single set of templates.

Why this pairing is its own job

The Craft CMS install guide covers the tag, and the estate agency guide covers what the assistant has to know. What follows is the part that belongs to neither.

  • Property entries are imported, usually on a schedule, from the system negotiators actually work in. The entry on the site is a copy, the material the assistant reads is a copy of that copy, and a property that went under offer this morning is two copies behind.
  • Craft's cache tag is common around listing regions because they are the expensive part of the page. A tag pasted inside one is served from stored output, so the deploy succeeded and the change is still invisible.
  • One install, several sites, one layout. Sales and lettings, or two branches on different fee scales, share the file you are pasting into, so one key answers for all of them unless the layout branches on the current site.
  • The listings a buyer is looking at are frequently on a portal you do not control, so the enquiry arrives on your site about a page on somebody else's, described in wording you did not write.

What changes about the install here

<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>

The tag is the same one on the Craft CMS guide. Everything below is about where it goes on a estate agency site specifically.

Check what the layout is wrapped in before you paste

Look at what surrounds the closing body tag. If the footer region sits inside a cache tag, put your line outside it. A tag inside cached output is served from a stored copy keyed by URL, so the install appears to have worked on pages nobody had visited yet and to have failed on the ones that matter.

It also means a key change later needs a cache clear before it takes effect, which is an unpleasant thing to discover while trying to switch an assistant off in a hurry.

Decide about the other sites in the install before you deploy

Open the sites screen and read the list properly. If it shows a lettings site and a sales site, or three branches, the layout you are editing is probably serving all of them and one key is about to answer on all of them.

Where the sites are variants of one brand on one fee scale, that is simpler and fine. Where the fee scale, the branch address or the service differs, branch on the current site handle in the layout and give each its own key, so a landlord in one town is not quoted another town's management fee in writing.

Each site's address is a separate origin, so every one needs an allowlist entry regardless of how many keys you end up running.

Deploy, clear, then check on a property page

Templates are project files, so this goes through your normal branch and release rather than through the control panel, and the change is live when the deploy lands rather than when somebody saves.

Clear the caches from Utilities afterwards and check a property page rather than the home page. Property templates are the most likely to be cached and the most likely to be the first page a visitor lands on, because that is where a portal sends them.

Where the answerable material lives

Source material on a Craft CMS estate agency site
Seller and landlord fee pagesCommission basis, tie in, notice, and what each management tier includes. Stable, high value, and the material vendors and landlords compare agents on before they ever call one.
Referencing and deposit processWhat is checked, when a guarantor is needed, how long it takes, which scheme holds a deposit and how deductions are decided. Entirely proceduralised, which makes it the strongest material on the site, and it has to match what you actually operate because a tenant will quote it back.
Property entriesImported, cached and moving. Index them and every availability answer carries a timestamp the visitor never sees. Keeping the assistant on process and fees and having it link the live listing is the safer arrangement by a distance.
Portal listingsNot yours. A buyer arriving from a portal is asking about a page on the portal's site, which is not in your material and not under your control. Answer about the property from your own entry, or decline and take a name.

The first thing to get right

Do this first
Branch the layout on the current site handle now, even if there is only one key today.

Craft multi site installs grow. The second branch or the lettings site gets added by somebody who is not thinking about the assistant, and it inherits the layout including the tag and the key. A few lines that select a key by site handle cost nothing while there is one site, and they prevent an answer written for one office being given in the name of another.

The failure that belongs to this combination

A tenant was quoted the sales fee, because both sites share the layout

The mechanics are undramatic. One install, two sites, one tag, one key, and a corpus assembled from a crawl that walked both addresses because both of them are yours.

The result is an assistant answering a landlord question out of a vendor page, citing it, and sounding certain. On a fee question that is a complaint. On a deposit or referencing question it becomes a compliance conversation, because what you told a tenant in writing is the version they will hold you to.

Either split the key by site, or make sure every fee page names its audience and its site in visible text so the citation under an answer shows immediately which one it reached for. The first is the fix. The second is what you do while the first is waiting to deploy.

Before you go live

  • The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
  • Open the site as a visitor would, on the pages a estate agency visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.

Questions

Can it tell somebody whether a property is still available?
Only as accurately as the copy it read, which on an imported listing is already behind your own system. Have it point at the live listing and offer to arrange a viewing rather than asserting a status, because an availability answer that is wrong costs you the applicant and the vendor's confidence at once.
Should the sales and lettings sites share one assistant?
Only where the fees and the process are genuinely the same. Where they differ, use two keys and two sets of material, because the failure is not a wrong fact from the wrong page, it is a wrong fact stated in writing to somebody deciding whether to instruct you.
It stopped appearing after we changed the key. Why?
If the tag sits inside a cache tag, the stored output still holds the old markup and will until it expires or is cleared. Clear the caches from Utilities, confirm, then move the tag outside the cached block so the next change does not need the same dance.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.