Data Views

Admin-authored, read-only SQL SELECT queries published as routable Joomla pages so non-admin site visitors can browse live database data — without requiring backend access or a database account.

What a Data View is

A Data View is a named, published surface that wraps one admin-authored SQL SELECT around a paginated, searchable HTML table rendered on the Joomla site frontend. Visitors reach it through a standard Joomla menu item; the data itself is loaded server-side on demand, so it is always live.

Key properties:

• Read-only by design. The base query is validated as a single, non-mutating SELECT before it is saved (see Validation) — no INSERT, UPDATE, DELETE, DROP, or similar statement can ever be stored or executed.
• Joomla-native access control. Who may see a view is governed by any combination of Joomla view-access-levels, user groups, and individual user IDs — no separate login or account is needed.
• Backend-authored. Only users with permission to create or edit views (or Super User access) can build and publish views.
• Frontend-rendered. Each page of data is loaded on demand, so what visitors see is always live and the page stays responsive even over large tables.

Prerequisites

Before you can build a Data View, its backing database connection must meet two conditions:

1. Published — the connection must be published so it is active.
2. Allow on frontend — the connection must have Allow on frontend (Data Views) explicitly turned on. This is off by default as a deliberate safeguard against accidental public exposure.

The Joomla site database can never back a Data View.

When you turn on "Allow on frontend" the connection form shows a warning reminding you to point the connection at a dedicated, read-only database account. Data Views execute queries using whichever credentials the connection stores — the view itself has no separate credential scope.

See Connections for full details.

Building a view — the step wizard

Open Next DB → Views → New view (or click the title of an existing view to edit it). The builder is a non-linear five-step stepper; you can jump between steps freely — state is preserved across step changes.

Step 1 — Source

Define the view's identity and its base query.

After entering a connection and a base query, click Validate & introspect. This submits the query to the server, runs the full validation pipeline, and — if the query is valid — returns the column list seeded into step 2. The step is marked complete when title, connection, and base query are all present.

Step 2 — Columns

Configure how each result column is presented. Introspected columns are pre-populated from the Validate & introspect result; you can adjust them freely. You can also add computed columns that combine values from two or more source columns via a template.

Per-column settings:

Computed columns aren't tied to a single source column — they use a template that can combine other columns, and are never sortable or searchable.

Step 3 — Display

Choose which interactive controls and paging behaviour visitors get.

Step 4 — Access

Define who may see this view. The access model is any-of (union): a visitor is granted access if they match at least one of the configured entries. See Access control for the full semantics.

Three independent sets can be configured:

• View access levels — Joomla's native access-level checkboxes (Public, Registered, Special, and any custom levels you have defined). The builder defaults a new view to Public so a freshly published view is immediately visible to all visitors.
• User groups — multi-select autocomplete of Joomla user groups.
• Specific users — type-to-search autocomplete of individual Joomla user accounts by name or username.

The interface shows the hint "A visitor sees this view if they match any of the following."

Step 5 — Review

Preview the view using real data before publishing it.

• The preview pane renders the current definition exactly as the live frontend will, and paginates through real results, so you see exactly what visitors will see before the view goes live.
• If the Source step is incomplete (no title, connection, or base query) a warning is shown and saving is blocked.
• A Published toggle at the bottom controls whether the view is live or stored as a draft. An unpublished view is not reachable on the frontend even if a menu item points to it.

Click Save view to persist the definition. The server re-runs the full validation at save time (see Validation) — the preview alone does not bypass it.

Validation

Before a view is saved — and whenever you click Validate & introspect — Next DB checks your query. All of these must pass before the query is accepted:

1. One statement only. The query must be a single statement; a multi-statement script (or an empty query) is rejected.
2. Must be a SELECT. It must start with SELECT (or a WITH … SELECT). Anything else — even EXPLAIN SELECT — is rejected.
3. No data-changing or administrative commands. Statements that could change data or the database (such as insert, update, delete, drop, create, alter, grant, and similar) are refused, even if they appear inside quoted text or comments.
4. Must run and return columns. The query is run live against the connection (returning no rows) to confirm it's valid and to read its column list. If it returns no columns, it's rejected. If two output columns have the same name, you're asked to add an alias (for example, "Column 'id' appears more than once — add an alias.").

Because validation runs the query against the live database, the connection must be reachable both when you validate and when you save.

Access control

A visitor can see a view if they match any of the access entries you configure for it. Three independent, optional lists are available:

• View access levels — Joomla's standard access levels (Public, Registered, Special, and any custom levels).
• User groups — one or more Joomla user groups.
• Specific users — individual Joomla user accounts.

A visitor who matches at least one entry in any list is allowed in; everyone else is kept out.

Default. A new view defaults to the Public access level, so a freshly published view is visible to everyone.

No entries configured. If you clear all three lists, the view is visible to no one on the site (Super Users still see it in the admin area).

Super Users. In the admin area, Super Users can browse every published view. On the public site, the normal access rules apply to everyone — there is no Super User bypass on the frontend.

