WordPress Bilder nach Backup-Restore nicht auswählbar – Object Cache als versteckte Fehlerquelle

Nach dem Einspielen eines vollständigen WordPress-Backups trat ein ungewöhnlicher Fehler auf: Bereits vorhandene Bilder funktionierten weiterhin problemlos. Neu hochgeladene Bilder erschienen in der Mediathek, ließen sich aber nicht mehr als Beitragsbild (Featured Image) zuweisen. Der Upload selbst schien zu funktionieren – Datei vorhanden, Thumbnails generiert, Mediathek aktualisiert. Nur die Verwendung schlug still und kommentarlos fehl.

Dieser Fall ist ein gutes Beispiel dafür, warum WordPress-Fehler nach einem Restore nicht immer dort liegen, wo man sie zuerst vermutet.

Das Fehlerbild im Detail

Die betroffene Installation hatte folgende Eigenschaften: WPML (Mehrsprachigkeit), EWWW Image Optimizer, persistentes Object Caching (Redis oder Memcached) und eine komplexe Seitenstruktur mit mehreren tausend Beiträgen. Nach dem vollständigen Restore verhielt sich die Website auf den ersten Blick vollkommen normal:

• Beiträge und Seiten vorhanden ✓
• Alte Bilder als Featured Image nutzbar ✓
• Neue Dateien hochladbar ✓
• Thumbnails wurden generiert ✓
• Mediathek öffnete sich korrekt ✓

Aber: Neu hochgeladene Bilder konnten nicht als Beitragsbild gesetzt werden. Die Mediathek zeigte sie an, die Auswahl schlug ohne Fehlermeldung fehl.

Die Fehlersuche – Schicht für Schicht

Schritt 1: Browser-Konsole und JavaScript

Der erste Verdacht bei einem stumm scheiternden Upload-Dialog liegt immer im Frontend: JavaScript-Fehler, blockierte Requests, fehlerhafte REST-API-Antworten. Ein Blick in die Browser-Konsole zeigte keine relevanten Fehler. Die REST-API antwortete, der Upload-Prozess lief durch.

Schritt 2: WordPress-Debug-Log

Mit aktiviertem WP_DEBUG und WP_DEBUG_LOG zeigten sich Notices von WPML, Rank Math und einigen Plugins – deprecation warnings, kleinere Inkompatibilitäten. Auffällig, aber keiner dieser Hinweise erklärte das konkrete Fehlverhalten beim Bild-Upload.

Schritt 3: Attachment-Postmeta direkt prüfen

Der entscheidende Hinweis kam beim direkten Blick auf die Postmeta eines neu hochgeladenen Attachments:

wp post meta get 130562 _wp_attached_file wp post meta get 130562 _wp_attachment_metadata

_wp_attachment_metadata war vorhanden – Breite, Höhe, generierte Bildgrößen, alles korrekt gespeichert. _wp_attached_file fehlte vollständig. WordPress hatte also die technischen Bilddaten gespeichert, aber die Verknüpfung zwischen Attachment-Objekt und Dateipfad war nicht gelandet.

Das war der erste konkrete Treffer: nicht die Datei, nicht die Thumbnails, nicht die Datenbank als Ganzes – sondern die Zuordnung zwischen Attachment-ID und Dateipfad.

Schritt 4: WPML und EWWW ausschließen

Da WPML bei Medien-Uploads Duplikate anlegt (je ein Attachment pro Sprache), bestand der Verdacht, dass die Sprachzuordnung die Meta-Zuordnung störte. Beide betroffenen Attachments – das englische Original und das deutsche Duplikat – zeigten das gleiche Fehlbild: _wp_attached_file fehlte bei beiden.

EWWW Image Optimizer wurde testweise deaktiviert. Der Fehler blieb. WordPress Core selbst wurde per wp core verify-checksums geprüft – keine Abweichungen.

Schritt 5: Den Upload-Prozess direkt protokollieren

Um zu verstehen, was während des Uploads tatsächlich passierte, wurde der Prozess intern geloggt. Das Ergebnis war eindeutig:

