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, and if you are running a shared demo login, that means they can change its username, email or password and lock every other visitor out.

Two things follow:

Turn off self-service profile editing before you publish a demo link — or point the demo at an account nobody else needs.
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.

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.