Always enforced on the server. Access is checked on every request — the initial page, each page of data, and every CSV export — so editing the web address can never reveal data a visitor isn't allowed to see. Guests who lack access are sent to the login page; logged-in users who lack access are shown an access-denied page.

Frontend output

A published Data View is accessed via a Joomla menu item of type "Next DB → Data View", with the target view selected in the menu item's parameters. The page's web address comes from the menu item's alias.

The rendered page is a styled, responsive table that matches your site template. Data loads on demand, so the first page appears as soon as the visitor arrives. Depending on the view's Display options, it can also show a global search box, a per-column filter row, an export/print toolbar, and a row-detail expander.

Interactions

Views created before these options existed keep working as they did: Print stays on if the view had export on, and the other new controls stay off until you turn them on.

A column that visitors can't see can't be searched, filtered or sorted by them. The search box only appears when at least one visible column is searchable.

On phones

On a phone, each row becomes a card with the column label beside its value, so nobody has to scroll sideways. A Sort by dropdown replaces the column headers, and a Filters button shows or hides the filters. The Fullscreen button isn't shown on phones.

Printing

Current page prints the rows on screen. All matching rows prints every row that matches the current search and filters, up to 2,000 rows or your Max export rows if that's lower. A note on the printout says when rows were left out.

The printout has the page heading, the description, any active search and filters, the print date and the columns the visitor chose. It leaves out your site template's header, modules and footer.

Page heading

The heading comes from the Joomla menu item. With Show Page Heading on, the page shows the menu item's Page Heading, or its title if that's empty. With it off, the page shows the view's title, unless you turn off Show the view title as the heading in step 3. The page never shows both.

The Description from step 3 appears under the heading. The menu item's Page Class is added to the view's wrapper, so your template's CSS can target it.

Search engines

These menu item settings apply to the page: Browser Page Title, Meta Description (falling back to the view's Description) and Robots. Each page also has a canonical address, which is the menu item's own address, so shared links with a search or sort don't count as separate pages. Social sharing tags are added too.

Table rows load after the page opens, so search engines that don't run JavaScript don't see them. Turn on Let search engines read the first page of rows in step 3 to include the first page in the page itself. It only works on views open to guests (Public or Guest access level), and that data becomes part of the public page, so use it only for data you're happy to publish. With Joomla's page cache on, the copy of those rows sent to search engines can be out of date until the cache refreshes. Visitors with JavaScript still get current rows.

Auto-refresh

With auto-refresh on, a frontend Data View re-checks its data on a timer, without reloading the page. The visitor keeps their page, sort, search and filters. If nothing changed, the table isn't touched.

A row identifier is required for Marked fields only and for highlighting. Without one, the view falls back to Whole view and doesn't highlight.

In Marked fields only mode, rows being added, removed or reordered redraws the whole table, including fields you didn't select. Otherwise rows that should leave the list would stay on screen.

Database load. Every open browser tab runs the view's query at this interval, plus a count query in Exact total mode. Keep the interval as long as your content allows, particularly under 30 seconds or on shared hosting. Skip total count mode reduces the cost.

Checks pause while the browser tab is hidden and while a visitor is using a search or filter box. A redraw waits while a row detail panel is open, though Marked fields only updates continue. After an error, checks slow down until one succeeds. They stop if the visitor no longer has access to the view, until the page is reloaded.

Auto-refresh applies to the site frontend, not the Visualise section of the admin area.

Showing only upcoming items

For a schedule or playlist, add a time condition to the base query so items leave the list once they've passed:

SELECT id, title, artist, start_at
FROM playlist
WHERE start_at >= NOW()

The condition is evaluated again on each check, so rows drop off with no change to the table. To keep the track that's playing now on the list, compare against its end time instead, such as end_at >= NOW().

• NOW() is the syntax for MySQL, MariaDB and PostgreSQL. SQLite uses datetime('now'), which uses UTC.
• NOW() uses the database server's clock and time zone, so your stored times must be in that same zone.
• Date columns are formatted as stored, not converted to the Joomla site or user time zone, so a displayed time can differ from a local clock if your database stores another zone.

Statement timeout

Every data request and export applies a time limit before running the base query, so a slow query can't tie up the server. The default is 5 seconds, adjustable per view. This is best-effort — if the database doesn't support the limit, the query still runs.

Browsing views in the admin back-end

In addition to the site frontend, published Data Views also appear inside the Next DB administration area under the Visualise section, as a grid of cards. A backend user sees a card for each view they're entitled to browse (Super Users see all of them). Opening a card shows the same data in a full table, using the same access rules. The underlying query and access settings are never exposed here — only the data and how it's displayed.

Management permissions

Creating, editing, and deleting Data Views is controlled by your profile's management permissions:

Super Users always have full access. All view changes are recorded in the audit trail, according to your audit settings.

For full details on the management permission model, see Delegated management.

See also

• Connections — enabling a connection for the frontend
• Profiles and ACL — management permissions and profile structure