-Updates

Updates in WebBlocks CMS sind release-basiert und paketbasiert.

CMS liefert die gemeinsame Publisher-Client-Laufzeit als synchronisierte Quellen unter src/Support/Updates/Client, ohne das private Composer-Paket zu benötigen. CMS-Adapter verwalten Datenbankhistorie, Versionspersistenz, Paketmigrationen, Katalogreparatur und Vollbackups. Generierte Dateien werden nicht direkt bearbeitet. Das private Client-Repository ist maßgeblich: composer embed:sync-all aktualisiert registrierte Kopien, composer embed:check-all erkennt Abweichungen über das Root-Manifest .publisher-client.json.

• Die installierte Version spiegelt das letzte tatsächlich auf die Installation angewendete Release wider.
• Gewöhnliche Quellcode-Entwicklung ändert die installierte Version nicht.
• Der In-App-Updater wendet veröffentlichte Release-Pakete an, keine lokalen Working-Tree-Änderungen.
• Neue Composer-Konsumenten sollten zuerst mit composer require fklavyenet/webblocks-cms und php artisan webblocks:install installieren, bevor sie den normalen release-basierten Update-Ablauf verwenden.
• Aktuelle paketnative Installationen konsumieren paketbasierte Release-ZIPs direkt.
• Paketnative System Updates wenden das Paket-Artefakt auf das kanonische Composer-Paketstammverzeichnis vendor/fklavyenet/webblocks-cms an, sodass Composer-Update und System Update dasselbe installierte Paketlayout erzeugen.
• Historisch konnten Installationen vor der paketnativen Umstellung wie 1.31.53 paketbasierte Release-ZIPs nicht direkt konsumieren und benötigten zuerst die root-verwaltete Bridge 1.32.33 im alten Format. Dieser Bridge-Pfad ist inzwischen aus der routinemäßigen Release-Validierung ausgemustert, da in normalen Gates keine alten root-verwalteten Installationen mehr zu unterstützen sind.

Maßgebliche Benutzerdokumentation liegt in docs/ des unabhängigen Repositorys webblocks-cms-docs, einschließlich docs/guides/ und Dokumentationsmedien. Öffentliche /docs- und /guides-Seiten sind Veröffentlichungsziele. CMS enthält den Laufzeitvertrag resources/contracts/inventory.md, weiterhin über GET /webadmin/api/inventory verfügbar. Installation und Updates benötigen das Docs-Repository nicht. Die Trennung führt keine Publikations- oder Synchronisierungsengine ein.

Der Lizenzübergang verwendet eine paketnative Brückenversion:

• 1.89.1: Publisher-ZIPs enthalten nur den alten Lizenzpfad docs/LICENSE, damit bestehende Updater die Brücke installieren. Composer/Git behalten LICENSE im Stamm. Der Brücken-Updater akzeptiert beide Layouts, bevorzugt bei beiden LICENSE im Stamm und installiert die kanonische Root-Lizenz. Dokumentation bleibt ausgeschlossen.
• 1.89.2 und neuer: Publisher-ZIPs enthalten LICENSE im Stamm ohne erzeugtes docs/-Verzeichnis. Die Metadaten verlangen mindestens CMS 1.89.1. Ältere Installationen müssen zunächst 1.89.1 installieren und erneut prüfen. Composer-Installationen können direkt aktualisieren.
• 1.89.3: Der eingebettete Publisher Client wird auf 1.1.13 angehoben, prüft Brückenkompatibilität und sucht nach erfolgreicher Installation nach dem nächsten Update. Der CMS-Adapter erhält update_path und verwirft ungültige Mindestproduktversionen.
• 1.89.4: Der eingebettete Publisher Client wird 1.1.14. Hinweise enthalten nur Versionen neuer als die installierte und höchstens bis zum ausgewählten Ziel, auch wenn dieses eine Brücke ist.

Eine ältere Paketinstallation erhält beispielsweise 1.89.1 vor 1.89.4. Prüfen und installieren Sie die Brücke, dann die aktuelle Version nach erneuter Prüfung. Die Brückenseite darf nur Hinweise bis 1.89.1 zeigen. Dies ist unabhängig von der historischen rootverwalteten Brücke 1.32.33.