WP_HANDLE_UPLOAD file=/uploads/2026/08/bild.png UPDATE_ATTACHED_FILE ID=130596 file=/uploads/2026/08/bild.png UPDATE_META ID=112921 ← falsche ID value=2026/08/bild.png ADD_ATTACHMENT ID=130596 attached_file='' ← leer

Der Upload gehörte zu Attachment ID 130596. Der Dateipfad wurde aber auf Post ID 112921 geschrieben – ein völlig anderes, bereits bestehendes Objekt. Das neue Attachment blieb ohne Dateipfad. WordPress arbeitete während des Schreibvorgangs mit einer falschen Objektreferenz.

Die Ursache: Datenbank-Restore trifft persistenten Object Cache

Damit war der Mechanismus klar. Die Installation verwendete einen persistenten Object Cache – Redis oder Memcached. Bei einem vollständigen WordPress-Restore wird die Datenbank auf einen älteren Stand zurückgesetzt. Der persistente Object Cache wird dabei nicht automatisch geleert.

Das erzeugt einen inkonsistenten Zustand:

• Die Datenbank enthält den älteren Stand
• Der Object Cache enthält noch Objekte aus dem neueren Stand – mit höheren Post-IDs, anderen Objektzuordnungen
• WordPress greift beim Schreiben neuer Daten auf gecachte Objekte zurück, die nicht mehr zur aktuellen Datenbankstruktur passen
• Neue Attachment-IDs kollidieren mit gecachten Objektdaten alter IDs
• Metadaten werden auf falsche Objekte geschrieben

Das Gefährliche an diesem Zustand: Die Website wirkte vollständig funktionsfähig. Alte Inhalte waren korrekt. Neue Uploads liefen technisch durch. Erst beim Verwenden der neuen Attachments wurde die Inkonsistenz sichtbar – und auch dann nur indirekt, ohne Fehlermeldung.

Die Lösung: persistenten Object Cache leeren

Nach dem vollständigen Leeren des persistenten Object Cache wurde ein neues Bild hochgeladen:

wp cache flush # Anschließend Upload testen: wp post meta get 130599 _wp_attached_file # Ergebnis: 2026/08/bild.jpg ✓

Das Bild konnte sofort als Featured Image gesetzt werden. Der Fehler war vollständig behoben.

Bei Redis-Object-Cache kann der Flush je nach Konfiguration auch direkt auf Redis-Ebene erfolgen:

# Redis-CLI direkt (alle Daten der aktuellen Datenbank) redis-cli FLUSHDB # Oder selektiv für WordPress-Keys (bei konfigurierbarem Prefix) redis-cli --scan --pattern "wp_*" | xargs redis-cli DEL

Wichtig: Bei Memcached gibt es kein selektives Flush. wp cache flush ist hier der richtige Weg, da WordPress nur seinen eigenen Namespace leert.

Was dieser Fall über WordPress-Restores lehrt

Ein vollständiger WordPress-Restore umfasst üblicherweise Dateisystem und Datenbank. Bei Installationen mit persistentem Object Caching gehört der Cache-Flush zwingend dazu – er wird aber von keinem gängigen Backup-Plugin automatisch ausgeführt.

Die Checkliste für einen vollständigen Restore auf Produktivsystemen sollte daher enthalten:

1. Dateisystem wiederherstellen (wp-content, ggf. Core-Dateien)
2. Datenbank einspielen (vollständiges SQL-Dump)
3. Persistenten Object Cache leeren – Redis FLUSHDB oder wp cache flush
4. Opcode-Cache leeren – OPcache Reset via PHP oder Webserver-Reload
5. Page Cache leeren – Cache Enabler, WP Super Cache, Nginx FastCGI Cache
6. Funktionstest – neue Inhalte erstellen, nicht nur bestehende prüfen

Punkt 6 ist dabei besonders wichtig: Ein Restore-Test, der nur prüft ob vorhandene Seiten laden, erkennt diesen Fehlertyp nicht. Erst das Erstellen neuer Inhalte – Beitrag, Bild, Menüeintrag – zeigt ob die Datenbank-Cache-Konsistenz stimmt.

Warum das bei komplexen Installationen häufiger vorkommt

Einfache WordPress-Installationen ohne persistenten Object Cache sind von diesem Problem nicht betroffen. wp_cache_set() und wp_cache_get() landen dann im PHP-internen Memory-Cache, der bei jedem Request neu aufgebaut wird.

