Zum Inhalt

Beispielarbeiten · Webseiten

WordPress-Updates mit Sicherung: kaputtes Update erkannt und zurückgenommen

Auf einer Test-Seite vor jedem Update Dateien und Datenbank gesichert, Updates einzeln eingespielt und geprüft; ein fehlerhaftes Plugin-Update wurde erkannt und aus der Sicherung zurückgenommen.

Musterarbeit (Demo), kein Kundenauftrag. Gebaut als Probeaufgabe mit erfundenen Beispieldaten; die Prüfzahlen unten stammen aus dem automatischen Prüflauf und sind nicht geschönt.

Was gebaut wurde

  • Vor jedem Update eine Sicherung von Dateien und Datenbank, das Archiv wird auf Lesbarkeit geprüft
  • Updates einzeln, danach die wichtigen Seiten und das Fehlerprotokoll geprüft
  • Ein kaputtes Update (kritischer Fehler) wird sofort aus der Sicherung zurückgenommen, die Seite läuft wie vorher
  • Bericht mit Versionen vorher/nachher und Grund je Rücknahme; Seite und Plugin erfunden

wartungsbericht.md herunterladen

Wie geprüft wurde

Automatischer Prüflauf vom 31.10.2026, aus dem Protokoll (Testdaten erfunden, Zahlen gemessen):

  • Wartungslauf lokal: Sicherung (wp-content + DB, ZIP heil) vor jedem Update, Update 1.0.0->1.1.0 behalten, kaputtes 1.2.0 (Fatal, HTTP 500) erkannt und automatisch zurueckgenommen, Ausgabe danach gleich, DB-Ruecknahme bewiesen, Monatsbericht
  • 13/13 Pruefungen gruen
Alle Prüffälle (13 von 13 grün)
  • ✓ inventur vorher
  • ✓ sicherung 1 heil mit db
  • ✓ update 1 behalten
  • ✓ update 1 wirkt
  • ✓ beitrag nach sicherung da
  • ✓ update 2 fehler erkannt
  • ✓ ruecknahme seite 200
  • ✓ ruecknahme version 1 1 0
  • ✓ ruecknahme ausgabe gleich
  • ✓ beitrag nach sicherung 3 erhalten
  • ✓ db ruecknahme aus sicherung 2
  • ✓ ein eintrag je update
  • ✓ bericht vollstaendig

Grenzen

Was diese Probe nicht abdeckt, steht hier, damit niemand mehr erwartet:

  • lokal mit SQLite und php -S; beim Kunden laeuft derselbe Ablauf per WP-CLI ueber SSH/Hosting-Konsole oder mit seinem Hosting-Backup - das braucht seinen Zugang; die Datenbank wird dort mit 'wp db …
  • Updates offline aus ZIP-Dateien; Core-Updates und Updates von wordpress.org wurden nicht live gezogen
  • geprueft wird HTTP-Status und Fatal im Protokoll je Seite; ein optischer Fehler ohne Fatal (verschobenes Layout) braucht zusaetzlich die gerenderte Pruefung (wp_theme_anpassen)
  • Premium-Plugins brauchen den Lizenzschluessel des Kunden; keine Malware-Entfernung, keine Reparatur nach Hack

Der Wartungsbericht

# Wartungsbericht (Probe, erfundener Kunde)

## Versionen

| Teil | vorher | nachher |
|---|---|---|
| WordPress | 7.1.3 | 7.1.3 |
| oeffnungszeiten-pro | 1.0.0 | 1.1.0 |
| sqlite-database-integration | 3.1.0 | 3.1.0 |

## Sicherungen

- sicherung_1.zip: 13794533 Bytes, SHA-256 237943ea7cc309a3..., Datenbank enthalten: ja
- sicherung_2.zip: 13794543 Bytes, SHA-256 6cd5e560877de901..., Datenbank enthalten: ja
- sicherung_3.zip: 13794820 Bytes, SHA-256 4b4cace82525ab47..., Datenbank enthalten: ja

## Updates

- oeffnungszeiten-pro 1.0.0 -> 1.1.0: behalten, alle Seiten 200, kein Fehler im Protokoll
- oeffnungszeiten-pro 1.1.0 -> 1.2.0: ZURUECKGENOMMEN aus sicherung_3.zip. Grund: PHP Fatal error: Uncaught Error: Call to undefined function oz_feiertage_formatieren() in \wp-content\plugins\oeffnungszeiten-pro\oeffnungszeiten-pro.php:11. Danach: / HTTP 200, /zeiten/ HTTP 200. Empfehlung: Update erst nach Korrektur des Herstellers erneut einspielen.

So etwas für deinen Betrieb?

Beschreib kurz, was du brauchst. Du bekommst einen Festpreis, bevor ich anfange; ohne dein Ja passiert nichts.

Zur Werkstatt