• Führen Sie Updates nur aus veröffentlichten Releases aus.
• Bewahren Sie installationsspezifische Dateien in geschützten Pfaden wie .env, storage/ und project/ auf.
• Behandeln Sie Entwicklungs- und Release-Workflows getrennt.
• In-App-Systemupdates zielen stets auf den Composer-Paketstamm vendor/fklavyenet/webblocks-cms. Quellcode-Wartungsstände aktualisieren über Git/Composer. Der eingestellte Quellcodemodus und WEBBLOCKS_UPDATES_MIGRATION_STRATEGY werden seit 1.41.0 ignoriert.
• Release-Pakete enthalten ausschließlich wiederverwendbaren CMS-Kerncode und dürfen keine installationsspezifischen project/-Inhalte ausliefern.
• Beim Update geschützte Pfade ändern die Release-Paketgrenze nicht: project/ bleibt lokal in der Installation und außerhalb des veröffentlichten Artefakts.
• Installierte CMS-Arbeitskopien sind Update-Konsumenten, keine Upstream-Publisher. Wenn eine Installation ein Git-origin hat, behalten Sie bei Bedarf den Fetch-Zugriff, deaktivieren Sie aber Push mit git remote set-url --push origin DISABLED.
• Erfolg wird erst gespeichert, wenn die Paketlaufzeit die Zielversion aus WebBlocks\Cms\Support\WebBlocks meldet. Eine alte/unerwartete Version führt zum Fehlschlag und automatischer Backup-Wiederherstellung. Der Status lautet bei erfolgreicher Wiederherstellung restored, sonst failed mit beiden Fehlerverläufen.

Eine Hostanwendung kann mehrere Pakete mit namensraumeigenem Publisher Client installieren. Laravel-Konfiguration gilt global; der gemeinsame Schlüssel publisher-client ist kein dauerhafter Produktzustand. Ein anderer Provider kann im selben Bootzyklus eigene Produkt-, Versionsresolver-, Ziel-, Validierungs-, Migrations- und Nachinstallationswerte schreiben.

Jeder CMS-Update-Einstieg stellt vor Dienstauflösung die vollständige CMS-Clientkonfiguration wieder her. Controller injizieren nur CmsPublisherClientConfigurator, rufen configure() auf und lösen danach SystemUpdateInspector, UpdateServerClient, SystemUpdater oder AdminUpdateIndicator im Container auf. Konstruktor-/Aktionsinjektion dieser Dienste könnte Abhängigkeiten vor Konfigurationswiederherstellung auflösen und ist unzulässig. Der Koexistenztest ersetzt die gemeinsame Konfiguration durch ein fremdes Produkt und beweist die gemeinsame Wiederherstellung von Resolver, Version, Ziel und Client.

System Updates zeigt eine Statuskarte mit zwei Zuständen. Aktuelle Installationen sehen Version und Prüfzeit. Bei kompatiblem Update erscheinen Versionspfad, eingeklappte What's new-Hinweise je Version, Update to X per Klick mit Backup-Hinweis (automatische Sicherung und Wiederherstellung bei Fehlern) sowie ein Link zu Vollbackups vor großen Updates. Verglichen werden laufender CMS-Code und neueste Veröffentlichung; die gespeicherte Installationsversion dient nur Historie und Persistenz.

Superadmins erhalten in der oberen Navigation eine asynchrone Update-Anzeige. Sie ist standardmäßig verborgen, liest /webadmin/system/updates/indicator im Hintergrund und erscheint nur bei neuer vertrauenswürdiger Version. Normales Admin-Rendering wartet nicht auf den Updateserver; aktuelle Installationen zeigen keinen dauerhaften Shortcut.

Die Vorprüfung prüft Datenbank, ZIP/sodium, PHP/Composer/Prozessausführung, Schreibzugriff auf Anwendungsstamm/Workspace und freien Speicher. Jede Prüfung besteht oder scheitert. Aktualisieren ist erst bei vollständigem Erfolg und freier Sperre möglich. Die Historie liegt in einem geschlossenen Akkordeon, Logs öffnen in Modals; destruktive Zeilenaktionen fehlen.

Nach Prüfungen und Anwendungen werden Läufe automatisch bereinigt. Standardmäßig bleiben die letzten fünf; der letzte Fehlversuch bleibt bis zu neuerem Erfolg. Die Oberfläche listet Läufe ohne Löschaktionen. CLI-Inspektion: php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last, php artisan webblocks:updates:runs --failed; kontrollierte Bereinigung: php artisan webblocks:updates:prune-runs --keep=5.

