WordPress 7.0 / 7.1 im Kundenbetrieb

Zwei Major-Releases in vier Monaten: 7.0 am 20. Mai, 7.1 am 19. August. Dazwischen 7.0.1 bis 7.0.4. Ich habe inzwischen alle Kundenseiten durch. Hier meine Notizen, sortiert nach dem, was mir tatsächlich Arbeit gemacht hat – nicht nach dem, was in den Release-Posts oben steht.

TL;DR:

Echtzeit-Kollaboration ist nicht drin. Weder in 7.0 noch in 7.1.
KI im Core ist eine API, kein Feature. Ohne Provider erzeugt der AI Client nichts.
Harte Grenze: PHP < 7.4 kann nicht auf 7.0 aktualisieren.
Staging-Testpunkte: eigene Blöcke im jetzt immer aktiven iframe-Editor, jQuery-UI-Abhängigkeiten.
Was besser wird: Bild-Uploads (in unterstützten Browsern), Responsive-Styles ohne CSS, Strg+K überall.

Was rausgeflogen ist

Real-Time Collaboration war das Headline-Feature von 7.0. Am 8. Mai, zwölf Tage vor Release, wurde es gezogen. Begründung im Make-Blog: Race Conditions, Serverlast, Speicher, Fuzz-Testing hat immer wieder Bugs gefunden. In 7.1 wurde weiter getestet und entwickelt, aber nicht für Core aktiviert.

Mir egal, ehrlich gesagt. Ich habe einen Kunden mit einer Redaktion, die aus zwei Leuten besteht. Post Locking reicht denen. Was stattdessen kam, ist das ausgebaute Notes-System: @-Mentions mit Benachrichtigung, Inline-Notizen auf Textauswahl statt auf ganzen Block, mehrere Konversationen pro Block, Rich Text in Notizen. Ein Vorschlagsmodus (Reviewer schlägt vor, Autor nimmt an oder ab) taucht in mehreren Quellen auf, ist in der finalen 7.1-Ankündigung aber nicht eindeutig bestätigt – ich habe ihn noch nicht selbst in Produktion gesehen. Der Rest ist der Teil von „Kollaboration“, der in der Praxis stattfindet.

Admin-Redesign

Aus meiner Sicht die erste ernsthafte Überarbeitung von wp-admin seit Jahren. Neues Farbschema „Modern“, View Transitions zwischen Admin-Seiten, in 7.1 bleibt die Admin-Bar auch im Site-Editor und Block-Editor erhalten. Titel/Tagline/Icon liegen jetzt unter „Identität“.

Das Einzige, was mich dabei Zeit gekostet hat: eigenes Admin-CSS. Zwei Projekte mit angepasstem Login-Logo und CI-Farben im Backend – meine Styles saßen auf Klassennamen und Farbwerten, die es so nicht mehr gibt. Das ist kein Core-Bruch, das ist mein Problem. Wenn du sowas hast:

bash

grep -rn "admin_enqueue_scripts\|login_enqueue_scripts" wp-content/themes/ wp-content/mu-plugins/

Alles, was da auftaucht, einmal auf Staging anschauen.

Was ich den Kunden zeige: Strg+K / Cmd+K. Die Befehlspalette gibt es jetzt überall im Admin, nicht nur im Editor. 7.1 gruppiert nach „Zuletzt“, Treffern und Vorschlägen. Spart den Weg durch die Menüs.

Und: Vor dem Update eine Mail an den Kunden. „Backend sieht ab morgen anders aus, Funktionen gleich.“ Sonst kommt der Anruf mit „Wurden wir gehackt?“. Ist mir passiert.

KI im Core

Das Thema mit dem größten Abstand zwischen Schlagzeile und Realität. Was in 7.0 tatsächlich drin ist:

