WordPress-Updates
WordPress 7.0 ist seit dem 20. Mai 2026 der aktuelle Major. Die 7.0-Linie steht heute bei 7.0.4 vom 12. August 2026, und das ist bereits das dritte Sicherheitsrelease seit Mitte Juli. WordPress 7.1 erscheint am 19. August 2026, am letzten Tag der WordCamp US in Phoenix. Diese Seite behandelt einen einzigen Fall: Core, Plugins, Theme und PHP einer bestehenden Installation auf einen aktuellen Stand bringen, ohne dass danach der Editor leer bleibt oder das Kontaktformular schweigt. Ein Projekt mit Anfang und Ende, kein Wartungsvertrag. Die Sharpness Solutions GmbH entwickelt seit 1999 in Oldenburg und arbeitet bundesweit remote, auch an Installationen, die jemand anders gebaut hat. Stand dieser Seite: 17. August 2026.
Anfragen zu WordPress-Updates entstehen selten aus Interesse an neuen Funktionen. Sie entstehen, weil der Hoster einen PHP-Wechsel angekündigt hat, weil im Dashboard eine zweistellige Zahl an offenen Aktualisierungen steht, weil ein Sicherheitshinweis auf dem Tisch liegt oder weil das letzte Update einmal etwas kaputt gemacht hat und seitdem niemand mehr anfasst. Vier Ausgangslagen decken das meiste ab, womit Betreiber hier ankommen. Keine davon ist ungewöhnlich, und keine wird von allein besser.
Ein Plugin-Update im Dashboard, danach eine weiße Seite oder ein verschobenes Layout, zurückgeholt hat es jemand mit einem Backup. Seitdem wird nichts mehr angefasst. Der Effekt ist kumulativ: Je länger der Stillstand dauert, desto mehr Versionssprünge fallen gleichzeitig an, und desto schwerer lässt sich ein Fehler danach einem Verursacher zuordnen.
Minor-Releases aktualisiert WordPress seit Version 3.7 selbst. Allein in der 7.0-Linie kamen drei Sicherheitsreleases: 7.0.2 vom 17. Juli 2026, für das WordPress.org wegen der Schwere der Lücken erzwungene Auto-Updates aktivierte, 7.0.3 vom 6. August 2026 mit zwölf gemeldeten Lücken und 7.0.4 vom 12. August 2026. Auf vielen Installationen hat sich damit nachts mehrfach etwas geändert, das niemand getestet hat. Auf anderen ist der Mechanismus abgeschaltet — dort sind die Lücken bis heute offen.
Der Hoster kündigt den Wechsel auf eine neuere PHP-Version an, und plötzlich hängt das WordPress-Update an einem Termin, den jemand anders gesetzt hat. Umgekehrt genauso: Aktuelle Plugin-Fassungen verlangen ein PHP, das auf dem Server nicht läuft. Wer die Reihenfolge falsch wählt, hat entweder Fatal Errors oder gar keinen Weg nach vorn.
Aktiv sind mehrere Dutzend Plugins, gewachsen über Jahre und mehrere Dienstleister. Ein Teil davon hat seit Jahren kein Update bekommen, ein Teil ist kommerziell und auf den Namen der alten Agentur lizenziert, und bei einigen weiß niemand mehr, welche Funktion daran hängt. Das ist keine Nachlässigkeit, sondern der Normalfall — nur lässt sich ohne dieses Wissen keine Reihenfolge festlegen.
WordPress 7.0 erschien am 20. Mai 2026. Die 7.0-Linie steht heute bei 7.0.4 vom 12. August 2026, und der Weg dorthin gehört in die Lagebeurteilung. 7.0.1 vom 9. Juli 2026 war ein reines Wartungsrelease mit 31 Bugfixes in Core und Block-Editor. 7.0.2 vom 17. Juli 2026 war ein Sicherheitsrelease mit zwei Lücken — einer SQL-Injection und einer Verwechslung von Routen in der Batch-Verarbeitung der REST-API —, die verkettet zu Remote Code Execution führten; wegen der Schwere aktivierte WordPress.org erzwungene Auto-Updates für betroffene Installationen. 7.0.3 vom 6. August 2026 war ebenfalls ein Sicherheitsrelease, mit zwölf gemeldeten Lücken, darunter mehrere Stored-XSS-Fälle, eine SSRF in der URL-Validierung und ein Pre-Auth-XSS auf der Login-Seite. 7.0.4 vom 12. August 2026 schließt eine authentifizierte Remote Code Execution ab der Rolle Autor über einen Datei-Upload, die nur Installationen mit Imagick und Ghostscript trifft. WordPress 7.1 erscheint am 19. August 2026, parallel zur WordCamp US in Phoenix, die vom 16. bis 19. August läuft. Das ist der Rahmen, in dem sich jede Update-Planung dieses Sommers bewegt: eine 7.0-Linie mit drei Sicherheitsreleases in vier Wochen, und ein Major-Release, das in zwei Tagen verfügbar ist und dessen Bruchstellen bekannt sind.
Erzwungenes Update heißt konkret: Die Fassung wurde über denselben Mechanismus verteilt, mit dem WordPress seit Version 3.7 Minor-Releases automatisch einspielt — nicht nur im Dashboard zum Klicken angeboten. Daraus folgen zwei Dinge. Erstens ist die Lücke auf den meisten Installationen bereits geschlossen, ohne dass jemand etwas getan hat. Zweitens hat sich auf diesen Installationen etwas geändert, das niemand vorher auf einem Testsystem gesehen hat. Beides ist bemerkenswert, und der zweite Punkt ist der Grund, warum wir bei einer Bestandsaufnahme nie mit dem vermuteten Versionsstand arbeiten, sondern mit dem gemessenen. Nachsehen lässt sich das unter Dashboard → Aktualisierungen, über die Kommandozeile mit wp core version und wp core check-update. Wichtig ist der umgekehrte Fall: Wo AUTOMATIC_UPDATER_DISABLED gesetzt ist, wo ein Filter den Mechanismus abschaltet oder wo das Dateisystem für den Webserver nicht schreibbar ist, kommt auch ein erzwungenes Update nicht an. Solche Installationen stehen heute möglicherweise noch auf 7.0.0 oder 7.0.1 — genau die Fassungen der 7.0-Linie, die von den 7.0.2-Lücken betroffen waren — und haben seither zwei weitere Sicherheitsreleases verpasst. Die Fehler sind öffentlich beschrieben, die Patches liegen bereit.
Ein Punkt gehört an den Anfang, weil er teure Fehlplanungen verhindert: React 19 kommt nicht mit WordPress 7.1. Diese Annahme ist verbreitet, sie stand lange in Roadmaps und Vorträgen, und sie ist falsch. Das Upgrade wurde zurückgenommen, nachdem Inkompatibilitäten zwischen alter und neuer React-Fassung auftraten und dazu Probleme in der Art, wie Plugins React einbinden. WordPress 7.1 bleibt auf React 18.3. Gutenberg bietet ein experimentelles Flag, mit dem sich React 19 testen lässt — als Testmöglichkeit, nicht als Auslieferungszustand. Wer auf Basis der Ankündigung ein Plugin oder ein Editor-Interface auf React 19 umgestellt hat, hat Aufwand für einen Zustand betrieben, der nicht eintritt. Die Lehre daraus ist allgemeiner: Eine Roadmap ist eine Absicht. Budgetiert wird gegen Release-Notes und gegen einen Testlauf, nicht gegen einen Plan.
Die erste und weitreichendste Bruchstelle in WordPress 7.1 ist der Post-Editor: Er ist jetzt immer iframed — unabhängig vom Theme-Typ, von den Block-API-Versionen der registrierten Blöcke und von denen der Blöcke im Inhalt. Bisher war das eine Entscheidung je Beitrag: In 7.0 wurde der Editor iframed, wenn jeder eingefügte Block Block-API-Version 3 oder höher hatte, und fiel bei einem einzigen älteren Block auf die frühere Darstellung zurück. Diese Bedingung ist entfallen, und mit ihr die Annahme, ein klassisches Theme oder ein alter Block halte den Editor aus dem iframe heraus. Code, der auf globales document oder window zugreift, bricht damit — er sucht in einem Dokument, in dem der Editor-Inhalt nicht mehr liegt. Der Weg führt über ownerDocument und defaultView an einem Element im Canvas: Man greift ein Element innerhalb des Editors, fragt dessen ownerDocument ab und arbeitet mit diesem Dokument beziehungsweise mit dessen defaultView statt mit den globalen Objekten; für Event-Listener am Canvas empfiehlt das Core-Team useRefEffect, damit Registrierung und Aufräumen zusammenbleiben. Betroffen sind in der Praxis Skripte an Meta-Boxen, eigene Editor-Erweiterungen, Custom-Field-Lösungen, TinyMCE-Anpassungen und alles, was per document.querySelector in den Editor greift — auch dann, wenn es dort seit fünf Jahren zuverlässig funktioniert hat.
Die zweite Bruchstelle sitzt in den Listentabellen des Backends. Das führende th mit scope="row" wanderte von der Checkbox- in die Titelspalte. Das ist die erste Änderung an dieser Stelle seit 2010, und sie ist inhaltlich richtig, weil die Zeile durch ihren Titel identifiziert wird und nicht durch eine Auswahlbox. Für Erweiterungen ist sie trotzdem ein Bruch: Alles, was auf die CSS-Klasse check-column selektiert, greift ins Leere. Das betrifft eigene Spalten in Beitrags-, Seiten-, Medien- oder Benutzerlisten, Bulk-Aktionen, Sortierlogik und Backend-CSS, das die Spaltenbreiten korrigiert. Die dritte Änderung ist kleiner und fällt dafür sofort auf: Die Eigenschaft __next40pxDefaultSize ist wirkungslos geworden, Formularelemente rendern unbedingt mit 40 px. Auch __next40pxDefaultSize={false} führt nicht mehr zurück auf die früheren 36 px — die Eigenschaft gehört ersatzlos aus dem Code. Wer damit in Sidebar-Panels, Block-Einstellungen oder eigenen Metaboxen ein kompaktes Layout gebaut hat, sieht danach ein anderes Layout — nicht kaputt, aber verschoben, und in engen Panels reicht das für Überlappungen.
Diese drei Punkte haben eine Gemeinsamkeit, die für die Abnahme entscheidend ist: Sie liegen im Backend, nicht im Frontend. Ein Aufruf der Startseite nach dem Update zeigt keinen davon. Sie zeigen sich, wenn eine Redakteurin einen Beitrag öffnet und speichert, wenn jemand ein Bild in die Mediathek zieht, wenn in einer Listentabelle eine eigene Spalte gebraucht wird. Deshalb steht auf unserer Abnahmeliste nicht „Seite lädt", sondern eine Reihe von Backend-Wegen mit echten Inhalten. Und deshalb ist 7.1 kein Pflichttermin am 19. August: Sicherheitsreleases innerhalb der 7.0-Linie spielen wir zeitnah ein, der Sprung auf 7.1 folgt nach einem Testlauf. Dazu gehört die Einschränkung, die WordPress selbst in jedes Sicherheitsrelease schreibt: Aktiv unterstützt ist nur die jeweils neueste Fassung, die Fixes für ältere Linien liefert das Projekt ausdrücklich als Kulanz. Ein Verbleib auf 7.0 ist damit eine Frist, kein Zustand. Wer beides gleich behandelt, verwechselt Dringlichkeit mit Aktualität.
In einem guten Teil der Fälle ist nicht WordPress der Grund, warum ein Update nicht geht, sondern PHP. Der Zusammenhang ist eine Klemme: Aktuelle Plugin- und Theme-Fassungen setzen eine PHP-Version voraus, die auf dem Server nicht läuft; ein PHP-Sprung wiederum bringt alten Plugin-Code zum Absturz. Wer PHP zuerst hebt, bekommt Fatal Errors aus Erweiterungen, die noch nicht soweit sind. Wer die Plugins zuerst hebt, bekommt Requirement-Fehler oder ein Composer-Setup, das nicht auflöst. Die Zahlen dazu sind hart und öffentlich: PHP 7.4 bekommt seit dem 28. November 2022 keine Sicherheitsupdates mehr, PHP 8.1 seit dem 31. Dezember 2025. PHP 8.2 wird noch bis zum 31. Dezember 2026 mit Sicherheitsfixes versorgt, PHP 8.3 bis zum 31. Dezember 2027, PHP 8.4 bis zum 31. Dezember 2028. Wer im Sommer 2026 auf 8.2 als Zielversion plant, plant die nächste Migration für dasselbe Jahr. Zielversion ist bei uns deshalb 8.3 oder 8.4, nicht der kleinste Sprung, der gerade funktioniert.
Geprüft wird das gemessen, nicht gelesen. Die Angabe „Requires PHP" im Plugin- oder Theme-Header ist ein Hinweis, keine Zusage — sie wird nicht überall gepflegt, und sie sagt nichts darüber, ob der Code auf der Zielversion Warnungen produziert. Belastbar ist ein Durchlauf auf einer Staging-Kopie mit der Zielversion und einem Log, das Deprecations mitschreibt: einmal durch das Backend, einmal durch die relevanten Frontend-Wege, einmal durch die Cronjobs. Was dabei typischerweise auffällt, ist nicht exotisch. Dynamische Eigenschaften sind seit PHP 8.2 deprecated, was ältere Plugin-Klassen zuverlässig trifft, solange sie kein #[\AllowDynamicProperties] tragen. Falsche Argumenttypen, die PHP 7 als Warnung durchgelassen hat, werfen in PHP 8 einen TypeError und beenden den Request. Und Bibliotheken, die ein Plugin mitbringt, statt sie über Composer zu beziehen, altern unbemerkt mit — sie stehen in keiner Update-Liste. Das 7.0.4-Beispiel zeigt, warum die Laufzeitumgebung mit auf die Liste gehört: Die dort geschlossene Lücke betrifft nur Installationen, auf denen Imagick zusammen mit Ghostscript arbeitet. Ob das bei Ihnen der Fall ist, steht nicht im WordPress-Dashboard, sondern in der PHP-Konfiguration.
Wenn der Termin vom Hoster kommt, ist die Reihenfolge fremdbestimmt, und dann gilt eine andere Priorität: erst die Staging-Kopie auf die Zielversion heben, dort die Plugin- und Theme-Seite nachziehen, dann live umschalten — nicht umgekehrt. Ein angekündigter PHP-Wechsel beim Hoster ist der häufigste Auslöser dafür, dass ein liegengebliebenes Update plötzlich ein Termin ist. Wir betreiben WordPress-Installationen auch auf eigenen Servern in Deutschland, auf Proxmox-PVE-Clustern; dort ist der PHP-Wechsel ein vereinbarter Termin und keine Mitteilung. Ein Umzug ist aber keine Bedingung: Wenn SSH-Zugang, ein sauberer Deployment-Weg und eine wählbare PHP-Version vorhanden sind, arbeiten wir auf Ihrem Hosting.
Minor-Releases aktualisiert WordPress seit Version 3.7 automatisch, Plugins und Themes seit Version 5.5 auf Wunsch. Das ist keine Notlösung, sondern die richtige Voreinstellung für einen bestimmten Fall: Core-Minor innerhalb einer Linie. Der Änderungsumfang ist klein, innerhalb der Linie bricht keine API, und nach der Veröffentlichung eines Sicherheitsfixes ist der Angriffsdruck messbar höher als das Risiko eines ungetesteten kleinen Sprungs. Wer diesen Mechanismus abschaltet, übernimmt damit die Pflicht, Sicherheitsreleases wie 7.0.2, 7.0.3 und 7.0.4 selbst und zeitnah zu bemerken — drei Stück zwischen Mitte Juli und Mitte August. Das ist eine legitime Entscheidung, wenn ein Prozess dahintersteht. Ohne Prozess ist sie einfach nur eine offene Lücke mit Vorsatz.
Bei Plugins ist die Antwort nicht pauschal, sondern eine Liste. Automatisch sinnvoll sind Erweiterungen ohne Frontend-Ausgabe und ohne Eingriff in Templates: Backend-Hilfen, Verwaltungswerkzeuge, kleine Ergänzungen ohne eigene Datenstrukturen. Nicht sinnvoll ist Automatik überall dort, wo ein Update fachlich ein Deployment ist — in Formularen mit Mailversand, in Zahlungs- und Bestellprozessen bei WooCommerce, in allem, was Templates überschreibt, und in allem, was am Editor hängt. Der Grund ist einfach: Ein automatisches Update prüft, ob es durchläuft. Es prüft nicht, ob die Seite danach richtig aussieht und ob das Formular noch eine Mail verschickt. Der Unterschied zwischen „läuft ohne Fehler" und „tut das Richtige" ist genau der Teil, den eine Maschine nicht abnimmt.
Was bei aktivierter Automatik trotzdem liegen bleibt, ist der teurere Teil: der Sprung auf einen neuen Major wie 7.1, Themes mit eigenem Code, die PHP-Version, verwaiste Plugins ohne Nachfolger. Dazu kommt ein Konflikt, der in gewachsenen Projekten regelmäßig übersehen wird: Updates aus dem Dashboard und ein Git-basiertes Deployment schließen sich gegenseitig aus. Was im Dashboard aktualisiert wird, landet nicht im Repository und wird beim nächsten Deployment überschrieben — im besten Fall fällt das sofort auf, im schlechteren Fall kommt eine gepatchte Fassung still zurück auf den alten Stand. Genau so verliert eine Installation ein erzwungenes Sicherheitsupdate wieder. Wir legen deshalb vorher fest, welcher Weg gilt: Core-Minor automatisch, Plugin-Automatik nach einer begründeten Liste, alles mit eigenem Code über Git und Staging. Und eine Automatik ohne funktionierende Backup-Kette richten wir nicht ein. Das wäre ein Risiko mit Zeitschaltuhr.
Am Anfang steht ein Plugin- und Theme-Inventar, und es ist mehr als eine Liste von Namen. Darin stehen je Erweiterung: installierte Version, Quelle (wordpress.org, kommerziell, Eigenentwicklung, unbekannt), auf wen die Lizenz ausgestellt ist, wann sie zuletzt aktualisiert wurde, ob sie im Frontend sichtbar ist und ob sie an einem Geschäftsprozess hängt. Daraus ergeben sich vier Klassen: aktuell, veraltet aber gepflegt, verwaist, und ersetzbar durch ein paar Zeilen im Theme. Die härteste Frage ist dabei nicht, ob es ein Update gibt, sondern ob die Erweiterung noch gebraucht wird. Erfahrungsgemäß fällt bei diesem Schritt ein nennenswerter Teil der Liste weg — nicht weil wir aufräumen wollen, sondern weil niemand mehr eine Funktion benennen kann, die daran hängt. Jedes Plugin, das nicht mitkommt, ist ein Plugin, das nie wieder bricht. Ein Werkzeug dafür ist wp plugin list --update=available; die Bewertung macht es nicht.
Dann die Reihenfolge, und die ist nicht verhandelbar. Erstens: Backup von Datenbank und Dateien, mit einem Rückweg, den jemand schon einmal gegangen ist. Zweitens: eine Staging-Kopie, die tatsächlich eine Kopie ist — URLs ersetzt, Mailversand abgeklemmt, Indexierung gesperrt, Zahlungsanbindungen auf Sandbox, Cronjobs kontrolliert. Ein Staging, das echte Bestellbestätigungen an echte Kunden schickt, ist ein zweites Produktivsystem. Drittens: PHP auf die Zielversion, mit Deprecation-Log. Viertens: Plugins einzeln oder in kleinen Gruppen mit Zwischenprüfung. Fünftens: der Core. Sechstens: Theme und eigener Code, hier landen die 7.1-Punkte — iframed Editor, check-column, 40 px. Siebtens: Abnahme. Achtens: das Live-Fenster. Der Grund für die Kleinteiligkeit in Schritt vier ist Diagnostik, nicht Vorsicht: Wer zwei Dutzend Plugins in einem Zug aktualisiert und danach einen Fehler hat, hat zwei Dutzend Verdächtige und keine Spur.
Rückweg heißt bei uns: Datenbank-Dump und Dateistand unmittelbar vor dem Fenster, und ein geprobter Weg zurück. Dabei gehört eine unangenehme Einschränkung offen dazu. Datenbank-Migrationen einzelner Plugins sind nicht immer umkehrbar. Der Rückweg ist dann ein Restore auf den Stand vor dem Fenster, kein Downgrade — und alles, was zwischen Dump und Restore passiert ist, an Bestellungen, Kommentaren, Formulareingängen oder redaktionellen Änderungen, ist damit weg. Genau deshalb liegt das Fenster außerhalb der Geschäftszeiten und ist kurz, und genau deshalb steht vorher eine Abnahmeliste: Beitrag anlegen und speichern, Medien-Upload, Formularversand mit echter Mail, Suche, Feeds, Objekt-Cache, Backend-Listen mit eigenen Spalten, Rechte der Redaktionsrollen. Und wenn sich beim Inventar zeigt, dass eine zentrale Erweiterung keinen Nachfolger hat, sagen wir das vor dem Angebot: Dann ist das Update kein Update mehr, sondern ein kleines Entwicklungsprojekt. Das macht die Zahl größer, und es ist trotzdem die ehrlichere Zahl. Wer die Pflege danach nicht selbst übernehmen will, findet die laufende Betreuung samt Service-Level-Staffel unter WordPress-Wartung; diese Seite endet mit dem Go-Live.
Ablauf
Die Ausgabe von wp core version und wp plugin list genügt, notfalls auch nur die URL. Sie bekommen eine schriftliche Einschätzung: gemessener Versionsstand, Zielversion für PHP, die Plugins, die nicht mitkommen, und der Aufwandsrahmen — auch dann, wenn Sie danach woanders beauftragen. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr, info@sharpness.de. Wir arbeiten bundesweit remote, Termine im Nordwesten nach Absprache.
Wir sehen nach, was tatsächlich läuft: Core-Version bis zur Patch-Stelle — zwischen 7.0.1 und 7.0.4 liegen drei Sicherheitsreleases —, PHP- und Datenbankversion, Theme-Herkunft, ob und wie automatische Updates aktiv sind, ob ein Git-Repository und ein Deployment-Weg existieren. Bei erzwungenen Sicherheitsupdates weicht der gemessene Stand oft vom erwarteten ab, in beide Richtungen. Das Ergebnis bekommen Sie schriftlich.
Jede Erweiterung einzeln: Version, Quelle, Lizenzinhaber, letztes Update, sichtbare Funktion, Rolle im Geschäftsprozess. Daraus entsteht die Einteilung in aktuell, gepflegt aber veraltet, verwaist und verzichtbar. Hier fällt in der Regel ein Teil der Liste weg, und hier zeigt sich, ob der Sprung auf 7.1 ein Update oder ein Entwicklungsschritt ist.
Wir spiegeln die Installation in eine Testumgebung: URLs ersetzt, Mailversand abgeklemmt, Indexierung gesperrt, Zahlungsanbindungen auf Sandbox, Cronjobs kontrolliert. Fehlt bei Ihnen bisher ein Staging, ist das der erste bleibende Gewinn des Projekts — jedes weitere Update wird damit billiger als dieses.
Auf der Kopie zuerst die PHP-Zielversion mit mitlaufendem Deprecation-Log, dann Plugins einzeln oder in kleinen Gruppen mit Zwischenprüfung, dann der Core. Danach der eigene Code: iframed Editor über ownerDocument und defaultView, Selektoren auf check-column, Layouts, die auf __next40pxDefaultSize gesetzt haben.
Sie prüfen am Staging gegen eine Abnahmeliste, die Backend-Wege enthält und nicht nur Seitenaufrufe: Beitrag speichern, Medien-Upload, Formular mit echter Mail, Suche, Feeds, Backend-Listen, Redaktionsrollen. Der Go-Live läuft in einem vereinbarten Fenster außerhalb der Geschäftszeiten, mit Dump und Dateistand unmittelbar davor und dokumentiertem Rückweg.
Nach dem Umschalten beobachten wir Logs und Mailversand, arbeiten die Punkte aus der Abnahme nach und übergeben den Stand: Versionsliste, Konfiguration der automatischen Updates, Deployment-Weg, was bewusst nicht mitgekommen ist. Danach die offene Frage, wer die nächsten Release-Zyklen bedient — Ihr Team oder wir.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Aktueller Major ist WordPress 7.0, erschienen am 20. Mai 2026. Aktuell innerhalb dieser Linie ist 7.0.4 vom 12. August 2026, ein Sicherheitsrelease gegen eine authentifizierte Remote Code Execution ab der Rolle Autor, die Installationen mit Imagick und Ghostscript trifft. Davor 7.0.3 vom 6. August 2026 mit zwölf gemeldeten Sicherheitslücken, 7.0.2 vom 17. Juli 2026 mit erzwungenen Auto-Updates und 7.0.1 vom 9. Juli 2026 mit 31 Bugfixes. WordPress 7.1 erscheint am 19. August 2026, parallel zur WordCamp US in Phoenix. Stand dieser Angabe: 17. August 2026.
Im Backend steht die Version unter Dashboard → Aktualisierungen und rechts unten auf der Dashboard-Startseite. Genauer und schneller geht es über die Kommandozeile: wp core version liefert den exakten Stand, wp core check-update sagt, was ansteht. Verlassen Sie sich nicht auf den erwarteten Wert. Nach einem erzwungenen Sicherheitsupdate wie 7.0.2 ist die Installation oft weiter als gedacht — und wenn der automatische Update-Mechanismus abgeschaltet oder das Dateisystem nicht schreibbar ist, steht sie deutlich zurück. Vergleichswert ist heute 7.0.4. Beide Fälle kommen vor, und beide ändern die Planung.
Nein. Das ist ein verbreiteter Irrtum, weil das Upgrade lange angekündigt war. Es wurde zurückgenommen, nachdem Inkompatibilitäten zwischen alter und neuer React-Fassung auftraten und dazu Probleme in der Art, wie Plugins React einbinden. WordPress 7.1 bleibt auf React 18.3. Gutenberg bietet ein experimentelles Flag, mit dem sich React 19 testen lässt — als Testmöglichkeit, nicht als Auslieferungszustand. Wer sein Plugin vorsorglich auf React 19 umgestellt hat, hat für einen Zustand gearbeitet, der nicht eintritt. Planen Sie gegen Release-Notes, nicht gegen Roadmaps.
Drei Punkte, alle im Backend. Erstens: Der Post-Editor ist jetzt immer iframed — unabhängig vom Theme-Typ und von den Block-API-Versionen. In 7.0 entschied das noch der Inhalt: Nur wenn jeder eingefügte Block API-Version 3 oder höher hatte, war der Editor iframed. Code, der auf globales document oder window zugreift, bricht; der Weg führt über ownerDocument und defaultView an einem Element im Canvas. Das trifft Meta-Box-Skripte, Custom-Field-Lösungen, TinyMCE-Anpassungen und eigene Editor-Erweiterungen. Zweitens: In den Listentabellen wanderte das führende th mit scope="row" von der Checkbox- in die Titelspalte — die erste Änderung daran seit 2010. Erweiterungen, die auf die CSS-Klasse check-column selektieren, brechen. Drittens: Die Eigenschaft __next40pxDefaultSize ist wirkungslos, Formularelemente rendern unbedingt mit 40 px; auch __next40pxDefaultSize={false} holt die früheren 36 px nicht zurück. Das verschiebt enge Panel-Layouts.
Es bedeutet, dass die Fassung über denselben Weg verteilt wurde, mit dem WordPress seit Version 3.7 Minor-Releases automatisch einspielt — nicht nur im Dashboard angeboten. Bei 7.0.2 vom 17. Juli 2026 war das der Fall: Zwei Lücken ließen sich zu Remote Code Execution verketten, deshalb aktivierte WordPress.org erzwungene Auto-Updates für betroffene Installationen. Für Betreiber folgt daraus zweierlei: Die Lücke ist auf den meisten Installationen bereits geschlossen, ohne dass jemand etwas getan hat, und auf denselben Installationen hat sich etwas geändert, das niemand vorher getestet hat. Wo der Mechanismus abgeschaltet ist oder das Dateisystem für den Webserver nicht schreibbar ist, kam das Update nicht an. Dort sind die Lücken bis heute offen, obwohl die Patches seit Wochen existieren — inzwischen die aus drei Sicherheitsreleases.
Für Core-Minor-Releases ja. Der Änderungsumfang innerhalb einer Linie ist klein, es bricht keine API, und nach der Veröffentlichung eines Sicherheitsfixes ist der Angriffsdruck höher als das Testrisiko. Drei Sicherheitsreleases zwischen Mitte Juli und Mitte August 2026 sind das praktische Argument dafür. Für Plugins und Themes — automatisch möglich seit WordPress 5.5 — lautet die Antwort: nach Liste. Sinnvoll bei Erweiterungen ohne Frontend-Ausgabe und ohne Eingriff in Templates. Nicht sinnvoll bei Formularen mit Mailversand, bei WooCommerce im Bestell- und Zahlungsweg, bei allem, was Templates überschreibt, und bei allem, was am Editor hängt. Ein automatisches Update prüft, ob es durchläuft — nicht, ob die Seite danach das Richtige tut.
Weil beide Seiten voneinander abhängen. Aktuelle Plugin- und Theme-Fassungen setzen eine neuere PHP-Version voraus, und ein PHP-Sprung bringt alten Erweiterungscode zum Absturz. PHP 7.4 bekommt seit dem 28. November 2022 keine Sicherheitsupdates mehr, PHP 8.1 seit dem 31. Dezember 2025. PHP 8.2 wird bis 31. Dezember 2026 versorgt, 8.3 bis 31. Dezember 2027, 8.4 bis 31. Dezember 2028. Wir zielen deshalb auf 8.3 oder 8.4, nicht auf den kleinsten Sprung, der gerade läuft. Geprüft wird das auf einer Staging-Kopie mit mitlaufendem Deprecation-Log, nicht anhand der Angabe „Requires PHP" im Plugin-Header. Und die Serverkonfiguration gehört mit auf die Liste: Die in 7.0.4 geschlossene Lücke trifft nur Installationen, auf denen Imagick zusammen mit Ghostscript arbeitet.
Nach Aufwand, und der Aufwand hängt an vier zählbaren Größen: Ausgangsversion von Core und PHP, Anzahl und Zustand der Plugins, Umfang des eigenen Codes in Theme und Erweiterungen, und Zahl der Erweiterungen ohne aktuelles Release. Drei davon können Sie selbst zählen — die Version über wp core version, die Plugins über wp plugin list, den eigenen Code über einen Blick in das Theme-Verzeichnis. Eine Zahl vor dem Inventar wäre geraten. Eine Preisliste gibt es nicht, weil ein Durchschnittspreis bedeutet, dass Sie den Aufwand fremder Projekte mitbezahlen. Wenn sich das Update in Ihrem Fall nicht rechnet, weil ein Neubau günstiger ist, sagen wir das.
Während der Arbeit gar nicht: Gearbeitet wird auf einer Staging-Kopie, die produktive Installation läuft unverändert weiter. Nicht erreichbar ist die Seite nur im Umschaltfenster, üblicherweise außerhalb der Geschäftszeiten. Unmittelbar davor ziehen wir Datenbank-Dump und Dateistand, damit ein Rückweg dokumentiert und geprobt ist. Redaktionelle Änderungen, die während der Umbauphase im Livesystem entstehen, ziehen wir vor dem Umschalten nach — deshalb ist es sinnvoll, den Termin früh zu kennen.
Nein. Sicherheits- und Wartungsreleases innerhalb der 7.0-Linie spielen Sie zeitnah ein — die schließen bekannte Lücken und brechen innerhalb der Linie nichts. Der Sprung auf 7.1 ist ein eigener Vorgang mit Testlauf, weil er drei bekannte Bruchstellen mitbringt: den immer iframed Post-Editor, die verschobene scope="row"-Spalte in den Listentabellen und die wirkungslose Eigenschaft __next40pxDefaultSize. Alle drei liegen im Backend und fallen bei einem Aufruf der Startseite nicht auf. Ein Punkt gehört zur Ehrlichkeit dazu: WordPress unterstützt aktiv nur die jeweils neueste Fassung und liefert Fixes für ältere Linien ausdrücklich als Kulanz. Auf 7.0 zu bleiben ist deshalb eine Frist, kein Dauerzustand. Wer Dringlichkeit und Aktualität gleich behandelt, aktualisiert entweder zu spät oder zu unvorsichtig.
Es gibt drei Wege, und die Reihenfolge ist immer dieselbe. Erstens: streichen, wenn niemand mehr eine Funktion benennen kann, die daran hängt — das trifft bei gewachsenen Installationen einen nennenswerten Teil der Liste. Zweitens: ersetzen durch eine gepflegte Alternative oder durch ein paar Zeilen im Theme, wenn die Funktion klein ist. Drittens: den Code übernehmen und selbst weiterpflegen, wenn die Funktion zentral ist und kein Ersatz existiert. Der dritte Weg ist ein Entwicklungsprojekt mit eigenem Aufwand, und das sagen wir vor dem Angebot. Kommerzielle Plugins bringen eine vierte Frage mit: Auf wen ist die Lizenz ausgestellt? Läuft sie auf die alte Agentur, gibt es kein Update, egal ob der Hersteller eines veröffentlicht hat.
Meistens ja, aber nicht als ein Klick. Der Core lässt sich in einem Sprung heben; die Arbeit liegt bei Plugins, Theme und PHP, und dort summieren sich mehrere Jahre Versionsabstand. Praktisch bedeutet das: Inventar, Staging, PHP zuerst, dann Plugins in kleinen Gruppen mit Zwischenprüfung, dann der Core, dann der eigene Code. Wer stattdessen alles in einem Zug aktualisiert und danach einen Fehler hat, hat keine Spur, sondern eine Verdächtigenliste. Und wenn dabei herauskommt, dass Theme und halbe Plugin-Liste ohnehin ersetzt werden müssen, stellen wir die Zahl für den Neubau daneben — auch wenn das Update der kleinere Auftrag wäre.
Ja, das ist bei Update-Anfragen der Normalfall. Gebraucht werden ein Administrator-Zugang zum Backend, SSH- oder SFTP-Zugang zum Server, Datenbankzugang und, falls vorhanden, das Git-Repository sowie die Lizenzen kommerzieller Plugins. Fehlt Dokumentation, ist das kein Ausschlusskriterium — undokumentierter Code ist der Regelfall. Wir dokumentieren den vorgefundenen Zustand und lassen ihn bestätigen, damit später unterscheidbar bleibt, was wir vorgefunden und was wir verursacht haben. Finden wir dabei Spuren einer Kompromittierung, ist das kein Update-Fall mehr, sondern eine saubere Neuaufsetzung mit eigenem Angebot.
Für dieses Projekt nicht — es endet mit dem Go-Live und der Übergabe. Für die Zeit danach ist die Frage berechtigt, weil der nächste Zyklus kommt: Minor-Releases, Plugin-Updates, die nächste PHP-Frist. Drei Sicherheitsreleases in vier Wochen sind kein Ausnahmesommer, sondern der Normalbetrieb. Wenn Sie das abgeben wollen, regelt eine Service-Level-Vereinbarung die Reaktionszeit — BASIC 24 Stunden, STANDARD 8 Stunden, ADVANCED 4 Stunden, PREMIUM 2 Stunden, als Monatspauschale netto je Projekt. Ohne Vereinbarung gilt bei uns die Bearbeitung in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten Mo–Fr 9:00–16:00 Uhr. Was zur laufenden Pflege gehört und was nicht, steht auf der Seite zur WordPress-Wartung.
Anfrage
Beschreiben Sie kurz die Lage. Wenn Sie den Versionsstand nicht kennen, ist das kein Problem — genau das ist der erste Schritt. Sie bekommen eine schriftliche Einschätzung, bevor über einen Auftrag gesprochen wird.