Release zeigt strukturierte Metadaten aus title, summary, highlights, fixes, compatibility_notes, migration_notes, asset_notes, operator_notes, technical_notes als maskierten Klartext. changelog_entries enthält kumulative Einträge, neueste zuerst, strikt über installierter Version und höchstens bis zum Ziel, aus changelog, releases, changelog_entries. Ohne Liste dient nur die Zielversion als Eintrag; What's new bleibt befüllt.

Der Legacy-String release_notes wird für ältere Release-Payloads weiterhin unterstützt. Sind keine Release Notes vorhanden, zeigt der Bildschirm No release notes were provided for this release. Der Updater leitet keine Änderungen aus Versionsnummern ab.

Metadaten werden lokal mit composer release:prepare vorbereitet und mit composer release:publish-update veröffentlicht. Der Wrapper prüft GitHub-CLI-Authentifizierung vor dem irreversiblen Publisher-Schreibvorgang, publiziert dort und erstellt/aktualisiert den passenden GitHub Release als latest. Vorbereitung verlangt einen passenden CHANGELOG.md-Abschnitt; dessen Operatorpunkte werden für release_notes und summary/highlights genutzt, ergänzt um Referenz, Prüfsumme und Mindestclientversion. Strukturierte Felder werden oben und verschachtelt gesendet; neue Clients erhalten reichhaltige, alte einfache Hinweise. Gelesen werden Top-Level, details, release_details, meta.release_details/meta.details.

GitHub Actions erzeugt keine Release-Pakete und publiziert keine Metadaten; .github führt nur Tests/Lint aus. Der lokale Wrapper hält GitHub latest mit dem stabilen Tag synchron. Systemupdates nutzen nur Publisher-Metadaten/Artefakte. Maßgeblich ist publisher.webblocksui.com: Veröffentlichung https://publisher.webblocksui.com/api/updates/publish, Prüfung https://publisher.webblocksui.com/api/updates/latest, Downloads https://publisher.webblocksui.com/downloads/.... Normale .env-Dateien benötigen keine Server-/Produkt-/Kanalschlüssel; ReleaseDefaults besitzt die Vorgaben samt stable und Pfaden. Die frühere Brücke updates.webblocksui.com ist historisch und keine aktive Konfiguration.

Maintainer-Befehle:

release:push pusht Release-Branch und annotierten Tag gemeinsam nach origin, mit einmaligen Pre-Push-Prüfungen. Erst danach werden identische Referenzen mit --no-verify nach backup gespiegelt; Branch und aufgelöster Tag werden auf beiden Remotes mit dem lokalen Release-Commit verglichen.

Veröffentlichung nutzt WEBBLOCKS_PUBLISHER_TOKEN, signierte Releases auch WEBBLOCKS_PUBLISHER_SIGNING_KEY. Vorgaben: https://publisher.webblocksui.com, Produkt webblocks-cms, Kanal stable, Lesen /api/updates/latest; Publishing nutzt dieselbe Identität und /api/updates/publish. Der Composer-Wrapper liest nur diese zwei Geheimnisse aus .env in den isolierten Testbench-Prozess; Cache-Konfiguration erneuert sie aus .env. Manuelles Exportieren entfällt. Dry-run prüft Schlüssel/Artefakt ohne Upload. Ein echter Lauf ohne Token bleibt kontrolliert unveröffentlicht, beendet erfolglos und zählt nicht als Publikation.

Prüfungen enthalten datenschutzwahrende Nutzungstelemetrie. Publisher unterscheidet Paketabrufe von aktiven anonymen Installationen. Downloads zählen Artefaktabrufe; aktive Installationen zählen eindeutige Installations-IDs, die sich über die Zeit melden.

Telemetrie ist standardmäßig aktiviert und lässt sich deaktivieren mit:

Bei aktiver Telemetrie entsteht bei der ersten benötigten Prüfung eine zufällige lokale installation_id in den Systemeinstellungen. Sie enthält keine Personen-/Sitedaten, bleibt innerhalb der Installation stabil und kann bei Neuaufbau oder Speicher-/Datenbankreset wechseln.

Die Prüfung sendet ausschließlich diese Telemetriefelder:

• product_key
• installed_version
• channel
• installation_id
• telemetry_schema_version

