VOW on WordPress

You can run a VOW on WordPress — no board rule says which software must serve the pages — but almost nobody does, because a Virtual Office Website is not a website feature. It is an access-controlled data application: a registration wall with terms-of-use click-wrap, passwords that expire on a board-mandated clock, sold data that must never reach an anonymous browser, and an audit trail behind all of it. This page lays out what the VOW agreement actually obliges you to build, how each obligation maps onto a WordPress stack, and where the effort concentrates. We write it first-hand — we operate a compliant VOW in production on TRREB’s feed — and the how-to is complete enough to follow without us.

What the VOW agreement obliges you to build

The VOW feed class exists because sold prices, expired and terminated listings, and other off-market data are treated differently from active inventory. When your brokerage signs a VOW data agreement (in the TRREB world, through PropTx), the display conditions attach to your website, and they are specific. Consumers must register with verified contact information and accept the VOW terms of use as a recorded act — a click-wrap, not a line of fine print (PropTx Rule 8.09). Their passwords are only valid for a bounded period — PropTx Rule 8.06 caps validity at 90 days, after which the user must renew before seeing gated data again. Sold data may be shown only to a logged-in, valid-password, terms-accepted user, and you are expected to be able to demonstrate who accessed what, which means retaining access records. The full checklist — the one worth handing to any vendor, including us — is in our VOW compliance requirements guide; the category itself is explained in what is a VOW.

How each requirement lands on a WordPress stack

The registration wall is the easy part. WordPress has mature user-account machinery, and any membership plugin (spoken of generically — the board does not care which) can force login before a template renders. Treat this as the first tenth of the build.

Password expiry is custom code. Consumer-membership tooling assumes passwords live until the user changes them. Rule 8.06 assumes the opposite: validity is capped at 90 days, so you need a dated credential record, an expiry check on every gated request, a renewal flow, and the emails that go with it. Fail closed — a user whose expiry state cannot be determined must be treated as expired, or your compliance depends on nothing ever breaking.

Terms of use need versioning, not a checkbox. You must record who accepted which version of the VOW terms and when, and re-prompt when the terms change. That is a small database schema and a middleware gate, not a plugin setting.

Redaction must happen server-side. This is the subtlety that decides whether a DIY VOW is actually compliant. Blurring a sold price with CSS while the true value sits in the page source is not gating — it is publishing. The sold fields, and the photo URLs of gated listings, must be stripped from the response before it leaves your server for an anonymous or expired session; the lock UI in the browser is presentation on top of data that is already absent. On WordPress that means intercepting every render path that touches the feed — detail pages, cards, search results, JSON endpoints, RSS — because one forgotten endpoint is a leak.

The audit trail rounds it out: an append-only record of gated-data access tied to the registered user, retained per your agreement. WordPress gives you nothing here by default.

Why almost nobody does it

The plugin economy is built where the volume is: active-listing display through the DDF and RESO Web API lineages. VOW support would require every vendor in that ecosystem to take on expiry logic, server-side gating, and audit obligations for a feature only some boards offer and only some agents request — so, in practice, none do, and the “VOW plugin” you might expect simply does not exist. The well-known Canadian sold-data sites are custom applications for exactly this reason. Add the human costs — a VOW agreement to negotiate, broker-of-record sign-off, a compliance review you should run before launch, and personal liability if a gated field leaks — and the honest summary is: a WordPress VOW is a bespoke software project wearing a WordPress theme.

If you build it anyway: the order of operations

Sequence matters. Secure the VOW agreement and broker sign-off first, because its terms drive the build. Stand up the authentication spine second — registration, verified contact capture, click-wrap with versioning, password lifecycle with 90-day expiry. Build the server-side gating layer third, and audit every render surface against it, including the endpoints you forgot you had. Add access logging fourth. Then have someone adversarial try to reach sold data logged out, with an expired password, and with a stale session, and fix what they find before the board does. Run that same audit again after every theme or plugin update, forever — the update treadmill is where compliant WordPress builds quietly stop being compliant.

Or skip the build. This machinery — expiry enforcement, redaction before render, terms versioning, the audit trail — is the product we already run in production, under our own board approvals, on a VOW website an agent can launch without owning any of the engineering. We think the honest comparison favours that; the point of this page is that you now have everything you need to check.