CMS & dbxKi

Official dbxapp website

The front end of dbxapp is normally CMS-driven. Pages are found via permalinks, rendered from content records and can embed modules.

CMS functionality

The CMS offers:

• Page tree
• Content pages
• Multilingualism
• Media administration
• SEO data
• Permalink index
• Content cache
• Module inclusions
• Template selection per content
• Admin processing in runtime context

For whom the CMS is intended

Editors edit pages, text, media, SEO and translations in a common interface. Designers provide reusable content, hero and media templates. Developers complement dynamic functions as modules without moving editorial content to PHP files.

This leaves three levels separate:

Level	Content
Editing	Page tree, text, media, metadata, active status
Presentation	Content, Hero, Gallery and Media Templates, Active Skin
Application	embedded modules such as contact, shop, report or workflow

A CMS page can therefore be a simple information page, a landing page with hero and gallery or the editorial cover around a complete application.

Modules and responsibilities

The central working surface is:

It is divided into page tree, editor and media/setting panel. The older list and individual masks remain available for specific administrative tasks; New editorial processes will use the coherent CMS interface.

Data model of a page

Content is language-related in tables such as content en, content en etc. stored. The resolver class dbxContentLng delivers the correct DD; Code is not meant to compose a language table from an unvalidated string.

Important page data:

Field	Meaning
id	ID within the active language
Folders	Folder in the language-related page tree
Title	visible page title
permalink	URL path within the language
Description	Short description and meta-fallback
Keywords	editorial search terms/Meta-Keywords
seo title	Optional custom browser and Open Graph title
meta robots	e.g. B. index,follow or noindex,follow
seo image id	open graph image; 0 Use the Hero Fallback
Content	Editor-capable HTML with CMS markers and module inclusions
template	Content layout of the page
Active	Public release
group read	Reading rights
lng uid	Cross-language identity
lng sync	Car, Manual or orphan
lng rev	Revision of the master page
lng synced rev	most recently adopted master revision

Folders have among others parent idrights and inherited defaults for content template, hero, gallery and display. The value parent means that the setting is taken from the parent folder. As a result, editors do not have to repeat common layout presets on each page.

Editorial workflow

1. Select the destination folder in the page tree.
2. Re-create the page or open the existing page.
3. Check title, permalink, description, keywords, template and status.
4. Structure and format content in the editor.
5. Assign hero, gallery and inline media from media management.
6. Check SEO titles, robots and social image.
7. Check language status and, if necessary, language synchronization.
8. Save and control frontend preview.
9. Check responsive display in desktop, tablet and mobile viewport.

Saving also performs the CMS rework: Content is normalized, media usage is updated, language revision is updated and affected indices/Caches are invalidated. Direct DB updates bypass these steps and are therefore not an editorial storage path.

Page tree, folder and inheritance

The page tree combines navigation and editorial order. Folders can contain subfolders and pages. A shift changes the hierarchy, but must not lose the cross-language identity or media assignments.

Typical heredity:

• Reading rights and visibility.
• Content template.
• Hero template, image, height, variant, sticky and scroll behavior.
• Gallery template, visible number, image size, overflow and click behavior.

Pages can overwrite individual values. A value set directly on the page takes precedence, parent uses the next higher defined value, and at the end a secure system fallback takes effect.

Content templates and slots

Content templates are under:

Examples:

The name describes the existing areas. A template can combine page titles, hero, header, gallery, one- to three-column body and footer. The renderer fills markers like {cms:hero, {cms:header, {cms:col1 and {cms:footer.

Mandatory language contract for c-*

c-*Files describe only the page division. They are therefore language-neutral and are listed exactly once in the basic directory mentioned above. There are no files like c-body1-footer_en.htm or c-body1-footer_es.htm.

The active language determines the editorial record, the FD texts and the CMS user interface. The list of available c-*-Layouts do not filter or change. Page and folder form therefore read the same physical form in German, English and Spanish c-*-List. The list is determined once per request and then reused; only the field label and the entry parent They are translated.

New layouts are complemented as a reusable template. Editorial pages should not replicate their own page-exclusive CSS application if a content template can display the same structure.

Editor and content structure

The editor stores HTML, but the CMS markers mark semantic boundaries. Examples are hero text, header, footer, column separator and print page break. The markers are displayed in the editor and translated into slots by the renderer.

For storage, the following applies:

• Empty paragraphs such as <p><br></p> are not multiplied as a growing distance sequence.
• Headings, paragraphs, lists, links and orientation remain semantic HTML.
• Content is not a place for scripts, styles or uncontrolled inline traders.
• Modular markers must remain syntactically complete.
• Copied Office formats are cleaned up instead of loading the page with manufacturer-specific markup.

Media administration

Media are central records in dbxMedia; their usage is tracked by dbxMediaUsage a page, a folder and a slot.

Separate Hero and Inline Media

An image at the top of the page with title, text or buttons positioned above it is not a freely built content block, but a CMS hero:

The Hero is thus edited via the existing Hero preview, height, variant, sticky and scroll settings. An inline image with Position-relative/Position absolute As a replacement hero is not allowed.

The area In text is formed from the currently visible editor content. It therefore only shows actually embedded media. Selection, image editing and removal directly affect the same editor content; The persistent dbxMediaUsage-Assignment is synchronized during storage via the CMS/dbxDB pipeline.

menu title belongs to the page fields next to Title, Permalink, Template and Status. It is loaded and stored as a short navigation title and is not part of the free content HTML.

Supported roles:

• Hero medium.
• Gallery medium with sorting.
• Inline image in content.
• Teaser or footer image.
• Video, external video or file/Download.
• SEO/open graph image.

File paths are normalized on the server side. Media is delivered via the content media route, which handles MIME type, range requests, ETag, last-modified and secure path boundaries. Editors should not be free files/...-Guess paths in HTML.

Fast and responsive images

The renderer generates the appropriate image attributes for content images. For galleries and images below the visible start, Lazy Loading is used; The hero, or The most important above-the-fold image can be prioritized. width and height, i.e. A stable aspect ratio prevents layout jumps.

Basic rules:

• use modern web formats and existing variants/Thumbnails,
• do not load an original file with several thousand pixels as a small card,
• meaningful Old age from media or page context,
• single-column gallery on mobile devices, with a maximum of two columns in landscape format,
• Actively load external videos only if necessary.

Unused media are not only assessed on the basis of a single table. Media maintenance compares usage, content references and files and removes only really orphaned entries.

SEO and Metadata

A published page provides at least:

• <title> From seo title or Title,
• Meta description from Description,
• Keywords, if editorially maintained,
• meta robots,
• Canonical/Permalink context,
• Open graph title, description and image,
• language-related alternate/language information, where available.

Metadata belongs to the finished page and thus also to the complete guest cache file. A cache output must not only save the body and try to add titles or social metadata from the DB after a hit.

Multilingual side families

lng uid Connects pages across languages. The master revision increases when relevant content is changed. Language siblings can be automatically synchronized, deliberately separated manually or marked as orphaned.

A translation receives its own permalink, content and metadata, but retains the same lng uid. Module inclusions and CMS markers are obtained exactly in a translation, unless the task explicitly requires their change.

Public edition and full guest cache

The cache works for pure GET-/HEAD-Permaline shopping calls from guests. Only a positive integer ID identifies a logged in user. Edit, AJAX, window and sync special requests are not cached as a public page.

The root call without parameters is technical /home and uses the same home cache logic. A hit does not require a content/permalink DB query. The file already contains Head, metadata, menus, resolution modules, skin and body. She will be with file get contents() Read unchanged – without escaping or re-interpretation.

File names of the current full-page cache v3 follow analogously:

The hash is formed from the complete normalized permalink. As a result, for example, abc/def and abc-def not. The Origin key binds the file to the schema, host, port and installation path.

Before each reading and writing, the document must be complete and <base href=.. > It fits exactly with the current basic URL. A deviant or damaged file is deleted when read and re-rendered as a cache miss. Cachebytes with file get contents() Returned unchanged: No escaping, no HTML parsing, no interpreter round and no session post-processing.

The configuration switch cache content Only controls the writing of new files. Existing cache hits remain readable even when writing is switched off. Content is disabled during normal storage over a new cache generation; Old requests can neither deliver old files nor write back to the new generation.

Erroneous replies, incomplete HTML, replies with inappropriate base href, protected input forms or inconclusively specific requests. HEAD Uses the same headers as GETDon’t send a body to Hit and Miss. One HEAD-Miss is allowed to render fully and cache for a following GET preparation.

Rights and publication

• Active controls the release of a page.
• group read limits readability.
• Folder rights can be inherited.
• Admin actions are reserved for the content admin module.
• A known CID or media ID alone is not an authorization.
• Cache is written only for actual public guest responses.

Editorial checklist

• Title, permalink, description, keywords and robots make sense.
• Side template matches the slots actually used.
• Hero and gallery have suitable media, alt texts and sizes.
• Links and module inclusions work.
• Language siblings and sync status are correct.
• Desktop, tablet, mobile portrait and mobile cross format are tested.
• Frontend does not show editor blank lines or empty paragraphs.
• After saving, an old guest cache file is not shipped.
• Social/SEO metadata also agree on a cache hit.

Content Processing

Module Inclusion in the CMS

Content can contain modules:

With parameters:

The interpreter executes these islands. In the template editor they remain raw text.

Content areas and columns

The CMS can divide content into areas with simple markers. A template decides which slots exist:

In the editor, the content separates areas via simple markers, such as:

Text before, between and after these markers is placed by the CMS renderer in the matching slots. Columns are created over templates with {cms:col1, {cms:col2 and {cms:col3. As a result, the content does not need its own PHP logic in order to be displayed multicolumn or with Header/Footer.

Multilingualism

Content can be conducted per language. Depending on the module structure, language fields, own tables or links are lng uid used.

Important points:

• The language is about dbx lng And remember-state.
• Permalinks must be language-specific.
• Cache must be disabled for content changes.

Content cache

The page cache speeds up public permalink pages, including the parameterless root call. It does not store individual content fragments, but the complete, already interpreted HTML response of the guest. This also includes menus, skin, titles, SEO/social metadata and resolved modules. Permalink and home indices are separate resolution structures.

The binding order, cache limits and disability rules are listed in the section “Public Issue and Full Guest Cache” above.

Editing the content template directly

Next to the field Content template shows the CMS for a selected c-*-Template a pen symbol. The process is deliberately fixed:

The editor window must never be opened before confirmation. The dialog indicates that every page that uses the same content template is affected. data-dbx, dbxConfirm and dbx-win are not used in parallel on the same link on this combined sequence; The CMS handler sequences Confirm and Editor uniquely.

Permalink contract

New CMS permalinks are flat and folder independent. Only lowercase letters, numbers and individual hyphens are allowed:

Use automatically generated permalinks - and never /. The dbxValidatorRule permalink and dbxContent_permalink::isValid() are used in recognition and storage. Because the folder is not part of the permalink, the link remains stable when moving a help or content page.

dbxKi

dbxKi is the AI interface for CMS and module tasks. It is intended to provide structured proposals, but not to circumvent the dbxapp rules.

Possible tasks:

• Draft content
• SEO texts
• Translation
• Module briefings
• Structural proposals for pages
• Explanation of existing templates

Visual CMS use with dbxKi

dbxKi is not just a technical interface. It is also intended for the philanthropic work in the CMS. The user should be guided in the CMS: Select the page, describe the task, provide context, review the proposal and save it afterwards.

A typical process for an editor:

The advantage is that the user does not have to work with database tables, IDs or internal storage formats. The interface shows the page and the relevant CMS information. dbxKi provides a structured proposal that is executed via the existing dbxapp paths.

The important thing is the separation:

• The human being decides which page, language and task is intended.
• dbxKi generates proposals, jobs or API actions.
• dbxapp only stores via the existing CMS, Form and DB pipelines.

This keeps the work guided and comprehensible. Even extensive tasks such as creating a new page, translating a page, improving SEO texts or assigning a hero image consist of a few steps.

Direct AI access for Codex and cursor

AI tools such as Codex or Cursor can directly access a local dbxapp installation if they have access to the project folder and/or the local HTTP endpoint. Then no manual uploading and downloading of a ZIP file is necessary.

The direct route is via the module:

The AI calls first system.describe on. After that, she knows the permitted actions, mandatory parameters, languages, tokens and sample requests. It may not then change CMS data directly via SQL, but uses the actions provided by dbxKi.

Recommended sequence for Codex/Cursor:

Example of the first API call:

Example of controlled update:

The preview provides an executable request. As a result, the AI does not have to guess which parameters are necessary during storage. The procedure is followed: First read, then plan, then execute.

ZIP bundle for AI without direct access

The ZIP path is intended for situations where the AI does not have direct access to the installation, for example in an external chat system. Then the human exports a briefing, the AI generates a response bundle from it and the human imports this bundle back into dbxapp.

With Codex or cursor on the same computer, this ZIP detour is usually not necessary. There you can use the direct API or project access. The ZIP path still remains important because it provides a secure exchange path for installations without shared file system or HTTP access.

dbxKi

AI actions should be preview-capable. Direct irreversible actions without user control must be avoided.

Edit content with dbxKi: human vision

Humans always work from the dbxapp surface. It does not need to know database tables, file paths or internal storage formats.

Typical entries:

• New CMS page: ?dbx module=dbxKi&dbx run1=briefing page create
• Change existing CMS page: ?dbx module=dbxKi&dbx run1=briefing page update
• Translate the CMS page: ?dbx module=dbxKi&dbx run1=briefing page translate
• Import finished AI answer: ?dbx module=dbxKi&dbx run1=bundle

The human process for a content change:

Important for the editor:

• The human being decides which page, language and task is intended.
• The selection of the Bootstrap components is part of the order. Only the components selected in the briefing may be incorporated into the content.
• Media is generated or assigned via media management, not via manual files/media/...-paths in the HTML.
• Hero images are not normal HTML content. They are replaced or newly created via the hero or media actions of dbxKi.
• The import does not blindly execute foreign code. dbxKi validates the job and uses the existing CMS pipelines.
• Once executed, cache, permalink index and media mappings are updated via the dbxapp pathways.

Edit content with dbxKi: AI view

The AI does not think about the complete dbxapp implementation. It reads the order and fills the fixed response scheme. dbxKi performs the execution.

The AI reads in the order bundle at least:

• KI-AUFTRAG.md
• briefing.json
• context.json
• job.vorlage.json
• manifest.json
• Optional media or sample files under assets/

Mandatory AI sequence for CMS content:

Allowed content actions are specified by dbxKi, for example:

• page.create
• Page Update
• translation.apply
• page.hero replace image
• page.hero create image
• media.create base64
• media.create image variant
• media.assign

Rules for AI:

• No SQL, no PHP, no direct file or database changes.
• Do not invent your own tools or secondary processes for execution.
• job.json is the only technical response structure for dbxKi.
• IDs, language, template, folders and existing content fields from the context do not guess freely.
• Leave fields that are not in the order unchanged.
• Content is HTML, not Markdown.
• Module inclusions such as [modulus=...]...[/Module obtained exactly, unless the order explicitly requests the change.
• Only use Bootstrap components if they were allowed in the briefing and are useful for Jodit/CMS.
• Inline media media.create * about the dbxKi delivered inline src- or inline img-Incorporate values.
• New media always with media.assign if they are to appear in the CMS as Hero, Gallery or inline medium.
• For direct API path first system.describe read, then use Guide/Preview and the delivered execute request execute unchanged.

Processing modules with dbxKi: human vision

New modules are first created via the module wizard. dbxKi for modules is designed for controlled changes to existing modules.

Typical entries:

• Create a module job: ?dbx module=dbxKi&dbx run1=briefing module
• Import module response: ?dbx module=dbxKi&dbx run1=module bundle
• Module API describe: ?dbx module=dbxKi&dbx run1=module api&action=system.describe

The human sequence for module changes:

Important for the admin:

• dbxKi may only edit the selected module.
• Changes outside of dbx/modules/{Module } / are not part of a module job.
• DD files are complete. They shall not be inc- Files depend.
• Each DD belongs to its own DB table.
• DD-to-DB sync runs over dbxKi and the dbxapp pipeline, not over manual SQL migrations.
• Templates are read and written via the dbxapp template paths. Module code used for reading dbx()->get system obj('dbxTPL')->get tpl(...); Writing operations run over the intended editor/dbxKi pipeline.
• Forms should use dbxForm conventions.
• Reports should use dbxReport conventions, including multi-select, multi-delete, edit, detail, callback functions and remember-state, if required.

Processing modules with dbxKi: AI view

The AI does not process a project freely. It provides a module job in a fixed scheme. dbxKi then checks and writes about its own functions.

The AI reads in the module order at least:

• KI-AUFTRAG.md
• briefing.json
• module.describe.json
• module.snapshot.json
• job.vorlage.json
• manifest.json
• optional module context under module context/

Mandatory AI sequence for module changes:

Allowed module actions are specified by dbxKi, for example:

• Module.backup
• module.file.write
• module.file.delete
• module.dd.write
• module.dd.sync
• module.template.set
• module.asset.write

Rules for AI:

• Never write outside the selected module.
• Never change files through direct shell, SQL or third-party tool statements.
• Do not create migrations or legacy loads if the current structure is the order.
• DD files always fully deliver.
• DD-to-DB sync only with module.dd.sync request.
• Templates on module.template.set not through invented storage locations.
• Adapt PHP code to the existing module style and use existing dbx(), dbxForm, dbxReport, openWin, Ajax, Confirm and Remember conventions.
• Do not pair UI state, selection states, and fast Ajax actions with Report HTML reloads if the task requires JSON-only or no-response.
• No global refactoring and no changes to core, other modules, global templates, configuration or databases, except dbxKi allows the specific action in the job.
• The answer is not a patch text for a human, but an executable dbxKi response bundle.

Target of the fixed dbxKi pipeline

The fixed pipeline takes the wrong degrees of freedom from the AI. The AI does not have to guess how dbxapp stores internally. It only has to provide a small, valid schema. dbxKi handles validation, backup, preview, execution, cache update and compliance with dbxapp rules.

Editing Designs with dbxKi

Design jobs use their own file-based pipeline. They are not executed as a CMS job and not as a module job:

dbxKiDesignService does not perform any delivered PHP code and free actions. Existing designs are secured as ZIP before the exchange. New designs are based on a full copy of the initial design and remain independent at runtime.

The full contract is under Design Studio and AI Wizard.

Publish dbxContent tutorials in Doxygen

The German, active pages in the dbxContent folder Documentation and tutorials are the relevant source of user documentation. The export reads content, assignments and media exclusively via DD and dbxDB:

No individual tutorials are selected by hand: All active pages of the tutorial folder are exported. Likewise, all are active dbxMediaUsage-Assignments of these pages are taken into account. In the stock of

1. July 2026, this means 18 pages, 302 page-related media assignments and 131 different image files.

Mandatory expiration after a change to a tutorial:

--writer generates the Doxygen pages and copies the associated media into the generated documentation stock. --check does not change anything and reports missing media or a non-current export with an error code.

Files under docs/generated/tutorials/ are not changed by hand. A technical correction is always made on the German dbxContent page and is then exported again. The hierarchy and assignment to user, developer and AI areas is in docs/doxygen-navigation.dox.

Old, double UTF-8 encoded characters in PHP comments are used exclusively for documentation output by docs/tools/doxygen_php_utf8_filter.php corrected. The filter does not change project files, PHP strings or executable code.

Rules

• AI may suggest content, but not bypass system paths.
• Module inclusions must be maintained exactly when content is translated.
• HTML structure must not be destroyed uncontrollably.
• Storage runs on existing modules, forms and DB pipelines.