CMS sendet keine Domains, vollständigen URLs, Admin-E-Mails, Serverpfade, Datenbanknamen, Lizenzinhaber, Nutzerzahlen, Token, Geheimnisse oder beliebige Umgebungs-/Konfigurationswerte. Bei WEBBLOCKS_TELEMETRY=false werden Metadaten weiterhin mit Produkt, Kanal und Version abgefragt, aber keine installation_id erzeugt oder gesendet.

Ein In-App-Systemupdate ist ein Ein-Klick-Lauf: Paket herunterladen/prüfen, automatisch sichern, Dateien anwenden und anschließend in dieser Reihenfolge:

• Paketupdate-Migrationen, sofern vorhanden
• Cache-Leerungsschritte
• Synchronisierung des mitgelieferten Katalogs (webblocks:catalog-repair --all)
• Aufzeichnung des Update-Laufs
• Persistierung der installierten Version

Bei Anwendungs-/Prüffehlern wird das Vorabbackup automatisch wiederhergestellt. Der Status lautet dann restored; scheitert auch die Wiederherstellung, lautet er failed mit beiden Fehlerverläufen. Das Backup bleibt für manuelle Wiederherstellung im Backup-Bildschirm oder per CLI php artisan system:backup:restore verfügbar.

Nach Erfolg greift die konfigurierte automatische Backup-Bereinigung; Anzahl und freie Bytes werden protokolliert. Bereinigungsfehler rollen das Update nicht zurück, sondern erscheinen in Ausgabe und Anwendungslog. Standard: Vorabbackups 14 Tage, mindestens die letzten fünf erfolgreichen; Wiederherstellungsschutz 30 Tage, Content-Apply-Punkte 7 Tage. Backups fehlgeschlagener/wiederhergestellter Updates bleiben 90 Tage geschützt. Manuelle, hochgeladene oder laufende Backups sind ausgeschlossen. Konfigurieren/Vorschau unter Maintenance → Cleanup; Scheduler, CLI und API unter Betrieb.

Normale Updates wenden Releases an und führen nach Cache-Leerung webblocks:catalog-repair --all als Unterprozess im neuen Code aus. Block-, Pluginblock-, Slot-, Layout- und Symbolkataloge werden abgeglichen; neue Zeilen wie Rating/Comments benötigen keinen manuellen Befehl. Der nach Cache-Leerung erneuerte Dienstmanifest entdeckt neue Kommandos. Die Synchronisierung ist idempotent und erhält eigene Katalogzeilen.

Katalogabgleich erfolgt bestmöglich: Dateien und Migrationen sind bereits erfolgreich, daher lässt ein Sync-Fehler den Update-Lauf nicht scheitern. Das Log meldet den Abbruch und die manuelle Wiederholbarkeit von php artisan webblocks:catalog-repair --all. Schemaänderungen gehören in explizite Update-Migrationen; der Abgleich repariert nur Katalogdaten.

Die Cache-Leerungsschritte umfassen das Leeren von Laravel-Config, Views, Anwendungscache und Routen, damit aktualisierte paketeigene Blade-Layouts und -Helfer nach dem Dateiaustausch neu kompiliert werden. Laden Sie auf Live-PHP-FPM-Installationen, bei denen OPcache so konfiguriert ist, dass Zeitstempel nicht validiert werden, nach einem erfolgreichen Update den betreffenden PHP-FPM-Dienst neu, damit PHP keine Paketklassen von vor dem Update weiter aus dem Speicher ausliefern kann.

Während des Updates zeigt ein nicht schließbares Modal den Versionspfad mit WebBlocks-UI-Ladeanzeige. PHP-Worker können während der Anfrage neu starten; deshalb wird nicht auf deren Abschluss gewartet. Nach Auslösung wird die Indikatorroute alle 1,5 Sekunden abgefragt, mit Rückkehr spätestens nach 3 Minuten. Jede Antwort, auch Login-Weiterleitung, lädt den Bildschirm neu.

System Update führt niemals Host-database/migrations aus. So kollidieren ausstehende Laravel-Startmigrationen wie 0001_01_01_000000_create_users_table.php nicht mit bereits erstellten CMS-Tabellen. Pakete werden nach vendor/fklavyenet/webblocks-cms installiert; nur PHP-Migrationen aus vendor/fklavyenet/webblocks-cms/database/migrations/updates werden ausgeführt. Fehlen sie, wird das Überspringen protokolliert und mit Cache-Leerung/Version fortgesetzt. Auch sichere Schema-Reparaturen, etwa fehlende Elternschlüssel für portable Vollbackups, gehören hierhin.

