A SuperControl WordPress site fails in a specific way. The pages are “in WordPress”. The booking is “in SuperControl”. The join is a branded-in-name-only calendar: an embed, a shortcode, or a plugin skin that never quite matches the theme and never quite feels like the rest of the page.
Guests notice. They notice on a phone, when the widget loads late, when the date picker does not match the type, when a search result is a screenshot of a list that was rendered for desktop.
The implementation job is to keep SuperControl as the operational system and make property search, availability, and checkout handoff feel like they belong to the site. That is the SuperControl WordPress service, not a theme sale.
If you still need the strategy argument for keeping the PMS, it is in Keep SuperControl, rebuild the guest experience. This piece is how the WordPress side should work.
What “native” has to mean
Native does not mean “we hid the iframe”. It means the public site owns presentation and SuperControl owns truth.
Property data synchronises from SuperControl. Names, descriptions, locations, capacities, amenities, galleries. WordPress can enhance them — editorial destination copy, local guides, better image crops — but it should not become a second property database that drifts.
Date searches request current availability and rates. A nightly dump of “open nights” into post meta will be wrong the moment a booking lands. Search has to ask SuperControl (or a cache you invalidate on change), not guess from last night’s cron.
Checkout remains SuperControl. Book, enquire, request a quote, or hand off. The website does not invent a parallel reservation that housekeepers will never see.
The UI is yours. Reusable components and design tokens, not a fixed plugin skin. The calendar should use the same buttons, spacing, and photography as the property page.
The front can stay WordPress. Gutenberg blocks, native property pages, destination SEO. Headless Next.js when the site genuinely needs it — usually not on day one.
Data: sync, don’t retype
The failure mode on older builds is a WordPress post per cottage that someone typed by hand, plus an embed that uses a SuperControl ID when it remembers to. Galleries diverge. Sleeping counts are wrong. A property is renamed in SuperControl and not on the site.
A workable model:
- SuperControl is canonical for operational fields.
- WordPress stores a property as a post (or a dedicated type) keyed by the SuperControl identifier.
- A sync job updates the canonical fields on a schedule and on webhook if you have one.
- Editorial-only fields live in WordPress and are not overwritten: “why we love this mill”, local walks, photographer credit.
ACF is a reasonable place for those editorial fields. If you later need to move or share them, that is an ACF problem — FieldCraft — not a SuperControl problem. Do not store rates in ACF.
When a property is withdrawn in SuperControl, the WordPress post should stop being bookable. Hiding it from search is not the same as leaving a stale “Check availability” block on a cached page.
Availability: live, HTML-first, cache with a brain
Live availability is the whole point of keeping SuperControl. Implementing it badly is how you recreate the widget.
Search in HTML first. Autocomplete and filters should not require a 2MB JavaScript list of every property. Return a small result document. Load maps on demand.
Ask for dates, then properties, not the other way around. Guests who have dates should not download the full estate to find out what is free.
Cache with invalidation, not with hope. A short cache of a date-range response is fine. A 24-hour cache of “July” is how you sell a week you no longer have. Invalidate when SuperControl tells you something changed, or keep TTLs short on those endpoints.
Rates at the point of decision. Do not paint a price from a brochure field if the live rate is different. Either show live rates or show “from” with a clear path to a live quote.
Failures should be visible. If SuperControl is slow or down, do not show last week’s green calendar as if it were live. Show a retry, an enquire path, or an honest wait. Silent stale availability is worse than a slow spinner.
Calendars that belong on the page
The calendar is the most looked-at component after photography. Treat it like a product surface.
- One date-range control that matches the theme, not an imported jQuery skin.
- Disabled nights that match SuperControl rules, including turnarounds if you expose them.
- A property page calendar that uses the same component as search, so behaviour does not change between list and detail.
- A handoff URL or session into SuperControl checkout that preserves the dates the guest just chose. Losing the range on click is how widgets earn their reputation.
Do not load three calendar libraries because a plugin bundled one and the theme bundled another. That is a performance bug with a booking costume.
WordPress architecture that does not fight the PMS
Use a dedicated property post type. Archive and single templates should be code you own, not a builder canvas per cottage.
Keep the booking scripts off pages that are not in the journey. A blog post does not need the availability bundle.
Editors need a preview that does not require a SuperControl login. Staging should talk to a non-production SuperControl account or a recorded fixture. Pointing staging at live availability is how test searches look like real demand.
Plugin discipline still applies. A SuperControl integration plus a page builder plus five SEO plugins plus a chat widget is how the mobile guest waits. Slim the CMS so the live availability calls have a chance. Modernisation is sometimes the first sprint of a SuperControl WordPress project.
Adjacent work that is not the first sprint
Stripe collection for deposits and balances on bookings that already exist in SuperControl is a payments problem. Booking-funnel analytics is a measurement problem. Both are useful after the guest can search and book without fighting a widget.
Do not start a SuperControl WordPress rebuild by installing a generic analytics plugin and a chat bubble. Start by making availability true and the calendar native. The rest of the stack is easier to justify once that path converts.
What we actually ship
Indicative work, independent of SuperControl itself: a technical audit, a calendar or search improvement, a native WordPress integration, a full direct-booking WordPress site, or a headless front when that is the right constraint. Fees live on the WordPress SuperControl page. They are implementation, not a Suite licence.
The acceptance test is simple. On a phone, search by dates, open a property, see a calendar that looks like the site, and land in SuperControl checkout with those dates intact — without a second, uglier UI appearing halfway.
If you cannot do that, you still have a widget. You just wrapped it in WordPress.