Demo Mode

A one-switch, read-only tour of the whole product, backed by a fully seeded demo restaurant. Turn it on to show Next Restaurant to a client, train staff, or explore an area you haven't used — without any risk of changing something.

Find it under Settings → Demo Mode.

What it does

Two things at once:

Seeds demo data — locations, a full menu with images and modifiers, reservations, orders across every channel, staff, stock and payments. The product looks like a working restaurant rather than an empty install.
Makes the install read-only — every write is refused at the server while demo mode is on.

The second part is what makes the first safe. A demonstration cannot accidentally delete a menu item or take a payment, because the write never reaches the database.

The Demo Mode tab with the switch on, and the demo banner across the top of the admin

The read-only tour

While demo mode is on:

Every screen is fully navigable. Nothing is hidden.
Every write is refused with a clear message saying demo mode is active.
A banner across the admin makes it obvious the install is in demo state, so nobody spends ten minutes wondering why nothing saves.

The refusal happens in the dispatcher, based on whether the request is a write, not on the name of the task. That distinction matters: a guard that pattern-matched task names would let through any endpoint whose name didn't match the pattern, and every new controller would be a chance to accidentally punch a hole in it.

The exemptions

Two lanes are deliberately exempt, because a demonstration that can't demonstrate anything is useless:

Lane	Why
Guest ordering	So you can show a QR order or a storefront checkout actually completing
Staff terminals	So you can show a POS ringing up a check and a KDS bumping a line

These exemptions are narrow and specific. They are not a general bypass, and they should not be widened — the value of demo mode is that the guarantee is simple enough to trust.

What demo mode does not cover

The lockdown covers NextRestaurant writes only. Joomla itself is untouched.

That matters because of how the read-only tour is granted: on a demo site, any signed-in Joomla account gets it — including someone who registered themselves through your storefront. Those visitors cannot change a single thing inside NextRestaurant, but as far as Joomla is concerned they are still ordinary logged-in users. In particular, a visitor can still edit their own account through the site's profile form, so a single shared demo login is fragile: one visitor can change its username, email or password and lock every other visitor out.

The quick user switcher below is the answer to that — it hands each visitor a disposable persona instead of a shared login, and every reset restores the cast. Alongside it:

Turn off self-service profile editing before you publish a demo link.
Never enable demo mode on a live restaurant. It is a showcase switch, not a security control.

For a public demo site we ship an optional extra plugin, System – Next Restaurant Demo Guard, which closes exactly that gap: while demo mode is on, only Super Users may change or delete Joomla user accounts. It is not part of the normal release — it comes with the internal demo package — and it is installed and enabled for you when you install that package.

If you have installed the demo dataset from a normal release, you have the full NextRestaurant write lockdown but no Joomla account protection. The two bullets above are how you cover the difference.

If you later install a normal release over a demo one, the guard stays behind, still enabled. The normal release does not list it, so nothing uninstalls it for you — and uninstalling the NextRestaurant package afterwards will not remove it either. This is harmless: the guard does nothing at all unless demo mode is on. If you want it gone, remove System – Next Restaurant Demo Guard on its own from System → Manage → Extensions, which works once the demo package it came with has been replaced.

The quick user switcher

Showing someone what a server sees, then what the kitchen sees, then what a manager sees used to mean creating Joomla accounts by hand, assigning roles, wiring staff PINs, and logging in and out between each one. Installing the demo data now seeds that cast for you, and a small pill in the corner of every page switches between them in one click.

Persona	Lands on	Sees
Diner	The storefront menu	Ordering and booking as a customer does
Server	The waiter handheld	The floor, their tables, ringing up a check
Kitchen	The kitchen display	Tickets, firing and bumping
Manager	Reports	Service oversight, staff, reporting
Back office	The dashboard	Every screen the product has

The panel opens by itself the first time somebody arrives, then stays out of the way as the corner pill. There is also a fuller page if you want something to link to — add a Demo User Switcher menu item — listing each persona with its username and password.

Everything stays on the front end. The staff app and the whole back office are served on the site as well as at /administrator, so the personas never leave the site: one session, one login, no jumping between the two halves of Joomla. That is not only tidier, it is safer — see below.

It adds no operator rights. A persona changes who you are, never what you may write. The manager persona can open a refund form and fill it in, and pressing Save gets the same refusal everyone else gets. The two exempt lanes stay exempt, so the diner really can place an order and the server really can ring one up — which is the whole point of them. Picking a staff persona also signs you in at the terminal, so a POS or KDS really does work; that is the terminal_demo_writes exemption above doing its job, not the switcher granting anything. Turn that setting off and both the switcher and the PIN pad go read-only together.

A few details worth knowing:

No persona is a Super User, and none can sign in at /administrator. Both are deliberate. A Super User is exempt from the lockdown, so a Super User persona could write for real; and Joomla accepts a password at /administrator without ever consulting demo mode, so an account that could log in there would be a standing back-office login that outlived the demo. Personas are ordinary registered users holding the NextRestaurant Owner and Manager roles — full authority inside the product, none outside it. That is why every password can safely be printed on the card.
The cast is fixed. Visitors cannot create accounts; there is no anonymous sign-up lane to abuse, and every visit looks the same.
Resetting the demo recreates the cast, so a visitor who changes something about their persona cannot spoil it for the next one.
It only exists on a demo install. The switcher ships with the same demo-only plugin as the guard above, and that plugin owns the table the personas live in. A normal release carries neither, so there is nothing to switch on by accident — installing demo data on a production site cannot expose it.

Turning it off

Switch it off in Settings → Demo Mode. Writes are immediately allowed again and the banner disappears.

The seeded demo data does not vanish on its own. Review it before going live — an install that goes into production with demo menu items still published will publish them to the storefront.

The demo photographs

Installing the demo data downloads a photograph for each menu item, plus six venue shots, from Wikimedia Commons into images/nextrestaurant/. They are chosen from a fixed, reviewed list, so every install gets the same pictures.

Some are public domain or CC0, but most are Creative Commons licences that require attribution wherever the photo is publicly displayed. If a demo photo is still on your storefront when you go live, either credit it or replace it with your own photography. The full list — file, licence and author — ships with the extension as DEMO-PHOTO-CREDITS.md in the component's administrator folder. Replacing the pictures with your own is the cleaner path for a real restaurant anyway.

When to use it

Situation	Why demo mode helps
Showing a client	A populated product with no chance of breaking their data
Training staff	People can click anything without consequences
Exploring a feature	See how reservations or the POS behave with real-looking data
Evaluating before buying	Judge the product with a full restaurant in it, not an empty shell

When not to use it

Not on a live site during service. It refuses every write, including real orders.
Not as a permissions mechanism. Demo mode is a global switch, not access control. To stop one person changing things, use Roles & Permissions.
Not as a backup. It prevents writes; it does not protect what is already there.

A note on testing permissions

Demo mode and permissions interact in a way that trips people up when they try to verify access control:

Demo mode refuses non-Super-User writes first. A permission test run while demo mode is on proves the demo guard works, not that your role grants are correct.
A Super User bypasses role checks entirely. Testing with a Super User account proves nothing about permissions either.

To actually verify a role, turn demo mode off, test with a non-Super-User account, and include a negative control — confirm that something you deliberately did not grant is refused. Without the negative control, a passing test may only be telling you that the account can do everything.