Verhaltensänderungen der Legacy-Erweiterungen (September und Oktober 2026) #

Lesen Sie diese Seite, bevor Sie eine Website aktualisieren, die die Legacy-Erweiterungen, Designs oder Themes verwendet, die mit oder neben Exponential 6.0.15 ausgeliefert werden. Zwischen dem 22. September und dem 2. Oktober 2026 wurden alle auf denselben Stand gebracht. Die meisten Änderungen sind unsichtbar; diese Seite führt die auf, die es nicht sind, in der Reihenfolge, in der Sie sie prüfen sollten, jeweils mit Prüfung und Lösung. Die eigene Seite jeder Erweiterung unter Erweiterungen führt ihre Releases auf.

Kurze Checkliste #

1. Aktualisieren Sie die Erweiterungen, die Sie verwenden, auf ihr aktuelles Release (siehe die Release Notes). Lassen Sie se7enxweb/expui installiert.

2. Erzeugen Sie die Autoloads neu und leeren Sie die Caches:

   php bin/php/ezpgenerateautoloads.php -e
   php bin/php/ezcache.php --clear-all --allow-root-user

3. Durchsuchen Sie Ihre eigenen Erweiterungen und Designs nach den Mustern der Abschnitte 1, 4 und 6 unten.

4. Prüfen Sie Rollen auf umbenannte und neue Richtlinien (Abschnitt 7) und handeln Sie bei den Sicherheitskorrekturen (Abschnitt 9).

5. Erneuern Sie alles, was gepackte Skripte und Styles cacht (ezjscore 1.5; --clear-tag=template,content).

1. Persistente PHP-Worker: Modul-Views deklarieren auf Dateiebene nicht mehr ohne Schutz #

Was sich geändert hat (22. September 2026). Exponential bindet bei jeder Anfrage eine Modul-View ein. Eine Funktion oder Klasse, die auf der obersten Ebene dieser Datei deklariert ist, wird beim zweiten Einbinden ein zweites Mal deklariert, und das ist fatal. Mit einem Prozess pro Anfrage passiert das nie; unter einem persistenten Worker (Exponential Velocity, FrankenPHP) beendet es den Worker bei der zweiten Anfrage, und der Client erhält ein 502.

In explayouts_ui, explayouts_ui_api, cjw_newsletter, eztags, ezupdate, ezflow, ezodf, ezpm, xrowmetadata, nxc_powercontent, syndication, sevenx_dse und xrowextract ist jede solche Deklaration jetzt in function_exists() oder class_exists() eingeschlossen und an den Anfang ihrer Datei verschoben. (PHP bindet eine unbedingte Deklaration der obersten Ebene, bevor die erste Zeile läuft; eine geschützte existiert erst, wenn die Ausführung sie erreicht, sodass eine Datei, die eine Funktion oberhalb ihrer eigenen Deklaration aufrief, sonst brechen würde.) Unter Apache und PHP-FPM ist das Verhalten unverändert.

So prüfen Sie Ihren eigenen Code.

grep -rln "^function \|^class " extension/*/modules extension/*/classes/runnable/views 2>/dev/null

Jede aufgeführte Datei deklariert auf Dateiebene und braucht einen Schutz.

So beheben Sie es.

• Schließen Sie jede Deklaration ein: if ( !function_exists( 'myHelper' ) ) { function myHelper() { ... } } und if ( !class_exists( 'MyClass', false ) ) { class MyClass { ... } }.
• Besser: Machen Sie die View zu einer Klasse, wie in Befehle, Cronjob-Teile und Modul-Views als Klassen beschrieben.
• Vermeiden Sie Zustand in statischen Funktionsvariablen und static-Variablen, der zwischen Anfragen zurückgesetzt werden muss. Beispiele: ezstarrating 6.0.3, dessen Cache der Bewertungsstatistik in einer statischen Funktionsvariablen lag; sevenx_dse 1.1.1, bei dem das für die Nonce der Sicherheitsrichtlinie galt.

2. Seiten für vergessene Passwörter verraten nicht mehr, ob eine Adresse ein Konto hat #

Was sich geändert hat. user/forgotpassword des Kernels antwortet für eine gültige Adresse nicht mehr mit „There is no registered user with that email address“, weil das jedem erlaubt, Adressen eine nach der anderen zu testen. Die Designs und die Erweiterung, die eine eigene Kopie der Seite hatten, taten am 27. September 2026 dasselbe: ezwebin 6.0.7, ezdemo 6.0.4 und ezmbpaex (die View userpaex/forgotpassword) 6.0.2. Jetzt gilt:

• Eine unbekannte, aber gültige Adresse erhält dieselbe Seite wie eine bekannte („wenn ein Konto mit der Adresse registriert ist, wurde eine E-Mail daran gesendet“);
• eine Eingabe, die keine E-Mail-Adresse ist, erhält „Bitte geben Sie eine gültige E-Mail-Adresse ein.“;
• eine als Array gesendete Adresse wird behandelt, als sei keine angegeben;
• jede Adresse, die die Seite ausgibt, wird mit |wash maskiert.

