Installation and Updates

This chapter is the mandatory operations contract for new installations, release updates and database changes. The decisive factor is always the local installation. The release directory is a validated publication generated from it and not a second source of development.

Principle: The DD determines the storage target, not the database type

Each DD has $table['server' a standard server delivered. An installation may locally overwrite this standard for each individual DD. Thus, in the same installation at the same time:

• DDs in various .db3files;
• multiple DDs in the same .db3file;
• individual DDs on MySQL/MariaDB;
• further DDs continue on SQLite;
• DDs of different modules on different SQL servers.

Domain modules remain independent of the selected database server. You continue to use only a DD reference and dbxDB:

Direct PDO, SQLite or MySQL code in the module, installer or in a migration is not allowed.

Resolving a server binding

The local configuration is exclusively in:

config.php contains only the delivered standard:

For example, a local mixed installation can be bound as follows:

dbxapp is the name of an active entry in $config['db'. A value such as dbxShop|dbxShop.db3 is a DD/DB3 server target.

The resolution is clear:

1. Exact local binding modulus|dd;
2. compatible older binding only via the naked DD name;
3. Other $table['server' from DD.

An existing but invalid local binding deliberately does not fall back on the DD standard. It is rejected as a configuration error. So a typo can never write unnoticed to the wrong database.

The current state can be checked without data mutation:

The return indicates declared and resolved servers, source and validity.

Administration

Underground System → DD Ser connections List dbxAdmin All found DDs. Each DD can independently access:

• their delivered DD standard;
• an active configured SQL server;
• its previous explicit DB3 target

be placed. Only deviations are stored. Passwords and other local database values are not rewritten.

A target change does not postpone data. Only an explicit transfer/migration process may transfer tables and records to another destination.

New installation and installation switches

A complete installation output can be provided via dbxapp.de. Production .db3Files from the development installation do not belong in a public source or update package.

A new installation starts with:

As long as this value is active, all dynamic page requests are redirected to the installer before permalink, content, session database or page-cache access. dbxSetup and the independent installation design. After successful completion, the assistant saves exclusively in the local, update-protected config.local.php:

The installer works in seven comprehensible steps:

1. Check PHP version, necessary extensions, composer dependencies and write permissions. Optional extensions are shown separately.
2. Set page title, brand name, claim, standard language, time zone, and user and admin design.
3. Select the target model: use the supplied DB3 files directly, set all DDs to a tested PDO server or existing single bindings. Supported installation goals are initially MySQL/MariaDB, PostgreSQL and Microsoft SQL Server. Existing non-secret server values are taken as form defaults; Empty password fields retain an already locally stored password.
4. In the DB3 standard, check all existing tables for completeness only by reading. Only for a selected central database server, the DD schemas are synchronized via dbxDB. An optional, explicitly confirmed transmission can only copy existing local DD tables to the reachable destination afterwards. Installation and module code never directly uses the underlying driver.
5. The administrator admin Set up with a personal password. password and repetition are already checked in the assistant; Capitals and lowercases, one number and one special character are authentic, twelve or more characters are recommended. If the user is missing, it is created. If it already exists, the installer updates the explicitly entered password, activates and confirms the account and ensures the admin role. Other profile data and non-installation settings are retained.
6. Configure global email operation, transport, SMTP access, visible sender, envelope sender and allowed sender domains.
7. Confirm a secret-free summary and enable the installation locally.

The installer does not change any existing groups. The personal admin password is used exclusively with password hash() stored and never output in summaries, logs or local configuration. A confirmed reinstallation may only update the account with the re-entered personal password. Repeated execution does not generate duplicate seed records.

PDO migration

A migration is only offered after server type, host, database, user and port have been captured. Before storing the DD bindings, a connection directly to the target database must succeed. If the database does not yet exist, the assistant may only create it after express selection and with an account authorized to do so; then the connection to the created database is checked again.

Only in the following, separately confirmed step are target tables generated from the DDs and – if also explicitly selected – existing DB3 data transmitted. A connection, creation or testing error ends the process before each schema or data migration.

Assistance in the installation assistant

Step 3 offers two directly accessible OpenWinAssistance:

• Included DB3 Explained describes the unchanged delivery status of table structure and technical data as well as the only reading completeness check. The personal admin password is only set up separately in step 5.
• PDO migration step by step separates server data, connection, optional database system, re-connection check, DD structure and the explicitly confirmed data transfer.

Both helps are opened without form submission. They show no access data and clearly indicate that no schema or data change starts without a successful destination connection.

Global e-mail operations

$config['mail delivery mode' applies before all module configurations:

Value	Behaviour
Internal	No network shipping. Recipient, sender and subject are recorded as an internal mail event in dbxSysMsg adopted; Content and attachments are not stored.
External	The selected PHP mail, sendmail or SMTP transport may send messages.
disabled	The mail event is rejected and the global block is logged internally.

The secure delivery standard is Internal. SMTP access and sender can already be fully prepared, while external shipping still remains turned off.

The global profile sender is only the fallback value for general system messages. Business processes have separate, locally stored From addresses:

Process	Configuration value	Specification
Contact requests, receipt confirmations and support responses	dbxContact.mail from	kontakt@dbxapp.de
Orders, order status and revocations	dbxShop.mail from	shop@dbxapp.de

Both values can be entered freely in installation step 6 and are combined with mail profile = dbxapp in the respective config.local.php stored. The contact form uses the requester's address exclusively as Reply-to; As a result, the visible sender remains stable and client-side mail rules can reliably distinguish contact and shop processes. Is the force from activated in the global mail profile, the mail service deliberately replaces both module senders with the global From value.

Supported Update Base

dbxapp 4.2.0 is the first supported version. UPDATE BASELINE and each update manifesto sets this limit in a machine-readable manner. There is no installation and no data migration from a version before 4.2.0.

The updater itself remains fully forwardable: New releases can replace and remove product files, execute DD/dbxDB migrations, create backups, and roll back files and databases together. These migrations always start at 4.2.0 or a minimum version expressly required later in the manifest.

Database migration of a module

A release migration is under:

Minimum example:

Mandatory rules:

1. The ID is permanently unique and will never be changed after publication.
2. The version number is the first release version that needs the change.
3. Every possibly modified DD is in affected dd.
4. Schema changes are from the new DD and run as sync dd.
5. Domain data changes use only the Up handed over dbxDB-/dbxDDObject.
6. A migration is never supplemented by direct SQL files or PDO.
7. Already executed migrations must not be subsequently changed; The SHA-256 comparison would intentionally stop the update.

sync dd uses the safe mode by default Applicable: missing fields and indices are added, but a necessary table rebuild stops with an error message. Only if the release author has explicitly checked the already secured rebuild, he is explicitly requested:

An optional Up receives the system-wide facades:

For recurring seeds, an idempotent installation service must be used. Migrations must not require local server names.

Update procedure

Until the installation starts, the user can completely stop the prepared update. The critical DB/file step started after this is deliberately not partially interruptible. An error automatically triggers the shared rollback of database tables and files.

Before a migration, each affected DD is resolved again. The backup is grouped according to the server actually used. This keeps an update correct if, for example, users and orders are on MySQL, content and sessions but in different DB3 files.

Protection against unintentional server change

If a release changes the one delivered in a DD $table['server'The update must not implicitly redirect an existing installation to the new destination. Without explicit local binding, the update process is rejected.

The operator then explicitly decides:

1. define the previous target as local DD binding; or
2. Transfer data to the new destination with the planned transfer process and only then change the binding.

This also applies to DB3-to-MySQL- and MySQL-to-DB3-changes.

Migration ledger and rollback

Executed migrations are carried out in dbxAdmin|dbxMigration logged with ID, version, module, checksum, status, affected servers and backup reference.

Before the first writing step, schema, indices and data of each affected existing table are backed up. During rollback:

• newly created tables removed;
• restore previous table structures and indices;
• restored secured data;
• the migration status is marked as rolled back;
• restore changed program files from the same update backup.

Release responsibility

The development takes place in <dbxapp source directory> instead. Only a explicit release step synchronizes the checked source state according to <dbxapp release directory>, creates inventory, ZIP, checksums and manifest and then publishes GitHub.

Installation data and local configuration are never copied from GitHub to an existing installation. Updates provide code, DDs and versioned migrations. The local DD server binding remains the truth of the respective installation.

The same property principle applies to menu content: Installation-related menu templates are customer files. A local menu adjustment is maintained directly in the affected installation, not published as a product change and must not be overwritten by an update. The implementation of the menu module and its system sources, on the other hand, remain product files; Changes to PHP, DD, FD, JavaScript or CSS are shipped exclusively via the tested release and update process.

Removal matrix

Before publishing a release, at least:

1. DD resolution without binding, with DB3 binding and with SQL alias;
2. parallel resolution of two DDs on different server types;
3. an invalid bond is rejected;
4. install=1 reaches the wizard without prior DD, permalink or side cache access;
5. necessary system checks block the next step, optional checks remain clearly visible as recommendations;
6. new installation, reappearance and repeated seeds do not generate duplicate records; The user admin upon confirmation of step 5, receives reproducibly the personal password checked there, the admin role and the status active and confirmed; empty password fields for existing server and mail access remain untouched;
7. unchanged, purely reading tested DB3 table structure and technical data as well as PDO installation: without reachable and existing or successfully created target database, neither schema nor data migration must start;
8. Global Mail Modes Internal, disabled and External; in particular: Internal do not start network transport and do not log message content;
9. German installation interface on desktop and mobile device without horizontal side overflow; English and Spanish follow only after technical and creative release of the German version;
10. registration with the admin password set in step 5 is successful; incorrect, weak or mismatched passwords are already rejected in the assistant;
11. Migration detection, checksum ledger and migration already executed;
12. Backup and rollback via at least two differently bound servers;
13. common file/DB rollback in case of simulated error;
14. existing dbxDB-, dbxForm-, dbxReport- and update regression tests;
15. complete running of the module dbxSelfTest including the PHP and JavaScript tests available in the respective installation.