Pakete installieren und aktualisieren

Ein Paket bündelt Funktionen für eine wiederholbare Installation. Dazu können Themes, Seitentemplates, Attribute, Blocktypen und Aufgaben gehören. Installation und Upgrade müssen vorhandene redaktionelle Inhalte erhalten.

Installationsumfang und Besitz festlegen

Im Paket-Controller stehen Handle, Version, benötigte Core-Version und gegebenenfalls Abhängigkeiten. install() registriert neue Objekte, upgrade() ergänzt oder migriert sie. Vor jedem Import ist zu prüfen, ob ein Handle bereits existiert und wem er gehört. Ein vorhandenes Core-Attribut darf nicht als eigenes Objekt übernommen werden; ein gleichnamiger fremder Blocktyp ist ein Konflikt, der vor dem Schreiben sichtbar werden muss.

Die Verwaltung zeigt verfügbare und installierte Funktionen vor einer Package-Installation.

Abbildung 1: Eine Paketinstallation wird über die Verwaltung angestoßen; die eigentliche Datenmigration muss im Controller sicher umgesetzt sein.

Nutzen Sie CIF für deklarative Objekte und Ausgangsinhalte, prüfen Sie aber die Wirkung jeder Import-Routine in der konkreten Core-Version. Bei Seitentypen kann ein wiederholter Import etwa Composer-Sets erneut anhängen. Bei Attributen kann ein Request-Cache eine vor dem Import fehlgeschlagene Suche behalten. Filtern Sie vorhandene Seitentypen und Attribute vor einem Import. Leeren Sie nach einem Attributimport den passenden Request-Cache, wenn die Suche den zuvor fehlenden Eintrag zwischengespeichert hat. Testen Sie den Import zweimal und führen Sie ein Upgrade mit vorhandenen Inhalten aus.

Bestehende Inhalte schützen

Ein normaler Upgrade-Lauf darf vorhandene Seiten, Blöcke und hochgeladene Dateien nicht durch Ausgangsinhalte ersetzen. Seitentyp-Defaults lassen sich beim ersten Anlegen befüllen; auf einer produktiven Site müssen vorhandene Defaults vor einer Änderung geprüft werden. Wenn ein Upgrade Inhalte migrieren muss, begrenzen Sie es auf klar erkannte, noch unveränderte Ausgangswerte und dokumentieren Sie den Eingriff. Sichern Sie Datenbank und Dateien zusammen und prüfen Sie die Auswirkungen an einer Kopie.

Der native Full Content Swap ist ein gesonderter Weg bei der Installation. Er wird nur nach ausdrücklicher Auswahl durch einen Superuser ausgelöst. Der Core verwaltet dabei den Austausch; ein Paket stellt CIF und zugehörige Dateien bereit. Eine eigene Löschroutine oder ein versteckter Swap in upgrade() wäre falsch. Prüfen Sie bei Startinhalten, ob Seiten, Dateien und globale Bereiche über diesen nativen Weg tatsächlich vollständig ankommen.

Release prüfen

Testen Sie mindestens vier Zustände: frische Installation mit und ohne Beispielinhalte, Upgrade mit redaktionell veränderten Inhalten und wiederholtes Upgrade derselben Version. Vergleichen Sie vorher/nachher die IDs fremder Objekte, Seitenversionen, Formulareinträge und Dateien. Ein erfolgreiches CLI-Ende belegt noch nicht, dass die Seite rendert: öffnen Sie Startseite, Unterseite und alle neuen Blockdialoge im Bearbeitungsmodus, dann prüfen Sie die mobile Ausgabe.

Auf uninstall() ist besondere Vorsicht nötig. Das Entfernen eigener Paketobjekte kann fremde Seiten treffen, wenn diese das Theme oder einen Block weiter verwenden. Ermitteln Sie solche Abhängigkeiten, bevor Sie deinstallieren. Pauschales Löschen nach Handle ohne Besitzprüfung gefährdet Core- und Drittanbieterobjekte. Erweiterungen und Themes verwalten beschreibt den Ablauf aus Verwaltungssicht.

Weiterlesen

Quelle: Concrete CMS Dokumentation (EN) · Stand: ConcreteCMS 9.5.7