Operating status

Official dbxapp website

This chapter documents the runtime and quality contracts for dbxapp 4.5.3. Its operational content was revalidated against this release on August 22, 2026.

Public quality status

Build ID

docs-4.5.3-20260822.5

Acceptance

August 22, 2026 · local and public

Status

passed

The release status is backed by a repeatable local acceptance run and a public HTTP crawl completed on August 22, 2026. The machine-readable report publishes the build ID, scope, timestamp, and individual results.

Check	Scope	Result
dbxSelfTest	191 discovered system and module tests	191/191 passed
Documentation crawl	158 sitemap pages, 227 internal targets	0 broken internal targets
Language pairs	96 canonical German/English pairs	96/96 reciprocal; identical version
Doxygen	1,311 HTML files per language	German/English 4.5.3; 0 build warnings
Error state	dbxMissing and files/dbxError.log	0 missing entries; no error log
WCAG 2.2 AA sample	Home, navigation, search, tutorial, long manual, and API; desktop and 390 px	Semantics, keyboard, focus, reflow, and contrast passed

Scope: This evidence applies to the named build. Customer-specific content and additional myX modules require their own acceptance tests.

System level

Area	Current contract
Product	dbxapp 4.5.3
Website	https://dbxapp.de
PHP	8.x
Doxygen	Project version 4.5.3, Generator 1.17.0; API search index is newly generated after the build
Front controller	index.php
Public API entry point	dbx/include/dbxApi.phpaccess to: dbx()
Public cache	Full guest page cache v3
Workflow	Definition in dbxWorkflow admin, execution in dbxWorkflow
Designs	dbxapp and Flowers; Old aliases fleurop is dissolved

Current security, integrity and performance contracts including secret overrides, action token decision, shop transactions, guest session behavior and HTTP evidence are under Security, integrity and performance.

Bootstrap and central API

In index.php Only Bootstrap tasks remain. The two global exceptions are necessary before dbxApi can load:

• dbx get base dir() determines the portable installation/include path.
• dbx get file dir() Determines the portable Files- Folder.

Shared runtime functions shall include methods according to: dbxApi.php and will be over dbx() Called. Module-related functions remain in the respective module. New global dbx *-Help functions are only allowed if they have to exist before the API for mandatory Bootstrap or compatibility reasons.

For data lists, the following applies: Data access remains central in dbxDB, technical quantity formation and assignment belong to the respective repository. Repeated relationships of a list are still loaded with bundled DD queries. Additional cached dbxDB::select1() identical single set accesses for the current request per DD and discards them centrally at insert(), Update(), save() and delete(). Transactions bypass the cache. Small unchangeable reference lists may also be noted within a request in the domain repository if each associated mutation emptys the cache.

Direct PDO or mysqli calls outside of dbxDB are also not allowed in command line, migration and maintenance tools. Table changes originate exclusively from DD and are dbxDD Administratively synchronized. A normal module request shall not trigger a schema change as a page effect. The shop DD synchronization and default maintenance is therefore behind the authorized and action-tokenized admin point Installation and maintenance.

The same applies to rendering: Services only generate the values whose placeholder uses the specific template. Request locations may be memorized for immutable template metadata; Domain, user and form data are not included in this metadata cache.

Current request and cache execution

A hit occurs before the content/CID database resolution. A miss renders the entire page down to interpreters and output filters. Exactly these finished bytes are stored.

Read more

Cache reading is for public guest calls with GET or HEAD allowed. In particular, registered users, admin bypass, personalized shopping cart, editor, Ajax, openWin and inconclusive query parameters are excluded.

Before issuing, the following shall be checked:

1. prepared cache generation is still true;
2. file is readable and complete HTML;
3. base href corresponds to schema, host, port and installation path;
4. Generation is still current even after reading.

If a condition is missing, the file is not used. Corrupted files or files with wrong base href are deleted and recreated at the request end after a normal render run.

A secure cache hit needed for UID 0 without incoming PHPSESSIDE no persistent PHP session. The briefly started session during the bootstraps is therefore destroyed before the early cache exit. The same applies outside the page cache only to detected robots on anonymous GET/HEAD requests. A guest session is never reconstructed via the IP; normal browser states remain bound to the random session cookie.

No treatment of cachebytes

With the cache hit, there is deliberately no treatment of the HTML content:

• No escaping;
• None htmlspecialchars();
• No repetition dbxInterpreter;
• No template replacement;
• No session or user enrichment.

