myX: updatefeste Erweiterungen

Lokale Erweiterungsschicht

myX: projektspezifisch und updatefest entwickeln

myX nimmt Anpassungen auf, die nur zu dieser Installation, diesem Kunden oder diesem Projekt gehören. Allgemeingültige Korrekturen bleiben dagegen in ihrem dbxapp-Kernel- oder Fachmodul. Diese Trennung verhindert, dass ein Produktupdate lokale Arbeit überschreibt.

Warum updatefest? Der Paketmanager aktualisiert signierte, verwaltete Produktpakete. Das lokale Paket local/module/myX ist nicht verwaltet und liegt außerhalb dieser Paketdateilisten. Seine Klassen, Templates und Assets bleiben deshalb beim Update erhalten. Updatefest heißt nicht wartungsfrei: Nach einem Versionswechsel werden die verwendeten Erweiterungspunkte weiterhin im Testsystem geprüft.

Welche Änderung gehört wohin?

Änderung	Ziel	Grund
Gilt für alle Installationen	dbxapp-Kernel oder zuständiges Fachmodul	Wird getestet, versioniert und als Produktupdate verteilt.
Gilt nur für diese Website oder diesen Kunden	`dbx/modules/myX`	Bleibt lokal und wird nicht von verwalteten Paketen überschrieben.
Menü, Texte und redaktionelle Inhalte	Installation / CMS	Kundeninhalt ist kein Produkt-Release.
Wiederverwendbare Modul-Fachlogik	Zuständiges Produktmodul	Klare Zuständigkeit, vollständige DD und gemeinsame Tests.

Sinnvolles Beispiel: lokaler Hinweis ohne Produktdatei

Die Installation soll nur auf ihrer Statusseite einen eigenen Hinweis anzeigen. Das HTML liegt in dbx/modules/myX/tpl/htm/service-status-notice.htm; die lokale Templateklasse ergänzt es nach der normalen dbxTPL-Verarbeitung:

class myTPL extends dbxTPL
{
    public function replaces(string $tpl, $replaces): string
    {
        $html = parent::replaces($tpl, $replaces);
        $page = trim((string)dbx()->get_system_var('dbx_permalink', ''), '/');
        if (basename($page) !== 'service-status') {
            return $html;
        }

        $notice = parent::get_tpl('myX|service-status-notice');
        return str_replace('</main>', $notice . '</main>', $html);
    }
}

Dabei wird weder dbxTPL noch dbxContent verändert. Der Updater kann beide Produktpakete ersetzen, während die lokale Klasse und ihr Template bestehen bleiben. Das reduziert Merge-Konflikte, macht Zuständigkeiten sichtbar und erleichtert Tests, Rollback und Audits.

Prüfung nach einem Update

Vorher: dbxapp 4.5.3 + myX

Produktpakete sind unverändert. myX ergänzt ausschließlich den lokalen Statushinweis und besitzt einen Vertragstest für den verwendeten Template-Hook.

Nachher: dbxapp 4.6 + myX

Der Updater ersetzt nur verwaltete Produktdateien. myX bleibt bytegleich; SelfTest, Hook-Vertrag, Statusseite, Missing-Liste und Error-Log werden erneut abgenommen.

Wenn der Hook geändert wurde: Das Produktupdate bleibt korrekt installiert. Nur die lokale myX-Erweiterung wird im Testsystem an den neuen, dokumentierten Vertrag angepasst und separat freigegeben. Genau diese Trennung macht Rollback, Verantwortlichkeit und Fehleranalyse beherrschbar.

myX, lokale Konfiguration und Daten vorab sichern.
Kernel- und Modulupdates zuerst in einer Testinstallation ausführen.
myX-Vertragstests, SelfTest und die betroffenen Seiten prüfen.
Admin-Missing-Liste, Systemmeldungen und files/dbxError.log kontrollieren.
Erst danach denselben signierten Paketstand produktiv installieren.