Kurz und einfach erklärt
WordPress bekommt bald eine neue große Version. Sie heißt 7.2. Sie soll am 8. Dezember kommen. Das ist mitten im Weihnachtsgeschäft.
Manche Shops holen sich neue Versionen von selbst. Im Dezember kann das Ärger machen. Prüfen Sie vorher, wie Ihr Shop eingestellt ist.
Testen Sie die neue Version zuerst auf einer Kopie Ihres Shops. Bringen Sie sie erst nach dem Fest in den echten Shop.
Updates gegen Lücken sind etwas anderes. Die spielen Sie sofort ein. Auch im Dezember.
Wir helfen dabei. Wir testen die neue Version vorher. Wir spielen sie ein, wenn Sie zustimmen.
WordPress 7.2 soll am 8. Dezember 2026 erscheinen (Make WordPress Core), als letzte Hauptversion des Jahres. Für einen Shop auf WordPress-Basis liegt dieser Termin mitten in den beiden Monaten, auf die im Einzelhandel 18,5 Prozent des Jahresumsatzes entfallen (HDE), und wenige Tage nach Black Friday und Cyber Monday. Die erste Beta ist für den 20. Oktober angesetzt, sieben Wochen vor der Veröffentlichung. Diese Zeit reicht, um das Update in Ruhe auf einer Testkopie zu prüfen, wenn jetzt jemand damit anfängt. Der Beitrag zeigt, wie Sie herausfinden, ob Ihr Shop sich am 8. Dezember von allein aktualisiert, wie ein Test ab Beta 1 aussieht und warum Sicherheitsupdates und Hauptversion im Dezember zwei getrennte Entscheidungen sind. Am Ende steht ein Plan, der bis in den Januar reicht.
Das Wichtigste in Kürze
- WordPress 7.2 ist für den 8. Dezember 2026 geplant (Make WordPress Core), Beta 1 für den 20. Oktober und RC1 für den 17. November. Der Termin fällt in die Monate, auf die 18,5 Prozent des Jahresumsatzes im Einzelhandel entfallen (HDE).
- Seit WordPress 5.6 aktualisieren sich neu installierte Seiten standardmäßig auch auf Hauptversionen (WordPress Developer Resources). Oberfläche, Konstante WP_AUTO_UPDATE_CORE und Hoster-Automatik gehören vor dem 8. Dezember geprüft.
- Beta und Release Candidate gehören auf eine Staging-Kopie, nicht in den Live-Shop: Checkout mit jeder Zahlart, Versand, Bestellmails und eigene Erweiterungen ab 20. Oktober testen und mit RC1 am 17. November wiederholen.
- Sicherheitsupdate und Major-Update getrennt entscheiden: Sicherheitsreleases wie 7.1.3 mit 7 Sicherheitskorrekturen (WordPress.org News) sofort einspielen, 7.2 vor dem 8. Dezember testen und erst nach der Hochphase live nehmen.
- Der Plan reicht bis Januar: 7.2 im Wartungsfenster mit frischer Sicherung einspielen, nicht in derselben Woche wie den PHP-Wechsel, und die Zurückstellung mit Grund dokumentieren, wie es der BSI IT-Grundschutz für nicht eingespielte Patches verlangt.
Was für WordPress 7.2 geplant ist
Den Zeitplan führt das Core-Team auf einer eigenen Projektseite. Beta 1 ist für den 20. Oktober 2026 vorgesehen (Make WordPress Core). Danach folgen im Wochentakt Beta 2 bis Beta 4 am 27. Oktober, 3. November und 10. November (Make WordPress Core). Am 17. November soll der erste Release Candidate erscheinen, zusammen mit dem Field Guide, der alle Entwicklerhinweise der Version bündelt (Make WordPress Core). Zwei weitere Release Candidates sind für den 24. November (Make WordPress Core) und den 1. Dezember 2026 (Make WordPress Core) eingeplant, am 7. Dezember ein Probelauf mit einem Code-Freeze von 24 Stunden (Make WordPress Core). Einen Tag später soll WordPress 7.2 veröffentlicht werden.
Dieselbe Seite hält fest, dass 7.2 die letzte Hauptversion des Jahres 2026 wird (Make WordPress Core). Der Planungsvorschlag vom Dezember 2025 hatte für 2026 wieder drei Hauptversionen vorgesehen, ungefähr eine alle vier Monate (Make WordPress Project). 7.0 und 7.1 sind erschienen, 7.2 schließt die Reihe. Für den Wartungsplan eines Shops ergeben sich daraus diese Phasen:
| Termin (geplant) | Stufe | Was der Shop in dieser Phase tut |
|---|---|---|
| 20. Oktober | Beta 1 | Staging-Kopie auf die Beta heben, Kernabläufe des Shops testen |
| 27. Oktober bis 10. November | Beta 2 bis Beta 4 | Gefundene Fehler nachtesten, Rückmeldungen der Erweiterungshersteller sammeln |
| 17. November | RC1 mit Field Guide | Entwicklerhinweise lesen, vollständigen Testlauf auf dem Release Candidate wiederholen |
| 24. November | RC2 | Freigabeliste abschließen, Autoupdate-Einstellung festlegen |
| 27. bis 30. November | Black Friday bis Cyber Monday | Keine Änderungen außer Sicherheitsupdates, Bereitschaft halten |
| 1. und 7. Dezember | RC3 und Probelauf | Letzte Änderungen der Erweiterungen einsammeln, nichts live nehmen |
| 8. Dezember | Release 7.2 | Staging auf die finale Version heben, der Live-Shop bleibt auf 7.1.x |
| Januar 2027 | nach der Hochphase | 7.2 im Wartungsfenster mit frischer Sicherung einspielen |
Warum der Termin so spät im Jahr liegt, erklärt der Planungsvorschlag selbst: Das Datum für 7.2 sei das am wenigsten verschiebbare der drei, weil frühere Termine mit Black Friday, Cyber Monday und Giving Tuesday kollidieren und spätere zu nah an die großen Feiertage und die freien Tage zum Jahresende rücken (Make WordPress Project). Das Projekt weicht also bewusst den Aktionstagen aus, nicht aber dem Weihnachtsgeschäft. Neu ist das nicht: WordPress 6.9 erschien am 2. Dezember 2025 (WordPress.org Releases), einen Tag nach dem Cyber Monday, der 2025 auf den 1. Dezember fiel (HDE).
Alle Termine sind geplant, nicht zugesagt. Wie weit Plan und Veröffentlichung auseinanderliegen können, zeigt das laufende Jahr. Der Vorschlag nannte für WordPress 7.0 den 9. April (Make WordPress Project), erschienen ist 7.0 am 20. Mai 2026 (WordPress.org Releases). WordPress 7.1 kam dagegen wie geplant am 19. August 2026 (WordPress.org Releases). Ein Wartungsplan, der am 8. Dezember hängt, braucht deshalb Puffer und jemanden, der den Zeitplan bis zur Veröffentlichung verfolgt und die eigenen Termine nachzieht, wenn sich etwas verschiebt.
Warum der Termin mitten in die Hochphase fällt
November und Dezember sind für den Handel die Monate mit dem größten Gewicht. Nach dem Handelsverband Deutschland entfallen 18,5 Prozent des Jahresumsatzes im Einzelhandel auf die letzten beiden Monate des Jahres (HDE). Für den Online-Handel prognostizierte der Verband für die Weihnachtszeit 2025 einen Umsatz von 22,2 Milliarden Euro (HDE). Für die beiden Aktionstage Black Friday und Cyber Monday rechnete er 2025 mit 5,8 Milliarden Euro Umsatz (HDE). In diesen Wochen kostet jede Störung im Checkout mehr als im Februar, und sie trifft ein Team, das mit Bestellungen, Versand und Kundenanfragen ohnehin ausgelastet ist. Wie ein Änderungsstopp für diese Zeit aufgebaut wird, beschreibt Änderungsstopp im Wartungsplan vor dem Weihnachtsgeschäft.
Ein Major-Update ist genau die Art Änderung, die in dieser Phase stört. Hauptversionen bringen neue Funktionen, Änderungen im Editor und neue Programmierschnittstellen; Wartungsversionen beheben Fehler und Sicherheitslücken. Das Plugin-Verzeichnis von WordPress zieht daraus selbst eine Konsequenz: Die Readme-Angabe, bis zu welcher Version eine Erweiterung getestet ist, ignoriert Minor-Versionen, weil Erweiterungen an einem Minor-Update nicht brechen sollten (WordPress Plugin Handbook). Umgekehrt heißt das: Wenn eine Erweiterung bricht, dann vor allem an einer Hauptversion. Bei einem Shop sind das nicht nur die Shop-Erweiterung selbst, sondern auch Zahlungs- und Versandanbindungen, Rechnungs- und Rechtstext-Module, Filter, Suche und das Theme.
Dazu kommt, dass sich eine Hauptversion bis kurz vor dem Termin noch deutlich bewegt. Für 7.1 meldete das Projekt zum ersten Release Candidate mehr als 145 Änderungen und Fehlerbehebungen allein seit Beta 4 (WordPress.org News). Wer im Oktober auf der Beta testet und danach nicht mehr, hat einen Stand geprüft, der so nicht erscheinen wird. Der Test ist deshalb kein einmaliger Termin, sondern eine Reihe, die mit dem Release Candidate endet.
Die Regel für den Dezember
Kommt 7.2 von allein?
Ob ein Shop am 8. Dezember ohne Zutun auf 7.2 springt, hängt davon ab, wie er installiert wurde und was seitdem eingestellt ist. Automatische Hintergrundupdates gibt es seit WordPress 3.7 (WordPress Developer Resources). Lange betrafen sie nur Wartungs- und Sicherheitsversionen. Seit WordPress 5.6 aktualisieren sich neu installierte Seiten standardmäßig auch auf neue Hauptversionen, sofern WordPress keinen Checkout einer Versionsverwaltung erkennt (WordPress Developer Resources). Ältere Installationen behalten ihr bisheriges Verhalten, bis jemand die automatischen Major-Updates in der Oberfläche, per Konstante oder per Filter einschaltet (WordPress Developer Resources).
Für einen Shop heißt das: Wer die Installation in den vergangenen Jahren neu aufgesetzt hat oder im Dashboard unter „Aktualisierungen“ die automatischen Updates für alle neuen Versionen eingeschaltet hat, kann 7.2 ohne weiteres Zutun erhalten, sobald es verteilt wird. Dann läuft das Major-Update mitten im Dezember, ohne Test auf Staging und ohne dass jemand bereitsteht.
Zwei weitere Stellen sind im Dashboard nicht sichtbar. Die Konstante WP_AUTO_UPDATE_CORE in der wp-config.php überschreibt die Einstellung, die Administratoren auf der Update-Seite wählen (WordPress Developer Resources). Und die Verwaltungsoberflächen mancher Hoster bringen eine eigene Update-Automatik für WordPress mit, die außerhalb von WordPress konfiguriert wird (WordPress Developer Resources). Wer welche Updates einspielt, gehört darum auch im Hosting-Vertrag geklärt; die Abgrenzung beschreibt Hoster oder Wartung: Wer im Shop was aktualisiert. Auf der Kommandozeile lässt sich der Stand mit wenigen WP-CLI-Befehlen erfassen:
# Installierte Version und verfügbare Updates des Kerns
wp core version
wp core check-update
# Ist die Konstante gesetzt? Eine Fehlermeldung heißt: nicht gesetzt
wp config get WP_AUTO_UPDATE_CORE
# Erweiterungen und Themes mit verfügbarem Update
wp plugin list --update=available
wp theme list --update=availableFür die Hochphase ist eine klare Einstellung besser als ein vergessener Haken. Der Wert minor lässt Wartungs- und Sicherheitsversionen des Kerns automatisch zu und schaltet Hauptversionen ab; true erlaubt alle Updates, false keines (WordPress Developer Resources). Mit minor bekommt der Kern seine Sicherheitsfixes weiter ohne Verzögerung, während 7.2 auf die Freigabe wartet:
// Wartungs- und Sicherheitsversionen automatisch,
// Hauptversionen erst nach Test und Freigabe
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Wer auch Minor-Updates lieber kontrolliert einspielt, wie es manche Wartungsverträge vorsehen, braucht dafür einen festen Eilweg mit Reaktionszeit. Sonst entsteht im Dezember genau die Lücke, die die Automatik schließen soll. Der BSI IT-Grundschutz verlangt ausdrücklich, für Autoupdate-Mechanismen festzulegen, wie mit ihnen umzugehen ist (BSI IT-Grundschutz). Eine Einstellung, die niemand bewusst gewählt hat, erfüllt das nicht.
Erweiterungen und Themes aktualisiert WordPress ohne eigene Einstellung nur in Sonderfällen automatisch, nämlich wenn das Sicherheitsteam für eine kritische Lücke eine Aktualisierung über die Schnittstelle von WordPress.org anstößt (WordPress Developer Resources). Wer alle Erweiterungs-Updates per Filter abschaltet, sperrt laut Dokumentation auch diese erzwungenen Sicherheitsupdates aus (WordPress Developer Resources). Für den Dezember ist das die falsche Richtung.
Seit WordPress 6.6 rollt der Kern ein automatisches Plugin-Update zurück, wenn es einen fatalen PHP-Fehler auslöst (Make WordPress Core). Erkannt wird der Fehler über eine Anfrage an die eigene Startseite (Make WordPress Core). Das schützt vor einer weißen Seite, nicht aber vor einem Checkout, der eine Zahlart verliert, vor falsch berechneten Versandkosten oder vor Bestellmails, die nicht mehr ankommen. Solche Fehler findet nur ein Test, der die Abläufe des Shops tatsächlich durchspielt; wie das im Alltag aussieht, steht in Update-Tests: Regressionen nach Shop-Updates vermeiden.
Beta 1 auf Staging testen, nicht live
Für Betas und Release Candidates gibt das Projekt eine klare Ansage: Sie sollen nicht auf Produktivseiten oder geschäftskritischen Websites installiert, betrieben oder getestet werden (WordPress.org News). Der richtige Ort ist eine Staging-Kopie, die dem Live-Shop in PHP-Version, Erweiterungen, Theme und Daten entspricht. Wie eine solche Umgebung aufgebaut wird und warum die Datenbankkopie anonymisiert gehört, beschreibt Staging-Umgebungen für sichere Shop-Updates.
Getestet wird nicht die Startseite, sondern der Weg des Geldes. Auf der Beta sollten mindestens diese Abläufe einmal vollständig durchlaufen:
- Warenkorb und Checkout bis zur Bestellbestätigung, mit jeder angebotenen Zahlart einschließlich der Rückmeldung des Zahlungsdienstes an den Shop
- Versandkostenberechnung, Steuerausweis und Gutscheine, auch für Lieferländer außerhalb Deutschlands
- Kundenkonto: Registrierung, Anmeldung, Passwort zurücksetzen und Bestellhistorie
- Bestell-, Versand- und Rechnungsmails sowie erzeugte Dokumente wie Rechnungen im PDF-Format
- Produktseiten, Filter und Suche, besonders Seiten mit eigenen Blöcken oder Vorlagen des Themes
- Bestellbearbeitung im Backend und die Schnittstellen zu Warenwirtschaft, Versand und Buchhaltung
- Geplante Aufgaben wie Lagerabgleich, Produktfeeds und Erinnerungsmails
Am meisten Aufmerksamkeit brauchen eigene Erweiterungen. Eine Erweiterung aus dem Plugin-Verzeichnis testen viele Betreiber und der Hersteller mit, eine individuell entwickelte Erweiterung niemand außer Ihnen. Schreibt sie eigene Blöcke, greift sie in den Editor ein oder nutzt sie interne Funktionen des Kerns, steigt das Risiko. Mit RC1 veröffentlicht das Projekt den Field Guide mit allen Entwicklerhinweisen der Version (Make WordPress Core). Er ist die Liste, gegen die eigene Erweiterungen geprüft werden, bevor die finale Version erscheint.
Für Erweiterungen von Drittanbietern ist die Readme-Angabe „Tested up to“ das öffentliche Signal. Zum ersten Release Candidate bittet das Projekt die Entwickler, ihre Tests abzuschließen und diese Angabe auf die neue Version zu setzen (WordPress.org News). Im Plugin-Verzeichnis erscheint ein Hinweis, wenn eine Erweiterung die letzten drei Hauptversionen nicht unterstützt (WordPress Plugin Handbook). Nach dieser Regel betrifft das nach dem Erscheinen von 7.2 jede Erweiterung, deren Readme höchstens 6.9 nennt. Eine solche Erweiterung ist nicht automatisch defekt, gehört aber vor dem Major-Update auf die Liste der Rückfragen an den Hersteller. Bei kostenpflichtigen Erweiterungen hängt das Update zudem häufig an einer gültigen Lizenz; wie man das vor der Hochphase klärt, steht in Lizenzfristen von Erweiterungen: Updates nicht verlieren.
Ein grüner Beta-Test ist keine Freigabe
Major-Update und Sicherheitsupdate getrennt entscheiden
Im Dezember laufen zwei Arten von Updates nebeneinander. Hauptversionen wie 7.2 erscheinen nach Plan; Wartungs- und Sicherheitsversionen erscheinen, wenn eine Lücke geschlossen werden muss. Seit 7.1 erschienen ist, kamen bis Anfang Oktober drei solcher Versionen: 7.1.1 am 17. September, 7.1.2 am 22. September und 7.1.3 am 6. Oktober 2026 (WordPress.org Releases). 7.1.2 schloss eine kritische Sicherheitslücke (WordPress.org News), 7.1.3 brachte 7 Sicherheitskorrekturen und 4 Fehlerbehebungen (WordPress.org News). Bei Sicherheitsreleases empfiehlt das Projekt, die Seiten sofort zu aktualisieren (WordPress.org News).
Daraus folgt eine einfache Trennung. Ein Sicherheitsupdate des Kerns oder einer Erweiterung wartet nicht auf das Ende der Hochphase, auch nicht in der Black Week. Der BSI IT-Grundschutz formuliert den Grundsatz nüchtern: Patches sollten zeitnah nach Veröffentlichung eingespielt werden (BSI IT-Grundschutz). Wie kurz das Fenster zwischen Bekanntwerden einer Lücke und den ersten Angriffen sein kann, zeigt der Beitrag zum Patch-Zeitfenster bei WordPress-Lücken. Ein Major-Update ist dagegen eine geplante Änderung mit neuen Funktionen. Für geplante Änderungen verlangt derselbe Baustein, die aktuelle Situation der betroffenen Geschäftsprozesse zu berücksichtigen (BSI IT-Grundschutz), und das Weihnachtsgeschäft ist genau so eine Situation.
| Update | Beispiel | Im Dezember | Begründung |
|---|---|---|---|
| Sicherheitsrelease des Kerns | 7.1.x, nach dem 8. Dezember auch 7.2.x | sofort, notfalls über den Eilweg | schließt bekannte Lücken, das Projekt empfiehlt sofortiges Aktualisieren |
| Sicherheitsupdate einer Erweiterung | Fix für eine gemeldete Lücke | sofort, nach Kurztest von Checkout und Zahlung | Angriffe auf bekannte Lücken warten nicht bis Januar |
| Wartungsversion ohne Sicherheitsbezug | reine Fehlerkorrekturen | nach Bewertung, im Wartungsfenster | Nutzen und Risiko je behobenem Fehler abwägen |
| Hauptversion des Kerns | WordPress 7.2 | testen ja, einspielen nach der Hochphase | neue Funktionen und Schnittstellen, Risiko für Erweiterungen |
| Funktionsupdate einer Erweiterung | neue Version mit neuen Funktionen | nach der Hochphase | ändert Abläufe ohne Sicherheitsnutzen |
Wer 7.2 bewusst zurückstellt, trifft eine Entscheidung, die festgehalten gehört. Der Grundschutz verlangt, dass bei einem nicht eingespielten Patch die Entscheidung und die Gründe dafür dokumentiert werden (BSI IT-Grundschutz). Eine Zeile im Wartungsplan reicht: Version, Grund, Termin für das Nachholen, verantwortliche Person. Wie wir Sicherheitsupdates nach Schweregrad priorisieren und einspielen, beschreibt die Seite Sicherheitsupdates.
Was ist, wenn ein Fix nur für 7.2 kommt?
Offiziell aktiv unterstützt wird nur die jeweils neueste WordPress-Version (WordPress.org News). Sicherheitsfixes gehen bisher zusätzlich als Gefälligkeit auf ältere Zweige, derzeit bis 4.7 (WordPress.org News), ohne Zusage für die nächste Lücke. Wie das im Einzelnen funktioniert, beschreibt WordPress-Sicherheitsupdates: Was alte Zweige noch bekommen. Für den Dezember heißt das: Ein paar Wochen auf 7.1.x sind vertretbar, solange jedes Sicherheitsrelease für 7.1 sofort eingespielt wird. Für den Fall, dass ein Fix nur für 7.2 erscheint, ist der Test vor dem 8. Dezember die Absicherung. Dann liegt eine geprüfte 7.2 bereit, und der Wechsel wird zum geplanten Eilweg statt zum Blindflug.
Der Plan bis Januar
Bis 19. Oktober: Bestand aufnehmen
Installierte Version, Autoupdate-Einstellung im Dashboard, Konstante in der wp-config.php und Automatik des Hosters erfassen. Eine Liste aller Erweiterungen mit Version, „Tested up to“ und Lizenzstatus anlegen und eigene Entwicklungen markieren.
20. Oktober bis 10. November: Beta auf Staging
Die Staging-Kopie auf Beta 1 heben und die Kernabläufe des Shops durchspielen. Fehler an die Hersteller melden und mit jeder weiteren Beta nachtesten.
17. November bis 1. Dezember: Release Candidate
Field Guide lesen, eigene Erweiterungen dagegen prüfen, den vollständigen Testlauf auf dem Release Candidate wiederholen. Spätestens jetzt die automatischen Major-Updates bis zur Freigabe aussetzen.
27. bis 30. November: Aktionstage
Nur Sicherheitsupdates über den Eilweg, sonst keine Änderungen. Bereitschaft, Ansprechpartner und Rückweg stehen fest.
8. Dezember: Release beobachten
Die Staging-Kopie auf die finale Version 7.2 heben und einen Kurztest fahren. Der Live-Shop bleibt auf 7.1.x und bekommt dessen Sicherheitsreleases sofort.
Januar: einspielen und zurückstellen
7.2 im Wartungsfenster mit frischer Sicherung und geprobtem Rückweg einspielen. Danach die Autoupdate-Einstellung auf den Normalbetrieb zurückstellen und den Eintrag im Wartungsplan schließen.
Installierte Version, Autoupdate-Einstellung im Dashboard, Konstante in der wp-config.php und Automatik des Hosters erfassen. Eine Liste aller Erweiterungen mit Version, „Tested up to“ und Lizenzstatus anlegen und eigene Entwicklungen markieren.
Die Staging-Kopie auf Beta 1 heben und die Kernabläufe des Shops durchspielen. Fehler an die Hersteller melden und mit jeder weiteren Beta nachtesten.
Field Guide lesen, eigene Erweiterungen dagegen prüfen, den vollständigen Testlauf auf dem Release Candidate wiederholen. Spätestens jetzt die automatischen Major-Updates bis zur Freigabe aussetzen.
Nur Sicherheitsupdates über den Eilweg, sonst keine Änderungen. Bereitschaft, Ansprechpartner und Rückweg stehen fest.
Die Staging-Kopie auf die finale Version 7.2 heben und einen Kurztest fahren. Der Live-Shop bleibt auf 7.1.x und bekommt dessen Sicherheitsreleases sofort.
7.2 im Wartungsfenster mit frischer Sicherung und geprobtem Rückweg einspielen. Danach die Autoupdate-Einstellung auf den Normalbetrieb zurückstellen und den Eintrag im Wartungsplan schließen.
Wann genau „nach der Hochphase“ ist, hängt vom Sortiment ab. Für viele Shops endet sie nicht am 24. Dezember: Gutscheineinlösungen, Umtausch und Retouren laufen bis in den Januar. Sinnvoll ist ein Termin, an dem der Shop erfahrungsgemäß ruhig ist und das Team erreichbar bleibt. Wie man ihn findet und den Shop währenddessen korrekt in den Wartungsmodus setzt, steht in Wartungsfenster: Shop-Updates ohne Umsatzausfall.
Ein zweiter Termin gehört in denselben Kalender. Die Sicherheitspflege für PHP 8.2 endet am 31. Dezember 2026 (The PHP Group). Wer seinen Shop noch auf 8.2 betreibt, hat im Januar zwei große Umstellungen vor sich. Beide in dasselbe Wartungsfenster zu legen, macht die Fehlersuche unnötig schwer: Bricht danach etwas, ist unklar, ob PHP oder WordPress die Ursache ist. Besser ist eine Reihenfolge mit Abstand, wie sie PHP-EOL-Management: Sichere Upgrades planen beschreibt.
Vor dem Einspielen steht eine frische, geprüfte Sicherung von Dateien und Datenbank. WordPress bietet im Dashboard keinen Weg zurück auf die vorherige Hauptversion; der verlässliche Rückweg ist die Sicherung, und zwar eine, deren Rücksicherung vorher einmal geprobt wurde. Wie Sicherungen eingerichtet, verschlüsselt abgelegt und regelmäßig zurückgespielt werden, beschreibt unser Backup-Service.
Was das für Wartung und Bereitschaft heißt
Die Entscheidungen aus diesem Beitrag lassen sich nicht einmal treffen und dann vergessen. Die Autoupdate-Einstellung wird vor dem Release umgestellt und im Januar zurückgestellt, Sicherheitsreleases müssen im Dezember notfalls auch an einem Wochenende eingespielt werden, und der Testlauf wiederholt sich mit jeder Beta. Das ist Arbeit für einen festen Wartungsplan mit klarer Zuständigkeit, nicht für den Moment, in dem die Update-Meldung im Dashboard erscheint. Der BSI-Grundschutz verlangt außerdem ein festgelegtes Verfahren, mit dem wichtige Änderungen beschleunigt werden können (BSI IT-Grundschutz). Für den Dezember ist das der Eilweg für Sicherheitsfixes.
In unserer WordPress-Wartung unterscheiden wir zwischen Minor-Updates mit Sicherheitsfixes und Major-Updates mit neuen Funktionen und behandeln sie unterschiedlich: Sicherheitsfixes spielen wir zeitnah ein, und jedes Update prüfen wir vorher auf einer Staging-Kopie. Automatische Updates ersetzen wir in der Regel durch kontrollierte, getestete Updates in definierten Wartungszyklen. Für den Dezember heißt das konkret: 7.2 prüfen wir vor dem Einspielen auf einer Staging-Kopie Ihres Shops, einschließlich Checkout, Zahlung und Suche, und eingespielt wird nach Ihrer Freigabe in einem abgestimmten Wartungsfenster. Reaktionszeiten für den Eilweg regelt der SLA-Wartungsvertrag, die laufende Überwachung von Erreichbarkeit und geschäftskritischen Funktionen wie dem Checkout übernimmt unser Monitoring.
Verwandte Artikel
Server-Logs im Shop: Wie lange IP-Adressen bleiben dürfen
Wie lange dürfen IP-Adressen in Server-Logs liegen? Was die DSGVO verlangt, was die fünf Wochen des BfDI bedeuten und wie Rotation, Kürzung und Backups wirken.
WordPress-Sicherheitsupdates: Was alte Zweige noch bekommen
WordPress 7.1.2 schloss eine kritische Lücke, der Fix kam als Gefälligkeit bis 4.7 zurück. Was ältere Zweige erhalten, was nicht und wann der Sprung fällig ist.
Rabattcodes in der Black Week: Missbrauch früh erkennen
Rabattcodes in der Black Week schützen: Codelänge, Rate-Limit am Gutscheinfeld, Alarm bei Fehlversuchen und ein Neukundenrabatt, der Mehrfachkonten standhält.