file get contents() returns the stored bytes unchanged. Security arises before writing: Only a finished public 200 response without protected token fields is accepted.

Writing and disability

cache content = 1 Allows new writing operations. cache content=0 only prevents new files; Existing hits remain readable and the switch does not delete anything. Substantive changes invalidate the cache separately.

The file is initially stored under a random temporary name with LOCK EX Written and subsequently renamed Atomar. The file name contains:

• readable permalink portion plus SHA-256 hash of the complete permalink;
• Language, design and skin;
• Hash of schema, host, port and installation path;
• Cache generation and format version v3.

A disability first changes the generation and then deletes old files. As a result, a parallel old request can neither deliver an old hit nor write its outdated rendering into the new generation.

HEAD

HEAD shall have the same resolution as: GETBut never send the body:

• Hit: finished cache file is checked, only headers are sent.
• Miss: Page may be fully rendered and saved, the final output suppresses the body centrally in dbxApi::emit_http_response_body().

Hit and Miss no longer differ in HTTP behavior.

Lack of resources and dbxMissing

dbxMissing logs only missing static resources such as JavaScript, CSS, images, fonts or similar files. An unknown normal permalink is not logged as a missing resource.

The process is before the content cache:

The administration can be reached via:

Deleting single or multiple entries and emptying the table are protected with Action Token and Confirm.

Validator rules

email

The rule email Checks a full Internet address:

• Total length maximum 254 characters, local part maximum 64 characters;
• exactly one @;
• no leading, final or double point in the local part;
• at least one point in the domain;
• domain labels maximum 63 characters, no leading ZXQ0000 QXZ hyphens;
• alphabetical or Punycode TLD;
• IDN conversion if: intl is available;
• final test with: FILTER VALIDATE EMAIL.

For a mandatory field email|min=1|max=254 used.

permalink

The rule permalink Allows exactly:

This excludes spaces, capitals, umlauts, special characters, slashes, leading /abschließende and double hyphens. The automatic generation canonized titles to a flat --Slug.

Forms, notifications and assistance

Each dbxForm requires:

• field rules including mandatory marking;
• a form message placeholder in the correct location;
• Help in the modular bar on the far right;
• Clear {i}-IDs and Ajax targets;
• normal request as fallback.

dbxAdminHelp Assigns fixed topics to robust permalinks such as Help-dashboard-admin to. These links do not contain folder paths and therefore do not change when moving the CMS help page. Unregistered forms received via formButton() a fallback aid.

The failed counter of dbxForm is set to zero after 600 seconds without further failed counter. As a result, short-term inhibitions and inhibit stages are not retained over a new test period.

User passwords

When editing a user, two fields are available in the right block: New password and Repeat the password. Both remain empty if the password is to remain unchanged. Once one is completed, both values shall be present and equal; is stored exclusively by password hash().

The list action “Generate new password” generates a twelve-digit password and stores only its hash. The current admin expiration shows the new password once as a success message; An automatic mail delivery is not part of the implementation there.

CMS Media and Shop Assignment

The CMS media list also shows shop pictures if their dbxMediaUsage exactly the currently edited document and the slot Shop assigned to it. These images are available for the gallery of this document. A shop assignment of another document must not appear in the current page.

Editor media retain layout attributes such as position and size when stored. The rendered output must adopt the structure of the editor; a left image with text on the right must not fall back into a vertical arrangement after being saved.

Writing CMS, media, SEO and shop admin GET/JSON actions use the existing module and DD rights action token()/check action token()system. Pure display and navigation remain compatible and tokenless. The token occupies the specific browser action and thus protects against externally triggered requests; it does not replace an authorization check.

Content template editor

The pen symbol next to a c-*-Content template uses a sequential action:

1. confirm.js shows exactly one warning at each click;
2. there is no editor window before consent;
3. “Cancel” ends the action;
4. ‘Yes’ shall be loaded over: ajax.js/OpenWin the existing dbxEditor;
5. ACE opens the selected file under dbx/modules/dbxContent/tpl/htm/.

Module Wizard

dbxWizard generates current module scaffolding with small router, service, DD/FD, dbxForm, dbxReport and templates. Safety rules:

• Module names and file names are rigorously checked;
• No paths outside dbx/modules/{Module } /;
• existing modules can be complemented in a targeted manner;
• Overwriting is explicit and can be done beforehand under files/module-backup/ secure;
• generated templates contain form messages, modular and unique targets;
• Technical logic uses dbx(), dbxDB, dbxForm, dbxReport, ajax.js, confirm.js and openWin instead of parallel implementations.