Die Meldungen verwenden den Übersetzungskontext design/standard/user/forgotpassword des Kernels, daher gelten vorhandene Übersetzungen. ezmbpaex 6.0.3 macht den Schlüssel zum Zurücksetzen außerdem zu 128 Zufallsbits aus der sicheren Quelle des Systems (bisher ein md5 aus der Zeit und mt_rand()). Schlüssel und Links behalten ihre Form; vorhandene Links funktionieren, bis sie ablaufen.

So prüfen Sie es. Überschreibt das Design Ihrer Website user/forgotpassword.tpl oder das Template von userpaex, vergleichen Sie es mit dem des Kernels. Tests oder Dokumentation, die die alte Meldung erwarten, müssen sich ändern.

3. Fehlerseiten zeigen ihren eigenen Fehler im Seitentitel #

Was sich geändert hat. Jede Fehlerseite erreicht das Pagelayout mit derselben URI, daher gab der Fehler, der zuerst gecacht wurde, allen späteren seinen Titel und Pfad: Ein „Seite nicht gefunden“ konnte den Titel des Fehlers „Zugriff verweigert“ tragen. Die Cache-Blöcke für Kopf, Pfad und Menü von ezwebin 6.0.8, ezdemo 6.0.5 und sevenx_themes_simple 1.0.15 fügen dem URI-Schlüssel jetzt Fehlertyp und Fehlernummer hinzu, wenn die Seite eine Fehlerseite ist. Jede andere Seite behält genau denselben Cache-Schlüssel.

So prüfen und beheben Sie es. Hat Ihr eigenes pagelayout.tpl ein {cache-block keys=array( $module_result.uri, ... )} um Kopf, Pfad oder Menüs, schlüsseln Sie Fehlerseiten ebenfalls nach Fehlertyp und Fehlernummer, wie es die Erweiterungen tun:

{def $uri_cache_key = $module_result.uri}
{if is_set( $module_result.errorType )}
    {set $uri_cache_key = concat( $module_result.uri, '|error|', $module_result.errorType, '|', first_set( $module_result.errorNumber, '' ) )}
{/if}
{cache-block keys=array( $uri_cache_key, $user_hash, $extra_cache_key )}
    ...
{/cache-block}

4. YUI ist weg; jQuery 4 und Exponential UI ersetzen es #

Das ganze Bild und die Ersatztabelle stehen in YUI aus Exponential entfernt. Für die Erweiterungen:

Diese Erweiterungen verlangen se7enxweb/expui ^1.0.0.1, wo sie dessen Module verwenden (eztags, ezwebin, ezwt, ezmultiupload, ezautosave).

jQuery 4 selbst hat Hilfsfunktionen entfernt: $.isArray, $.trim, $.proxy, $.browser, die Kurzformen .click(), .bind() und .unbind() und das boolesche .attr(). eztags, ezie, ezstarrating, cjw_newsletter, ezwebin, ezdemo, xrowmetadata und das Magnific Popup des Themes simple wurden portiert (.on(), .off(), .prop(), Array.isArray).

So prüfen Sie Ihre eigenen Skripte:

grep -rnE 'YUI\(|YAHOO\.|ezjsc::yui|\$\.browser|\$\.isArray|\.bind\(|\.unbind\(|\.load\(function' extension/ design/

5. HTML5-Markup in den Designs #

ezwebin 6.0.3, sein Installationspaket ezwebin-ezpackage, ezwt 6.0.3 und sevenx_themes_simple 1.0.12 (Juli 2026) schreiben HTML5:

• selbstschließende XHTML-Schrägstriche (<br />, <input />, <img />, <meta />, <link />) sind entfernt;
• veraltete Attribute type und language an Tags <script>, <style> und Stylesheet-<link> sind entfernt;
• das Stylesheet der Werkzeugleiste verzichtet auf Herstellerpräfixe.

ezdemo, ezodf und ezflow folgten mit <br> (27. September). bcwebsitestatistics 1.0.6 tut dasselbe für die Analyse-Tags. Überschreibt Ihr Design diese Templates, muss ein Style oder Skript, das nach den alten Attributen auswählt oder XHTML-Ausgabe erwartet, möglicherweise geändert werden.

6. Code, der auf jeder Datenbank laufen muss #

Eine Reihe von Korrekturen (29. und 30. September 2026) hat Abfragen portabel gemacht. Eigener Code sollte denselben Regeln folgen; die Korrekturen der Erweiterungen zeigen jede davon:

7. Geänderte Namen, Registerkarten und Richtlinien #

8. Die API des Layout-Editors: Tokens, Entwürfe und gesperrte Zonen #

