dbxapp Knowledge System Self-Test
Search Reference

System Self-Test

On this page
  1. Run dbxSelfTest and understand results
    1. Open self-test
    2. Which test profile should you use?
    3. What is checked?
    4. JavaScript without Node.js on the web server
    5. Monitoring, stopping, and resuming
    6. Reading status correctly
    7. Command line and automation
    8. Protocols and data protection
    9. Recommended acceptance procedure
    10. Further instructions

Operation & Safety · Quality assurance

Run dbxSelfTest and understand results

dbxSelfTest checks an installation reproducibly from the admin area or by command line. The test catalog reflects the components installed on the current system, every run is recorded permanently and each result shown transparently down to the individual test.

Recommendation Run the quick test after an installation, update, module change, or server migration. Run the full test before a release and after major changes.

Open self-test

Sign in as an administrator and select System → system self-test. The direct internal call is ?dbx_modul=dbxSelfTest&dbx_run1=dashboard. The overview shows the detected test areas, the active run, a filterable test catalog, and the latest results.

Which test profile should you use?

Quick test

Short operational check for runtime, protection rules, entry points, cache and all module checks marked as fast.

Complete test

Runs the entire existing catalogue and adds PHP and JavaScript syntax checks as well as Composer checks.

Test selection

Performs only the checks marked in the catalogue. Filter by name, file, or area when you need a targeted regression check.

Single test

Runs exactly one test and is suitable for diagnosis after a correction.

The number of available tests varies by installation. A production package includes the integrated system checks, while a development installation also discovers PHP and JavaScript tests supplied by installed modules. The important measure is therefore not a fixed number, but whether every discovered test completes successfully.

What is checked?

  • Runtime: PHP 8.2 or newer, required extensions and secure process execution.
  • File system: Required directories, local configuration and protection from delivered secrets.
  • Modules and contracts: Entry points plus the DD, FD, template, routing, and security contracts of installed components.
  • Syntax: all project PHP files and – if Node.js exists – all project-owned JavaScript files.
  • Browser behavior: JavaScript tests with DOM, events and UI behavior run on the web dashboard in an isolated hidden browser frame.
  • Dependencies: Composer configuration and, when Composer is available, its security audit.
  • Integrity: Merge-conflict markers and guest page-cache consistency.

JavaScript without Node.js on the web server

Node.js is not required for online operation. When a run starts from the web dashboard, the open browser executes the JavaScript behavior tests. This checks DOM behavior, events, and user interactions in a real browser environment. The comprehensive JavaScript syntax check for the complete file tree uses node --check; if Node.js is missing, this check is reported as skipped and not as a system error. Node.js is recommended on development and release systems.

Monitoring, stopping, and resuming

  1. StartingConfirm the selected profile or tests. Progress, current test and counter are continuously updated.
  2. Opening detailsEach test shows status, duration, exit code and output. This makes failures reproducible.
  3. Stop safely“Stop running” stops after the current test. Already recorded results are retained.
  4. ResumeAn interrupted run can be continued from the next pending test. Stale running reports are recognized as interrupted after ten minutes.
  5. Export“JSON” provides the complete, machine-readable report for support, archive or CI evaluation.

Reading status correctly

  • Passed: The check met its defined contract.
  • Error: Review the details and output, fix the cause, and rerun the individual test first.
  • Skipped: An optional runtime such as Node.js or Composer was not available. Assess whether it is needed for your use.
  • Running: The run is active. For long syntax or integrity checks, a single step can take visibly longer.
  • Interrupted: Browser, PHP process or server has been terminated. You can resume or restart the run.

Command line and automation

php dbx/modules/dbxSelfTest/tools/run.php --profile=quick
php dbx/modules/dbxSelfTest/tools/run.php --profile=full
php dbx/modules/dbxSelfTest/tools/run.php --test=<test-id>
php dbx/modules/dbxSelfTest/tools/run.php --profile=full --json

The CLI run is suitable for deployment scripts and scheduled tests. For browser-based JavaScript tests, the web dashboard remains the relevant environment; On build systems, Node.js adds the full syntax check.

Protocols and data protection

Run reports are stored as JSON files/sys/selftest. The history retains the 20 most recent runs. The endpoints accept only test identifiers recognized by the server and protect state-changing actions with action tokens; requests cannot inject shell commands. Nevertheless, test output should never contain passwords, tokens, or complete local configuration files.

Limit of self-test A successful run does not replace backup and recovery testing, nor does it replace domain testing of real business processes. Login, critical forms, media, email and central pages should also be checked manually after an update.
  1. Run the quick test and resolve every failure.
  2. Run the full test through to a completed final status.
  3. Explicitly evaluate skipped tests and provide Node.js or Composer if necessary.
  4. Rerun failed checks individually, fix them, and then repeat the full test.
  5. Archive JSON report along with version number, backup verification and manual acceptance.

Further instructions