Jede WebBlocks-CMS-Schemaänderung, die vom Laufzeitcode benötigt wird, muss beide Installationspfade unterstützen:

1. Neue/Paket-Konsumenten-Installationen: Aktualisieren Sie den normalen oder den Fresh-Schema-Migrationspfad.
2. Bestehende paketnative Installationen, die über System Updates aktualisiert werden: Fügen Sie eine Paket-Update-Migration unter dem Paketverzeichnis database/migrations/updates hinzu; installierte Konsumenten führen sie aus vendor/fklavyenet/webblocks-cms/database/migrations/updates aus.

Das Fresh-Schema allein reicht nicht aus. Wenn neuer Laufzeitcode eine Tabelle oder Spalte erwartet, muss das Release eine Update-Migration für bestehende Installationen enthalten, oder das Update muss sicher fehlschlagen, bevor der neue Codepfad einen rohen 500-Fehler auslösen kann. Paketnative System Updates dürfen nicht verlangen, dass gewöhnliche Benutzer sich nach einem erfolgreichen Update per SSH auf einer Site anmelden und Migrationen manuell ausführen.

Ein erfolgreiches Paketupdate stimmt Code, Schema, Cache-Leerung und nachgelagerte Versions-/Schemaprüfung ab. Abhängige Admin/API/Laufzeitseiten müssen bei fehlendem Schema kontrollierte Hinweise statt roher Framework-/Datenbankfehler zeigen. Referenz ist 1.32.146→1.32.147: cms_api_tokens lag nur in normalen Migrationen; nach Paketupdate scheiterte System -> API Tokens, bis 1.32.147 Paketmigration und kontrollierte Bereitschaft ergänzte.

Interaktionsschema folgt demselben Vertrag. Paketupdates müssen wbcms_comment_entries/wbcms_content_ratings automatisch bereitstellen, ohne Host-artisan migrate. Die idempotente Reparatur erhält/benennt alte unpräfixierte Tabellen um, erstellt sonst präfixierte Tabellen und bewahrt Interaktionsdaten absichtlich beim Rollback.

Release-Berichte zu Schemaänderungen müssen explizit beantworten:

• Fresh-Schema-Pfad aktualisiert: ja/nein
• Paket-Update-Migration hinzugefügt: ja/nein
• Regressionstest für die Update-Migration hinzugefügt: ja/nein
• kontrolliertes Verhalten bei fehlendem Schema nötig/hinzugefügt: ja/nein

Während der Paketumstellung können manche Installationen noch eine veraltete Kopie packages/webblocks-cms im Installationsstamm oder eine alte verschachtelte Vendor-Übergangskopie haben. Diese Pfade sind Legacy-Übergangsartefakte, nicht die aktive paketnative Source of Truth. Paketnatives System Update ersetzt nun das kanonische Composer-Paketstammverzeichnis unter vendor/fklavyenet/webblocks-cms und verifiziert die Zielversion aus diesem Paketstamm. Es behält packages/webblocks-cms nicht als zweite aktualisierte Laufzeitkopie.

Ältere Vendor-Verzeichnisse vendor/fklavyenet/webblocks-cms können repositoryförmig sein mit artisan, app/, bootstrap/, packages/webblocks-cms/, plugins/, tests/. System Update ersetzt sie durch das flache Paket: composer.json, Root-LICENSE, src/, routes/, resources/, database/, public/, config/, stubs/ direkt unter vendor/fklavyenet/webblocks-cms. Vor optimiertem Autoload wird Composer-Metadaten normalisiert; WebBlocks\Cms\ muss aus vendor/fklavyenet/webblocks-cms/src, nicht vendor/fklavyenet/webblocks-cms/packages/webblocks-cms/src aufgelöst werden. Veraltete Pfade lassen das Update scheitern statt falschen Erfolg zu melden.

Moderne Updates bewahren die mit der v1.32.56-Migration eingeführte Trennung von /webadmin-Admin und /cms-Assets. /cms ist ausschließlich ein statischer Asset-Namespace und kein Admin-Präfix, weil Nginx-try_files /cms/ als physisches Verzeichnis public/cms/ auflösen kann, bevor Laravel eine Route sieht. Updates dürfen weder im Installationsstamm noch in den öffentlichen Paket-Assets CMS-eigene /cms-Admin-Aliasse, /cms-Weiterleitungen, /admin-Routen oder eine public/cms/index.php-Übergabe wiederherstellen.