Baustein	Was es ist
AI Client	Anbieterneutrale PHP/JS-Schnittstelle. Plugins reden mit einer API statt jedes mit seinem eigenen OpenAI-Wrapper. Kein Provider ist im Core enthalten.
Abilities API	Seit 6.9, in 7.0 ausgebaut, in 7.1 mit besserer Abfrage, Filterung, Validierung und einem einheitlichen Public-Flag. Plugins beschreiben maschinenlesbar, was sie können.
Connectors	`Einstellungen > Connectors`. Zentrale Stelle für Provider-Verbindungen. Anthropic, Google und OpenAI sind als vorgesehene Provider aufgeführt; die eigentlichen Integrationen kommen nicht mit dem Core.

Die eigentlichen Features (Alt-Texte, Excerpts, Bildbearbeitung) liegen in einem separaten offiziellen AI-Plugin, dort einzeln togglebar. Ohne Provider erzeugt der AI Client selbst keine Ausgaben.

Meine Regel: Connectors-Screen bleibt bei der Übergabe leer. Nicht weil ich das für Unsinn halte – Alt-Text-Vorschläge wären für 80 % meiner Kunden ein Gewinn, die pflegen sonst gar keine. Sondern weil die Entscheidung „welche Inhalte gehen an welchen Anbieter“ nicht meine ist.

Wichtig zur Einordnung: Ein gespeicherter API-Key überträgt noch nichts. Daten fließen erst, wenn eine Funktion tatsächlich einen Request an den Provider schickt – dann aber Beitragsinhalte, Prompts oder Bilder. Beim Gartenblog egal, bei Arztpraxis oder Shop mit Kundendaten in Bestellnotizen nicht. AVV mit dem Anbieter, Datenschutzerklärung – das gehört in die Übergabedoku, bevor jemand aus Neugier eine Funktion einschaltet. Ich bin kein Jurist, das ist nur die Reihenfolge, in der ich das mache.

Wer eigene Plugins für Kunden baut: Abilities API dieses Jahr mal anschauen. Die Plugin-Landschaft wird sich auf den AI Client umstellen, und das ist gut – jedes SEO-Plugin und jeder Page-Builder mit eigenem KI-Modul und eigenem Key-Feld war nicht haltbar.

Was auf die Staging-Testliste gehört

Der Admin-Umbau und die KI-Themen bekommen die Aufmerksamkeit. Probleme entstehen an anderen Stellen.

PHP-Minimum 7.4

7.0 hebt von 7.2.24 auf 7.4.0. Wer darunter liegt, kann nicht auf 7.0 aktualisieren und bleibt zunächst auf dem 6.9-Branch; Security-Fixes werden nach Möglichkeit zurückportiert. Klingt harmlos, ist aber ein Symptom: PHP 7.4 ist seit November 2022 EOL. Zwei Bestandskunden auf altem Shared Hosting hatte ich genau da stehen. Beide jetzt auf 8.3, beide haben eine Stunde Kompat-Test bezahlt.

Zum Kontext: PHP 8.2 ist zum 31.12.2026 EOL, 8.6 ist für den 19. November geplant. Neuprojekte übergebe ich mit 8.4 oder 8.5.

bash

wp cli info | grep "PHP version"
# oder
php -v

Der Post-Editor ist jetzt immer ein iframe (7.1)

Der Punkt, der in Sekundärquellen am häufigsten falsch dargestellt wird – ich hatte es in der ersten Fassung dieses Artikels auch falsch. Also genau:

6.9: Warnung in der Konsole (mit SCRIPT_DEBUG) für Blöcke mit apiVersion ≤ 2.
7.0: Editor läuft im iframe, wenn alle im Beitrag eingefügten Blöcke apiVersion 3+ haben. Ein alter Block drin → iframe wird still entfernt. Kompatibilitäts-Fallback.
7.1: Fallback weg. Der Editor ist immer ein iframe, egal welche apiVersion.