Ajax contract

dbx ajax=1 In principle, only ajax.js for an actual Ajaxrequest. Manually generated links to complete pages do not contain the parameter. After an Ajaxrequest, new content is initialized via the dbx scan/feature pipeline.

Form Submits must SubmitEvent.submitter be preserved. FormData(form) does not automatically contain the clicked Submit button; ajax.js Therefore, it complements it. name/value. confirm.js triggers confirmed form actions via the normal Submit path and stops name/value Meanwhile, in a short-lived hidden field. This keeps form configuration, dbxForm security, AJAX and native fallbacks compatible. The dbxapp asset version is increased to 69 after this kernel change.

DD Trace

Activated DD-Trace is a deliberate exception. In the current source state:

• dbxUser.dd.php: traceability = 1;
• All other active DDs: trace=0.

Backup DDs are not an active runtime definition and are not considered a current table by this rule.

Change log and AI answers

dbxChangeLog admin maintains the filterable, editable and erasable change history. The resources of an entry are shown as a standard closed subreport, noted in UI state. The admin dashboard incorporates the most recent entries; System navigation opens the complete list.

Codex and dbxKi write exactly one understandable entry after a successful logical change block. dbxKi requires the declared change log-object with Summary, reasoning Details and Resources. Only after successful execution is stored over dbxKiChangeLogService::write_change_log(); the response returns the stored record as JSON.

Cross-session UI standards

The UI settings follow the order separately for desktop and mobile personal profile → admin standard → product standard. Administrators store the current stable UI state under System → UI as an installation-wide standard. Logged in users save and load their personal profile in the profile settings. Remove it, the system standard reappears.

Only shared display keys are stored, including grid page size, lines, autosave, column order/-breite/-sichtbarkeit, desktop height, utility theme/Skin, collapse states, menu branches, and the active admin dashboard area. Search filters, selection, current page, form values, window positions, history and scroll position are not distributed.

Reports, total number and mobile lists

dbxReport::set_report_counts($filtered count, $total count) Separate hit number and unfiltered total number. Total remains unchanged by search or selection filters; Selected describes the current hit amount. Pagination is on the right in the joint report bar.

Tables basically use the common responsive scroll frame. Where a tabular line does not remain mobile, the common class can dbx-report mobile cards form cards based on the field labels. Module-specific CSS only supplements special technical lines and does not replace the general table contract.

Sitemap, robots.txt and unknown permalinks

sitemap.xml contains only active, public and indexable content pages. noindexPages, protected folders and duplicate flat language URLs are excluded. With activated language paths, accessible language variants are recorded with canonical URLs. robots.txt Allows public pages and refers to the sitemap. Both answers support public cache headers, ETag and 304.

Known shifted permalinks become editorial in dbxContent.permalink redirects maintained and forwarded from the kernel with 301 to their canonical internal destination. A truly unknown GET/HEAD permalink remains a helpful 404 response; Missing static resources and unknown POST targets also remain true 404. A blanket 302 to the homepage is not planned, because it would disguise broken links as Soft-404. Installation-specific exceptions in myX are not necessary for this.

Minimum checks before publication

1. Check PHP syntax of all modified PHP files.
2. JavaScript with node --check check.
3. Run validator tests for email and permalink.
4. cache test including hash collision; base href, generation and byte-accurate output.
5. HEAD Check out Hit and Miss.
6. perform missing resource testing; Normal permalinks must not be logged.
7. Perform dbxForm help audit and try-count test.
8. Wizard generation test.
9. dbxDB boundary, action token and template hygiene tests.
10. Check CMS editor, Confirm and ACE sequence in the browser.
11. Re-create Doxygen to an empty output folder and search for old domains, dead links and Doxygen warnings.

Real references

• dbx/include/dbxApi.php
• dbx/include/dbxWebApp.class.php
• dbx/include/dbxValidator.class.php
• dbx/include/dbxForm.class.php
• dbx/modules/dbxContent/include/dbxContentPageCache.class.php
• dbx/modules/dbxContent/include/dbxContent_permalink.class.php
• dbx/modules/dbxAdmin/include/dbxMissing.class.php
• dbx/modules/dbxAdmin/include/dbxAdminHelp.class.php
• dbx/modules/dbxAdmin/include/dbxWizard.class.php
• dbx/js/lib/cms.js

Read more: CMS and dbxKi, dbxForm, Developing modules, dbxWorkflow and Core classes.