Admin Dashboard

The admin dashboard is the central operational overview of dbxapp. It shows system state, runtimes, sessions, logs, cache, databases, and recent changes. This tutorial explains each area step by step.

Open and use dashboard

1. Sign in with an account that is authorized to access the administration area.
2. Open in the top menu ADMIN. The start page of the admin module shows the dashboard.
3. Select an area on the left. The content on the right changes without leaving the dashboard.
4. Read first Status and Health, thereafter System messages and Performance. This shows the overall state first and then helps you investigate potential issues.

1. Status & Health – Read the overall state

This area is the first point of contact. It combines measured runtimes with system messages and contacts. The three gauges show average values from already recorded requests.

Interpret the gauges correctly

• Total request: Average total duration of a request. This includes PHP processing, database accesses and further work of the request.
• Total PHP: average runtime excluding the reported database share. If only this value increases, the cause is more likely PHP, modules, templates or external processing.
• Total DB: average sum of database timers. A strikingly high proportion indicates slow queries, large amounts of data or many individual accesses.
• System status: Summary health value. The reasoning below indicates whether warnings or errors have been taken into account.
• Contacts: Distribute requests by Open, In Work, Inquiry, Answered and Closed.
• SysMsg: distributed stored messages for info, warning, error and security.

Then, check for them.

1. Compare them Total request with PHP Total and Total DB.
2. Open the area for messages System messages and filter for Warning, Error or Security.
3. Open when execution times are high Performance Find the affected module.
4. Check for a high proportion of DB additionally Databases and the DB sync.

2. Key figures – Oversee scope and development

The metric cards summarize the most important quantities and operating values. The large value is the current status; the smaller line explains the reference size. The history shows the change from the previously saved dashboard status.

A positive or negative trend is not automatically good or bad: More records can be expected, but not more runtime. Always check what has changed technically.

3. Quick access – open frequent tasks directly

Quick access replaces several menu paths. Each button opens the associated administration area.

• Users: Manage accounts, roles, status, verification and user actions.
• Sessions: Check active and saved sessions.
• Modules: Installed modules and check their status.
• DD Sync: Compare Data Dictionary definitions with the detected schema state.
• DB Sync: Check or synchronize tables and database structures.
• SysMsg: Open full system message log.

4. System messages – finding errors and security events

System messages log technical events. Whether only errors or additional warnings and further messages are stored is set at the top of the area.

Log level

• Error only: Only stores error messages.
• Error + Warning: stores errors and warnings; This is a useful operating mode with a manageable scope.
• All: Stores all system messages and provides the most diagnostic context, but generates more data.

Investigate a message

1. Sort them first. Create descending.
2. Filter for severity Error, Fatal, Security or Warning.
3. Read: Area, Module, Action and Work together. These columns describe where the message originated.
4. Use them RID and Usersto narrow down the affected record or user.
5. Read the message completely. Information such as: why and what Explain cause and context.
6. First fix the cause and reload the affected page or repeat the affected operation. Delete messages only after your operating or storage concept allows this.

5. Sessions – Check active and saved sessions

The session area shows which requests or sessions were saved. The switch Session DB Controls whether normal HTTP and HTML-AJAX requests write their session at the request end to the database.

• Access: Time of the stored request.
• User and IP: associated user and source address.
• Design, Page, Color and Lng: User-interface context of the session.
• Module, Run1 and Run2: requested dbxapp area and operation.
• Edit: shows the processing mode.
• Request: identifier for the stored request.

Turn session DB on or off

1. Change the switch only if you know if the session list is needed for operation or diagnosis.
2. Click on Storage. The status block confirms “session-DB active” or “session-DB inactive”.
3. In the case of inactive session DB, sessions continue to run over the PHP session; However, the database list is not updated.

6. Performance – narrowing down slow modules

Performance shows average values per module. This allows you to see whether the time is predominantly created in PHP or in database accesses. The number of requests indicates how much data the average is based on.

Select the recording level

• From: does not write new performance data.
• Only main indicators: writes PHP/System-, JavaScript and DB totals.
• Key figures and details: also writes detail timers for a deeper analysis.

Stepwise analysis

1. Locate the module where the slow process was performed.
2. Check the request number. Very few requests provide only a rough indication.
3. Compare them PHP Total and Total DB.
4. If DB is high overall, check data volume, table status and detail timer. If PHP is high, check module code, templates, external services and large loops.
5. Repeat the process several times under comparable conditions and then compare again.

Compression maintains the performance database. Performance DB empty removes the recorded comparison baseline and should only be used explicitly.

7. Content cache – managing guest pages and sitemap

The content cache stores the complete final output of valid permalinks for unregistered guests. Head metadata, design, menus and modules are already resolved in a cache hit.

The counter “Cache new guest sites”

• Active: existing cache files are read; a cache miss is rendered live and then saved as a complete final output.
• Inactive: existing cache files are still read and output; A cache miss is rendered live, but not re-stored.
• Turning it off does not clear the cache. For this there is the separate action Cache empty.

Controls and numbers

• Guest full pages: Number of complete pages saved.
• Sitemap: Number and status of created sitemap URLs.
• Cache directory: physical location of the cache files.
• Language lines: Pages, active pages, folders and cached HTML files per language.
• Empty cache: remove the stored guest pages; The following calls are initially cache misses.
• Re-create Sitemap: rebuilds the sitemap from the current content status.
• CMS: Opens the content management.

8. Diagrams – quickly recognizing size ratios

The bar chart represents central sets relative to each other: Users, online entries, modules, DataDictionaries and databases. The figures above the bar remain relevant; The bar height only facilitates comparison.

Below the diagram are additional technical indicators:

• Trace entries: Number of currently considered activity or trace entries.
• Missing: logged missing resources. A value greater than zero should be checked in the dbxMissing area.
• AutoSync DDs: DataDictionaries with active automatic matching.
• Trace DDs: DataDictionaries whose changes are recorded in the trace.
• ms Request: Duration of the current request.
• KB DBX Memory: Memory consumption of the current request.

Use the diagrams as an early warning: An unexpected change leads to detailed checks in key figures, system messages, performance or databases.

9. Activity – Recognize recent changes

Activity shows recent logged changes. Typical actions are insert, update or delete. The affected DataDictionary or the record and the time stamp are displayed.

Then read an entry.

1. The first line calls the action, for example Insert.
2. The second line calls the DataDictionary and often the Dataset ID, for example dbxMediaUsage #3763.
3. On the right is the exact time.
4. Assign the entry to a just running admin, import, CMS or workflow action.
5. In the event of an unknown or unexpected change, check appropriate system messages, user context and the affected record.

10. Databases – Check data sources and table status

The database report shows the largest or most important recognized data sources. DataDictionary, Server/Datei and table, relative load, number of records and status are specified.

• Data source: Name of the DataDictionary and associated database file and table.
• Utilisation: relative bar compared to the largest displayed source. It is not a hard disk level.
• Number: currently determined number of records.
• Status ok: Source and table were found. A missing status must be examined via DD- and DB-Sync.
• DB Sync: opens the synchronization check for database structures.

A missing or unexpected source

1. Note DD name, database file and table.
2. Open DD Sync And check the definition.
3. Open DB Sync Read the structural differences.
4. Check system messages for DB or access errors.
5. Make a structural change only after check and following the intended safeguarding procedure.

Recommended control sequence

Typical questions

Open admin dashboardAll tutorials