Dieser Abschnitt ist historisch. Der Updater von 1.31.53 validierte den alten root-verwalteten Archivvertrag: artisan und composer.json mussten im Archivstamm oder in einem einzelnen Wrapper-Verzeichnis vorhanden sein. Paketbasierte Artefakte wie 1.32.31 enthielten absichtlich kein Root-artisan, daher schlugen diese alten Clients vor dem Anwenden mit Package validation failed because composer.json and artisan were not found at the archive root. fehl.

Die ausgemusterte Bridge-Strategie war zweistufig:

• Ein Bridge-Release-Artefakt im alten root-verwalteten Format veröffentlichen oder erneut veröffentlichen, gebaut aus einer bridge-fähigen Quelle, die noch die Legacy-Wrapper App\Support\System\Updates\* hatte und bereits strikte paketbasierte fklavyenet/webblocks-cms-Archive validierte. Für die Bridge 1.32.33 war v1.32.30 die Quellreferenz.
• Paketbasierte Releases mit minimum_client_version auf 1.32.18 oder neuer veröffentlichen, damit alten Clients das neueste paketbasierte Artefakt nicht vor der Bridge angeboten wurde.
• Nach dem Anwenden der Bridge konnte der installierte Updater das strikte paketbasierte fklavyenet/webblocks-cms-Artefaktformat moderner Releases validieren und anwenden.

scripts/build-root-managed-bridge-archive.sh VERSION [OUTPUT_DIR] [GIT_REF] wird nur als archiviertes/manuelles Wiederherstellungswerkzeug für das Bridge-ZIP im alten Format beibehalten; zum Beispiel scripts/build-root-managed-bridge-archive.sh 1.32.33 dist v1.32.30. Der Builder schließt installationseigene Pfade wie .env, storage/, project/, public/site/, public/storage und Root-config/ absichtlich aus; paketeigene Standardwerte unter packages/webblocks-cms/config bleiben Teil der Paket-Laufzeit. Die routinemäßige paketnative Validierung führt diesen Bridge-Pfad nicht aus.

Der abgeschlossene historische Pfad war 1.31.53 -> 1.32.33 bridge -> 1.32.34+ package-rooted. Bereits bridge-fähige Installationen wie 1.32.30 übersprangen die Bridge und aktualisierten direkt auf ein paketbasiertes 1.32.34+-Release. Aktuelle Release-Gates schützen nur das paketbasierte Artefakt und das paketnative Updater-Verhalten.

Systemupdates führen nach Installation webblocks:catalog-repair --all automatisch aus; siehe Update-Ablauf. Dieselben Befehle bleiben für manuelle Reparaturen zwischen Releases oder unvollständige Synchronisierung verfügbar:

Der Befehl unterstützt --block-types, --plugin-block-types, --slot-types, --page-layouts, --icons. Zunächst mit --dry-run erzeugte, geänderte, unveränderte und übersprungene Zeilen prüfen. Er ist idempotent, erhält individuelle Katalogzeilen und löscht sie nicht.

Die Low-Level-Blocktyp-Synchronisation bleibt aus Kompatibilitätsgründen verfügbar:

Der Blocktyp-Reparaturpfad hält den datenbankgestützten block_types-Katalog auf bestehenden Installationen mit dem ausgelieferten CMS-Kernkatalog abgeglichen:

• fehlende Kern-Blocktypen werden erstellt
• bestehende Kern-Blocktypen werden an Ort und Stelle aktualisiert
• benutzerdefinierte installationsspezifische Blocktypen bleiben erhalten
• doppelte Kernzeilen werden nicht erstellt

Dieser Wartungs-Workflow schließt die Lücke, dass eine Installation Katalogzeilen auffrischen muss, ohne dass jede Anwendung eines Release-Pakets eine umfassende datenbankgestützte Katalogreparatur durchführt.

Wenn der Updater innerhalb eines git-gestützten Installationsklons läuft, der noch auf das kanonische CMS-Upstream zeigt, deaktiviert das CMS nun nach den Post-Install-Befehlen auch automatisch den origin-Push, sodass künftige versehentliche git push-Versuche klar fehlschlagen, während normaler Fetch- oder Pull-Zugriff verfügbar bleibt.

• Betrieb
• Installation
• Beiträge