Booking, orders and enquiries

Nothing on this site ever claims a table is free. No availability, no calendar, no countdown, no confirmation — the site does not know any of it. A person answers, and until they do nothing is held. The enquiry receipt says so, and the seam says so once, beside the press. The word confirmed appears nowhere.

That is a design decision, not a missing feature: a site that says a table is held, when nothing held it, is the one failure a restaurant cannot absorb.

The booking seam: three modes

Settings › Site details › Booking › Mode.

Whatever the mode, the plain link-out is rendered underneath the container, and <noscript> carries the same link. A widget that fails to load, is blocked by a content blocker or is refused by a consent banner still leaves a working way to book. The container is invisible until the partner puts something in it, so a blocked widget photographs as nothing rather than as a dead grey rectangle over a working link.

provider is the one setting on the whole site that loads code from another company.

Before it is on, the site makes no third-party request anywhere, which is what lets your notices page say there is nothing to consent to. That stops being true the day you switch it on: the partner's script runs in your visitors' browsers, they can see the page was visited, and the consent obligations attach. The settings screen says this where the field is, and so does the agent ability that writes it.

One adapter ships — OpenTable — and it has never been run against a live account. It is that partner's documented loader shape, nothing more. We claim compatibility with no named provider. An unknown provider falls back to the plain link, never to an empty box. Treat provider mode as a seam you finish, not as an integration you inherit.

The limits beside the press

Which services take a table at all comes from the service records — Services › the service › Bookable — and the one-line summary under them ("Bookings: supper and weekend brunch. Everything else is walk-in.") is derived from that, never typed.

To stop taking bookings for one service for a while, post a Booking slip. It strikes that service's row on the booking card and the derived line stops naming it. Nothing in your settings changes, and it reverses itself on the date you set.

The takeaway order seam: three modes

Settings › Site details › Order › Mode. The same shape as booking.

There is no cart, no basket, no quantity on a dish row, no checkout, no payment and no delivery, and nothing claims a preparation time or a queue. It is a documented place to put the link, which is what a café that takes collection orders needs every day.

The enquiry form

Six fields — what it is about, name, email, how many people, preferred date, anything we should know — an error summary at the top, and a receipt that says no table is held until somebody answers.

It is an enquiry, never a booking.

How it sends

Two ways in, one handler, neither checked less than the other:

• With no JavaScript, the form posts natively to WordPress's own admin-post.php, the browser gates the field constraints itself, and the page comes back with the receipt rendered on the server.
• With JavaScript, the same fields go to the plugin's own REST route, and the errors are shown in the summary without a reload.

Every sentence the form can show is already in the page — each field's own messages, the summary's headings, each row's label — so a translator changes the page and the server and the browser cannot say two different things about one field.

What it stores: nothing, by default

The mail goes to Group email (or the site administrator if that is empty), with a Reply-To of the person who wrote, and the request ends. Nothing is written to your database.

Tick Keep a copy of enquiries and each one is kept as a private record instead. That is personal data your site then holds, nothing expires it on its own, and your privacy notice has to say so. The sentence under the button changes to match, in both states.

Email delivery

WordPress sends mail with wp_mail(), which on most hosts means PHP's own mail(). That is the single most common reason a form "does not work": the mail is sent and silently dropped by the recipient's spam filter.

If enquiries do not arrive, install an SMTP plugin and send through a real mail service — your own domain's mailbox, or a transactional provider. That account is yours; we own none of it and recommend no particular one.

Spam protection, and no captcha

Four measures, none of which sends your visitors anywhere:

1. A WordPress nonce.
2. A field no person can see.
3. The signed instant the page was drawn — anything sent within three seconds of it was not typed by a person, and anything older than two hours belongs to a stale page.
4. Five sends per connection per ten minutes, the connection held as a hash and never as an address.

A submission that trips a trap is answered exactly like a good one and is not sent. Telling a robot which test it failed is how the next attempt passes it.

There is no third-party captcha, and none is planned. A captcha sends every visitor somewhere to be scored. This site sends nobody anywhere — see Privacy.

Who owns what