• explayouts_ui_api 1.3.3 lehnt jede Anfrage außer GET, die das Formular-Token der Sitzung nicht mitbringt (Header X-CSRF-Token oder Feld ezxform_token), mit HTTP 403 und dem JSON-Body {"error":{"code":403,"reason":"form_token_missing"}} ab.
• 1.3.4 lehnt Schreibvorgänge an Blöcken ab, sofern der Block nicht zu einem Entwurf gehört.
• 1.2.1 lehnt Schreibvorgänge an Blöcken eines veröffentlichten gemeinsamen Layouts und in verknüpfte Zonen ab.

Skripte, die die API angesteuert haben, müssen das Token von GET /explayouts_ui_api/app/api/config holen (csrf_token), an Entwürfen arbeiten und veröffentlichen. Siehe die Spezifikation der API.

9. Sicherheitskorrekturen, die Handeln erfordern können #

10. Metadaten, Übersetzungen und Integritätsmanifeste #

• Jede Erweiterung hat jetzt eine ezinfo.php und eine extension.xml, die beide Name, Version, Copyright, Lizenz und Website angeben, sodass Setup > Über und die Upgrade-Prüfungen sie zeigen. Einige zeigten den Verzeichnisnamen als ihren Namen; sie zeigen jetzt ihre echten Namen (zum Beispiel „Enhanced eZBinary File Type“, „Xrow Meta Data“, „Exponential Layouts UI API“).
• Registerkartennamen, Tooltips, Navigationsteile und Einträge des linken Menüs von Erweiterungen werden in den Kontexten design/admin/pagelayout, kernel/navigationpart und design/admin/parts/<menu>/menu übersetzt; fügen Sie Ihre Sprache dort hinzu.
• Die share/filelist.md5 von cjw_newsletter (das Manifest hinter Setup > Systemupgrade Überprüfung > Überprüfe Dateikonsistenz) entspricht jetzt den Dateien. Vor 4.1.5 meldete die Prüfung Dateien, die niemand angefasst hatte.
• Die Copyright-Hinweise in den Erweiterungen nennen zuerst „1998 - 2026 7x & Exponential Foundation“, über den ursprünglichen Hinweisen von eZ Systems, die bleiben, wie es die GPL verlangt.

11. REST API v1 und v2 kommen aus einer Erweiterung; ezprestapiprovider ist veraltet #

Was sich geändert hat (15. Oktober 2026). ezprestapi 1.2.6 liefert REST API v1 und v2 allein aus: eine Provider-Klasse, ezp7xRestApiProvider, für die Präfixe ezp und ezpl, eine Routentabelle, eine OAuth2-Einrichtung. ezprestapiprovider 6.0.4 ist sein letztes Release und eine Kompatibilitätsschicht: ezpRestApiProvider und ezpRestContentController erweitern die Klassen von ezprestapi, seine rest.ini ordnet ezp und ezpl ezp7xRestApiProvider zu, und die fünf Klassen, die es doppelt hatte, sind entfernt. Bisher antwortete jede Route /api/ezp/v2/... mit 404, und die Lesezugriffe von v1 liefen ohne die Berechtigungsprüfungen, wenn ezprestapiprovider früher in ActiveExtensions stand oder allein aktiv war (wie es der Setup-Assistent früher aktivierte). Jetzt leitet jede Kombination jede URL an ezp7xRestContentController. OutputFormat=xhtml füllt renderedOutput wieder; jede andere Antwort von v1 und v2 ist unverändert.

So prüfen Sie es. grep -rn "ezprestapiprovider\|ezpRestApiProvider\|ezpRestContentController" settings/override extension/*/settings extension/*/classes findet die Aktivierung, ein Override von rest.ini, das den alten Provider nennt, und Code, der den alten Controller erweitert.

So beheben Sie es. Behalten Sie ActiveExtensions[]=ezprestapi oder fügen Sie es hinzu und entfernen Sie ActiveExtensions[]=ezprestapiprovider; ändern Sie ProviderClass[ezp]=ezpRestApiProvider in ezp7xRestApiProvider; führen Sie dann php bin/php/ezcache.php --clear-tag=ini --allow-root-user und php bin/php/ezpgenerateautoloads.php -e aus, laden Sie PHP-FPM neu und starten Sie Velocity neu. Für OAuth-Clients, Tokens, persönliche API-Schlüssel oder URLs von v1 ändert sich nichts. Die Schritte und die Tabelle vorher und seitdem stehen in REST API v1 und v2: eine Erweiterung.

Verwandte Seiten #

• REST API v1 und v2: eine Erweiterung

• YUI aus Exponential entfernt

• Befehle, Cronjob-Teile und Modul-Views als Klassen

• Unterstützung für PHP 8, Velocity-Engines, Sicherheitshärtung

• Release Notes aller Erweiterungen

• Geschichte der Erweiterungen

• Eine Erweiterung kann ein Kernel-Modul ersetzen

• Erweiterungen in mehr als einem Ordner

• Geschichte: Januar 2024, 16. bis 31., September 2024, Oktober 2024