Was das nicht heißt: Blöcke mit apiVersion 2 sind nicht automatisch kaputt. Sie laufen im iframe weiter. Was kaputt geht, ist Code, der aus dem Editor-Script heraus mit document oder window auf den Canvas zugreift – der schaut jetzt ins falsche Dokument. Auch vw/vh und Media Queries beziehen sich jetzt auf den Canvas, nicht aufs Browserfenster.

Ein apiVersion-Bump repariert solchen Code nicht. Er ist trotzdem sinnvoll, weil das Schema nur noch Version 3 validiert. Zum Finden der Kandidaten:

bash

# Blöcke mit alter API-Version
grep -rn '"apiVersion": [12]' wp-content/plugins/ wp-content/themes/ --include=block.json

# Verdächtige DOM-Zugriffe in Editor-Scripts
grep -rn "document\.\(querySelector\|getElementById\|body\)\|window\.\(innerWidth\|scrollY\)" \
  wp-content/plugins/*/src wp-content/themes/*/src 2>/dev/null

Treffer aus dem ersten grep priorisiert auf Staging öffnen. Treffer aus dem zweiten anschauen, ob sie den Canvas meinen – dann ownerDocument des Block-Elements nutzen oder über die Editor-APIs gehen. Für Styles: editorStyle in der block.json bzw. add_editor_style() ist der saubere Weg, der wird in den iframe injiziert. Ryan Welcher hat ein Demo-Plugin mit kaputten und reparierten Beispielen veröffentlicht, das ist die beste Testbasis, die ich kenne.

Bei mir: drei eigene Blöcke aus 2021. Alle drei liefen im iframe, einer hatte im Editor die Styles verloren, weil ich sie über enqueue_block_editor_assets geladen hatte statt über editorStyle. Zehn Minuten.

jQuery UI 1.14.2 (7.1)

Bump von 1.13.3 auf 1.14.2, jQuery.uiBackCompat ist aktiviert. Entfernt wurden unter anderem $.fn._form, $.ui.ie, $.ui.safeActiveElement, $.ui.safeBlur sowie IE/Legacy-Edge-Support. Das bricht nichts von selbst. Es ist ein Testpunkt für Code, der interne APIs oder eigene UI-Stylings nutzt.

bash

grep -rn "jquery-ui-" wp-content/plugins/ wp-content/themes/ wp-content/mu-plugins/ | grep -v node_modules

Bei mir hat es ein Buchungs-Plugin erwischt. Datepicker im Admin ging nicht mehr auf. Fix vom Hersteller nach drei Tagen. Mit Staging: drei Tage warten. Ohne: drei Tage keine Termine anlegen.

Server-seitige Block-Registrierung (7.0) – positiv

Einfache, serverseitig gerenderte Blöcke und Patterns gehen jetzt komplett in PHP, mit autoRegister, ohne JS-Build. Für „Kunde braucht einen Hinweiskasten mit Icon“ muss ich keinen Webpack-Build mehr ins Projekt ziehen. Für stark interaktive Blöcke ist das nicht gedacht. Dazu mal ein eigener Artikel.

Was für Kunden tatsächlich besser wird

Bildverarbeitung im Browser (7.1) – mit Einschränkungen. Bisher: Upload → PHP → GD/ImageMagick → alle Sub-Sizes auf dem Server. Daher die Memory-Fehler bei großen Handyfotos und die ewige „memory_limit hochsetzen“-Empfehlung. In 7.1 übernimmt das in unterstützten Browsern eine WebAssembly-Version von libvips (wasm-vips) in einem Web Worker: Skalieren, Sub-Sizes, Format-Konvertierung passieren vor dem Upload. HEIC vom iPhone wird unterwegs konvertiert. Abgebrochene Uploads werden wiederholt. big_image_size_threshold und image_editor_output_format werden respektiert.

Die Einschränkungen sind real:

Browser	WASM-Pipeline
Chrome / Edge ≥ 137	ja
Firefox	nein
Safari	nein (HEIC-Fallback per Canvas funktioniert)

