Upgrades ohne defekte Integrationen #

Diese Seite richtet sich an Integratoren und Betreiber, die eine Installation aktualisieren müssen, von der andere Systeme abhängen. Exponential wird aktiv gepflegt; jedes Release bringt Korrekturen, Sicherheitshärtung und neue Funktionen, und einige davon ändern Verhalten, auf das sich eine Integration verlässt. Upgrades sind sicher, wenn Sie wissen, wo Sie nachsehen müssen, und einmal proben. Das Upgrade selbst beschreibt Upgrade.

Inhalt #

1. Was sich unter einer Integration typischerweise ändert
2. Vor dem Upgrade lesen
3. Versionen und Composer
4. Das Upgrade, mit Integrationen
5. Integrationen schreiben, die gut altern

Was sich unter einer Integration typischerweise ändert #

Vor dem Upgrade lesen #

• Die Hinweise zu Verhaltensänderungen in doc/eng-us/bc/6.0/ (zum Beispiel Verhaltensänderungen 2026-10 und Verhaltensänderungen der Erweiterungen): Jeder sagt, was sich geändert hat, wer betroffen ist, wie man es prüft und wie man es behebt.
• Die Release-Hinweise jeder Erweiterung, die Ihre Integration verwendet (doc/changelogs/extensions/).
• Die Checkliste der Upgrade-Anleitung für jeden Zeitraum, den Sie durchlaufen (Upgrade, Teil C).

Durchsuchen Sie sie nach den Namen, die Ihre Integration verwendet: die Klassen, die sie aufruft, die Einstellungen, die sie setzt, die Routen, die sie aufruft.

Versionen und Composer #

• Die composer.json im Wurzelverzeichnis verwendet Tilde-Bedingungen (~1.2.6): Die letzte Stelle bleibt frei, composer update bringt also Korrekturen derselben Linie, aber keine neue Nebenlinie.
• Ihre Integrationserweiterung deklariert in ihrer eigenen composer.json, was sie braucht ("se7enxweb/ezprestapi": "~1.2.6"), damit eine Installation nicht in eine Linie aktualisieren kann, die Sie nicht getestet haben (composer.json für Erweiterungen).
• Halten Sie die Versionen in den Übergabedokumenten fest; composer show und Setup > Extensions listen sie auf.

Das Upgrade, mit Integrationen #

1. Proben Sie auf einer Kopie der Produktion mit denselben Versionen der Integration; führen Sie die Abnahmefälle und die Probeläufe der Importe aus (Integrationen testen).
2. Informieren Sie die Verantwortlichen der anderen Systeme über das Fenster; Aufrufe währenddessen können scheitern.
3. Pausieren Sie die Cronjob-Teile der Integration unter Setup > Cronjobs (und die Queue-Worker), damit kein Import halb auf dem alten und halb auf dem neuen Code läuft (Cronjobs für Integrationen).
4. Schalten Sie wahlweise den Wartungsmodus ein (php bin/php/maintenance.php on --message="..." --until=1h); API-Clients erhalten 503 mit Retry-After und sollten zurückweichen.
5. Aktualisieren Sie: Code, Datenbank-Update, Autoloads, Caches, php bin/php/console exp:velocity deploy.
6. Prüfen Sie: die Abnahmefälle, einen Probelauf je Import, einen Aufruf je API-Client, exp:audit sinks list.
7. Setzen Sie die Cronjob-Teile fort und beobachten Sie die ersten Läufe.
8. Halten Sie im Änderungsprotokoll der Integration fest, was sich für sie geändert hat.

Integrationen schreiben, die gut altern #

• Verwenden Sie die unterstützten APIs (eZContentFunctions, Operationen, expservices, die REST-Routen) statt Tabellen und interner Methoden.
• Halten Sie den Code in einer Erweiterung mit Tests, nicht in verstreuten Skripten.
• Sichern Sie optionale Kernel-Klassen mit class_exists() ab (die Audit-API dokumentiert das), damit ein fehlendes Teil die Funktion einschränkt, statt sie scheitern zu lassen.
• Ziehen Sie für alles, was eine Website ändern können muss, Einstellungen dem Code vor.
• Folgen Sie dem Projekt: Geben Sie Korrekturen, die Sie brauchen, an das Projekt zurück, damit das nächste Release sie enthält (Integrationen zurückgeben).

Verwandte Seiten #

• Upgrade
• Teil 4 des Erweiterungsbuchs: Upgrade
• Kunden-Websites aktuell halten
• Release- und Upgrade-Planung
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.