Bei Installationen mit Redis oder Memcached hingegen überleben Cache-Einträge den PHP-Prozess. Das ist gewollt und erhöht die Performance erheblich – aber es bedeutet auch, dass ein Datenbankstand-Wechsel (Restore, Migration, manuelle SQL-Operationen) ohne Cache-Flush inkonsistente Zustände erzeugen kann.

Besonders anfällig sind Installationen mit:

• WPML: Sprachzuordnungen, Attachment-Duplikate und Element-Translations werden intensiv gecacht
• WooCommerce: Produkt-Meta, Session-Daten und Transients landen im Object Cache
• Page Buildern: Elementor und WPBakery nutzen eigene Cache-Strukturen auf Basis von Postmeta
• großen Mediatheken: Attachment-Metadaten werden aggressiv gecacht, da diese Queries teuer sind

Fazit: stille Fehler sind die gefährlichsten

Der beschriebene Fehler – WordPress Featured Image nach Backup-Restore nicht auswählbar – hatte keine offensichtliche Fehlermeldung. Kein PHP-Fatal-Error, kein 500, kein Debug-Log-Eintrag der direkt auf die Ursache zeigte. Die Website wirkte gesund.

Das ist charakteristisch für Cache-Inkonsistenz-Probleme: Sie äußern sich als seltsames Verhalten, das sich nicht reproduzieren lässt, intermittierend auftritt oder nur bei bestimmten Aktionen sichtbar wird. Der diagnostische Schlüssel ist in solchen Fällen immer der direkte Blick auf die Datenbankwerte – nicht auf die gecachte Ausgabe.

Für Unternehmen und Agenturen, die WordPress-Systeme mit persistentem Caching betreiben: Ein Cache-Flush nach jedem Restore ist kein optionaler Schritt. Er ist Teil des Restore-Prozesses. Bei Fragen zu Performance, Caching-Architektur oder Serveroptimierung für WordPress-Systeme: Leistungsübersicht und Kontaktmöglichkeiten.

---

Häufige Fragen

Warum funktionieren alte Bilder nach einem Restore, aber keine neuen?
Alte Attachments haben ihre Metadaten korrekt in der wiederhergestellten Datenbank. Neue Uploads werden während des Schreibvorgangs durch den inkonsistenten Object Cache auf falsche Post-IDs umgeleitet. Die bestehenden Daten im Cache passen noch zum alten Datenbankstand, neue Schreiboperationen geraten in Konflikt mit gecachten Objektzuordnungen.

Welche WordPress-Caches müssen nach einem Restore geleert werden?
Mindestens: persistenter Object Cache (Redis/Memcached via wp cache flush oder redis-cli FLUSHDB), OPcache (opcache_reset() oder Webserver-Reload) und der Page Cache des eingesetzten Caching-Plugins. Browser-Cache und CDN-Cache sind optional, aber empfehlenswert.

Wie erkenne ich ob meine WordPress-Installation einen persistenten Object Cache nutzt?
In wp-content/ nach einer Datei object-cache.php suchen. Deren Vorhandensein bedeutet, dass WordPress einen externen Object Cache (Redis, Memcached) verwendet. Alternativ: wp cache type via WP-CLI.

Ist das Problem auf bestimmte Backup-Plugins beschränkt?
Nein. Das Problem entsteht grundsätzlich bei jedem vollständigen Datenbankwechsel ohne anschließenden Cache-Flush – unabhängig vom verwendeten Backup-Tool. UpdraftPlus, Duplicator, ManageWP und alle anderen Lösungen betreffen dies gleichermaßen, da keines dieser Tools den externen Object Cache automatisch leert.

Kann dieser Fehler auch bei anderen WordPress-Aktionen auftreten?
Ja. Datenbankmigrationen, manuelle SQL-Operationen, Multisite-Umstellungen und Staging-zu-Production-Transfers können denselben inkonsistenten Zustand erzeugen, wenn dabei keine Cache-Invalidierung erfolgt.

---

Autor: Manuel Kuhn, WordPress Performance Engineer & Serveradministrator, Hosting-Fixers.de – August 2026