Dazu: mehr als 2 GB Gerätespeicher, und die Pipeline läuft nur im Block-Editor. Die Media-Library-Grid-Ansicht lädt weiter klassisch über async-upload.php. Wer nicht passt, bekommt still den Server-Weg. Die WASM-Binaries werden erst beim ersten Upload nachgeladen, nicht mit dem Editor.

Für den Kundenalltag heißt das: Der Redakteur mit Chrome am Desktop merkt den Unterschied bei großen Fotos deutlich. Der Kunde mit Safari am Mac merkt nichts. Ich sage das inzwischen bei der Übergabe dazu, sonst kommt die Frage „bei meinem Kollegen geht das aber schneller“.

Neu ist auch das Media-Editor-Modal: Zuschneiden (frei oder mit Seitenverhältnis), Drehen, Spiegeln, Metadaten – in einem Dialog statt im alten Inline-Cropper. Das sehen Kunden sofort.

Responsive- und Hover-Styles ohne CSS (7.1). Kleinere Schrift auf Mobil, Hover-Farbe auf dem Button – bisher Custom CSS oder Page-Builder. Jetzt Einstellung, global oder pro Block. Breakpoints sind konfigurierbar; Default ist Mobile bis 480 px, Tablet bis 782 px:

json

{
  "settings": {
    "viewport": {
      "mobile": "600px",
      "tablet": "900px"
    }
  }
}

Für mich heißt das weniger Custom-CSS in Kundenprojekten, das ich in zwei Jahren wieder anfassen muss.

Sonstiges: Tabs-Block und Playlist-Block im Core. „Als dekorativ markieren“ für Bilder (a11y). Classic-Block bleibt im Inserter – das Ausblenden war gemerged und wurde am 7. Juli reverted, der Filter wp_classic_block_supports_inserter ist wieder weg. Begründung: soll durch Wahl obsolet werden, nicht durch Zwang. Finde ich richtig.

Meine Update-Routine

1. PHP prüfen        → < 7.4 geht nicht, < 8.2 will ich nicht übergeben
2. Plugins + Theme   → vor dem Core aktualisieren
3. Staging           → eigene Blöcke im Editor öffnen (iframe!)
                       jQuery-UI-Screens klicken
                       8-MB-Handyfoto hochladen, einmal mit Chrome, einmal mit Safari
                       Formulare absenden, bei Shops Testbestellung
4. Connectors        → leer? gut. Nicht leer? klären, wer das war
5. Kunde informieren → "Backend sieht anders aus"
6. Prod              → wp core update && wp core update-db
7. Durchklicken

Und wer mit 7.1 noch wartet: mindestens 7.0.4. Das ist ein Security-Release vom 12. August, WordPress empfiehlt das sofortige Update. Stand heute ist 7.1 die aktuelle Hauptversion. „Ich warte mit dem Major“ ist okay. „Ich bleibe auf 7.0.1, das läuft“ nicht.

Fazit

7.0 hat Fundamente gelegt (AI Client, Abilities, Admin, PHP-first-Blöcke). 7.1 hat fertig gebaut und mit der Browser-Bildverarbeitung – für die, deren Browser mitspielt – ein 15 Jahre altes Ärgernis entschärft. Echtzeit-Kollaboration fehlt weiter, und lieber spät als instabil.

Die Risiken liegen nicht im neuen Admin und nicht bei der KI. Sie liegen in Editor-Code, der aufs falsche document zeigt, in jQuery-UI-Abhängigkeiten und vergessenen PHP-Versionen. Also da, wo sie immer lagen.

Zwei Sachen für die Liste: alle eigenen Blöcke im iframe testen und auf apiVersion: 3 bringen, und einmal in Ruhe die Abilities API lesen. Das eine ist Pflicht, das andere wird es.

Primärquellen

Überblicksartikel (Sekundärquellen, nur zur Orientierung)