WordPress zeigt keine Plugin-Updates mehr an: So lässt sich die Ursache systematisch eingrenzen

Bei WordPress kann es vorkommen, dass für installierte Plugins plötzlich keine verfügbaren Updates mehr angezeigt werden. In der Plugin-Übersicht fehlt dann der Hinweis auf eine neue Version und damit auch der Button „Jetzt aktualisieren“.

Das Problem ist tückisch: Auf den ersten Blick sieht es so aus, als seien alle Plugins aktuell. Tatsächlich kann WordPress verfügbare Updates durchaus erkennen, die Informationen aber anschließend nicht korrekt speichern. Genau dieses Verhalten trat bei einer unserer WordPress-Installationen auf.

In unserem konkreten Fall war das Plugin Open Graph and Twitter Card Tags der Auslöser. Ein Update des Plugins beseitigte das Problem. Interessanter als die konkrete Ursache ist jedoch der Weg dorthin: Mit einigen gezielten Prüfungen lässt sich relativ genau feststellen, an welcher Stelle der WordPress-Updateprozess scheitert.

Dazu gab es in unserem Fall auf jeden Fall für Contactform 7 ein Update was jedoch nicht angezeigt wurde. Dieses wurde hier als Basis zur nähere Prüfung verwendet.

Dieser Beitrag zeigt die Diagnose Schritt für Schritt.

Typisches Fehlerbild

Das Problem kann beispielsweise so aussehen:

• Unter Plugins → Installierte Plugins werden keine verfügbaren Updates angezeigt.
• Der Button „Jetzt aktualisieren“ fehlt.
• Mehrere Plugins sind nachweislich nicht auf dem aktuellen Stand.
• Dashboard → Aktualisierungen → Erneut prüfen ändert nichts.
• Automatische Updates können eventuell weiterhin aktiviert oder deaktiviert werden.
• WordPress selbst funktioniert ansonsten normal.

Wichtig ist dabei die Unterscheidung zwischen zwei Funktionen.

Wenn in der Pluginliste beispielsweise steht:

Automatische Aktualisierungen deaktivieren

bedeutet das nicht, dass Updates grundsätzlich deaktiviert sind. Es bedeutet vielmehr, dass automatische Updates für dieses Plugin momentan aktiviert sind und über diesen Link deaktiviert werden könnten.

Fehlt dagegen bei einer vorhandenen neuen Plugin-Version der Hinweis „Jetzt aktualisieren“, hat WordPress das Update entweder nicht erkannt oder die Updateinformation geht auf dem Weg zur Pluginübersicht verloren.

Wie WordPress Plugin-Updates grundsätzlich ermittelt

Vereinfacht funktioniert die Updateprüfung so:

Installierte Plugins ermitteln
        ↓
Versionsinformationen an WordPress.org senden
        ↓
WordPress.org liefert verfügbare Updates
        ↓
WordPress verarbeitet die Antwort
        ↓
Updateinformationen werden gespeichert
        ↓
Pluginübersicht zeigt „Jetzt aktualisieren“

WordPress speichert diese Informationen in einem sogenannten Site Transient:

update_plugins

Darin befinden sich unter anderem drei interessante Bereiche:

checked
response
no_update

Bedeutung:

Bereich	Bedeutung
checked	Von WordPress geprüfte installierte Plugin-Versionen
response	Plugins, für die ein Update verfügbar ist
no_update	Plugins, für die kein Update verfügbar ist

Wenn beispielsweise Contact Form 7 installiert ist und ein Update verfügbar ist, sollte das Plugin sowohl unter checked als auch unter response auftauchen.

Genau hier lässt sich die Fehlersuche ansetzen.

Schritt 1: Prüfen, ob tatsächlich Updates fehlen

Zunächst sollte man sicherstellen, dass überhaupt ein Problem vorliegt.

Beispielsweise kann man bei einem Plugin aus dem offiziellen WordPress-Verzeichnis prüfen:

Installierte Version: 6.1.6
Aktuelle Version:     6.1.7

Wenn WordPress trotzdem kein Update anzeigt, stimmt etwas nicht.

Anschließend einmal:

Dashboard → Aktualisierungen → Erneut prüfen

ausführen.

Taucht das Update danach weiterhin nicht auf, lohnt sich eine technische Diagnose.

Schritt 2: WP-CLI verwenden

Für die folgenden Tests ist WP-CLI sehr hilfreich.

WP-CLI ist die Kommandozeilenschnittstelle von WordPress. Die Befehle werden per SSH im WordPress-Hauptverzeichnis ausgeführt.

Das richtige Verzeichnis erkennt man beispielsweise an:

wp-admin/
wp-content/
wp-includes/
wp-config.php
index.php

Mit

ls

kann man den Inhalt des aktuellen Verzeichnisses anzeigen.

Ob WP-CLI vorhanden ist, lässt sich testen mit:

wp --info

Schritt 3: Erkennt WordPress das Plugin überhaupt?

Als Erstes sollte geprüft werden, ob WordPress das betreffende Plugin korrekt als installiert erkennt.

Für Contact Form 7 beispielsweise:

wp eval '
require_once ABSPATH . "wp-admin/includes/plugin.php";
$p = get_plugins();

foreach ($p as $file => $data) {
    if (stripos($file, "contact-form-7") !== false) {
        echo $file . " -> " . $data["Version"] . PHP_EOL;
    }
}
'

Eine Ausgabe wie:

contact-form-7/wp-contact-form-7.php -> 6.1.6

zeigt:

WordPress erkennt das Plugin und dessen installierte Version korrekt.

Damit können Probleme mit Plugin-Verzeichnis, Dateiname oder Plugin-Header weitgehend ausgeschlossen werden.

Schritt 4: Den WordPress-Update-Transient untersuchen

Jetzt wird interessant, was WordPress über verfügbare Updates gespeichert hat.

Zum Beispiel:

wp eval '
$u = get_site_transient("update_plugins");

echo "checked_count: ";
echo count((array) ($u->checked ?? [])) . PHP_EOL;

echo "response_count: ";
echo count((array) ($u->response ?? [])) . PHP_EOL;

echo "no_update_count: ";
echo count((array) ($u->no_update ?? [])) . PHP_EOL;

echo "CF7 checked: ";
var_dump($u->checked["contact-form-7/wp-contact-form-7.php"] ?? "FEHLT");

echo "CF7 response: ";
var_dump(isset($u->response["contact-form-7/wp-contact-form-7.php"]));
'

In unserem Fehlerfall kam sinngemäß:

checked_count: 0
response_count: 0

CF7 checked: "FEHLT"
CF7 response: false

Das war bereits auffällig.

WordPress erkannte Contact Form 7 zwar als installiertes Plugin, aber im Update-Transient war es nicht vorhanden.

Schritt 5: Prüfen, ob WordPress.org erreichbar ist

Ein häufiger Verdacht ist zunächst:

Kann der Server WordPress.org überhaupt erreichen?

Das sollte getestet werden, bevor man Plugins oder Themes verdächtigt.

Ein direkter Test kann über wp_remote_post() erfolgen.

Im konkreten Fall antwortete:

https://api.wordpress.org/plugins/update-check/1.1/

mit:

HTTP STATUS: 200

und lieferte tatsächlich unter anderem:

contact-form-7/wp-contact-form-7.php
new_version: 6.1.7

Damit war klar:

WordPress.org kennt das Update und der Server kann die Update-API erreichen.

DNS, Firewall, SSL-Verbindung und ein grundsätzlicher Netzwerkfehler waren damit weitgehend ausgeschlossen.

Schritt 6: Die echte Anfrage von wp_update_plugins() beobachten

Noch aussagekräftiger ist es, die Anfrage zu beobachten, die WordPress selbst während wp_update_plugins() ausführt.

Dazu eignet sich der WordPress-Hook:

http_api_debug

Ein vereinfachter Diagnosetest:

wp eval '
add_action(
    "http_api_debug",
    function($response, $context, $class, $args, $url) {

        if (strpos($url, "api.wordpress.org/plugins/update-check/1.1/") === false) {
            return;
        }

        echo "URL: " . $url . PHP_EOL;
        echo "Timeout: ";
        var_dump($args["timeout"] ?? "FEHLT");

        if (is_wp_error($response)) {
            echo "ERROR: " . $response->get_error_message() . PHP_EOL;
        } else {
            echo "HTTP Status: " .
                wp_remote_retrieve_response_code($response) . PHP_EOL;

            echo "Body Length: " .
                strlen(wp_remote_retrieve_body($response)) . PHP_EOL;
        }
    },
    10,
    5
);

delete_site_transient("update_plugins");

$start = microtime(true);
wp_update_plugins();

echo "Dauer: " .
    round(microtime(true) - $start, 3) .
    " Sekunden" . PHP_EOL;
'

Bei uns ergab das:

HTTP Status: 200
Body Length: 11978
Dauer: 0.455 Sekunden

Damit war endgültig klar:

Die WordPress-Updateabfrage selbst funktioniert.

Der Fehler musste danach entstehen.

Schritt 7: Updateinformationen vor dem Speichern kontrollieren

WordPress verwendet für den Update-Transient unter anderem den Filter:

pre_set_site_transient_update_plugins

Damit lässt sich überprüfen, welche Daten WordPress unmittelbar vor dem Speichern besitzt.

Bei uns zeigte die Diagnose:

checked: 20
response: 4
no_update: 10

und konkret:

CF7 checked: "6.1.6"
CF7 response: true

Das war der entscheidende Wendepunkt.

WordPress hatte:

• 20 Plugins geprüft,
• vier Updates gefunden,
• Contact Form 7 korrekt als Version 6.1.6 erkannt,
• das Update von Contact Form 7 korrekt erkannt.

Die Update-Erkennung funktionierte also vollständig.

Trotzdem waren die Daten anschließend wieder verschwunden.

Schritt 8: Datenbankfehler sichtbar machen

Der nächste Schritt war deshalb, den tatsächlichen Datenbankfehler auszulesen:

global $wpdb;

echo $wpdb->last_error;

Dabei erschien:

Das Verarbeiten des Werts für das folgende Feld ist fehlgeschlagen: option_value. Der bereitgestellte Wert könnte zu lang sein oder ungültige Daten enthalten.

Damit war klar:

WordPress konnte den fertigen Update-Transient nicht in der Datenbank speichern.

Das erklärt das komplette Fehlerbild.

WordPress findet die Updates:

4 Updates gefunden

möchte sie speichern:

_site_transient_update_plugins

der Datenbankvorgang schlägt jedoch fehl.

Beim nächsten Aufruf fehlen die Informationen wieder.

Folge:

kein gespeichertes Update
        ↓
kein Update-Hinweis
        ↓
kein „Jetzt aktualisieren“-Button

Schritt 9: wp_options.option_value prüfen

Der Update-Transient wird bei einer normalen WordPress-Installation in wp_options gespeichert.

Deshalb sollte zunächst die Spaltenstruktur geprüft werden:

wp db query \
"SHOW FULL COLUMNS FROM $(wp db prefix)options LIKE 'option_value';"

Bei uns ergab die Prüfung:

Field:     option_value
Type:      longtext
Collation: utf8_general_ci

LONGTEXT war korrekt. Die maximale Feldlänge war damit nicht das Problem.

Auffällig war jedoch:

utf8_general_ci

Das entspricht dem älteren MySQL-UTF-8-Zeichensatz und unterstützt nicht den vollständigen Unicode-Zeichensatz wie utf8mb4.

Damit entstand der Verdacht:

Enthält einer der Plugin-Update-Datensätze ein Zeichen, das sich mit dem verwendeten Datenbankzeichensatz nicht speichern lässt?

Schritt 10: Das konkrete problematische Plugin finden

WordPress selbst stellt mit:

$wpdb->strip_invalid_text_for_column()

eine Möglichkeit bereit zu prüfen, ob ein Wert in einer bestimmten Datenbankspalte gespeichert werden kann.

Wir haben deshalb die einzelnen Bereiche des Update-Objekts getestet:

checked
response
no_update
translations

Das Ergebnis war:

checked: OK

response: INVALID / NICHT SPEICHERBAR
  -> wonderm00ns-simple-facebook-open-graph-tags/wonderm00n-open-graph.php

no_update: OK
translations: OK

Damit war die Ursache isoliert.

Der problematische Update-Eintrag gehörte zu:

Open Graph and Twitter Card Tags

bzw. technisch:

wonderm00ns-simple-facebook-open-graph-tags/
wonderm00n-open-graph.php

Ein einziger problematischer Eintrag im response-Objekt verhinderte das Speichern des gesamten Update-Transients.

Dadurch verschwanden nicht nur die Updateinformationen dieses Plugins, sondern auch die Updates der anderen Plugins.

Die eigentliche Lösung

In unserem konkreten Fall war die Lösung erstaunlich einfach:

Open Graph and Twitter Card Tags wurde manuell auf die aktuelle Version gebracht.

Danach wurde die Plugin-Updateprüfung erneut durchgeführt.

Anschließend konnten die Updateinformationen wieder gespeichert werden und die zuvor fehlenden Update-Buttons erschienen wieder.

Damit war auch praktisch bestätigt, dass dieses Plugin bzw. dessen damaliger Update-Eintrag der Auslöser war.

Schnelltest: Habe ich dasselbe Problem?

Wer ein ähnliches Verhalten auf einer WordPress-Seite beobachtet, kann die Diagnose erheblich verkürzen.

Zunächst:

wp plugin list --update=available

Wenn dort erwartete Updates fehlen, dann:

wp eval '
delete_site_transient("update_plugins");
wp_update_plugins();

$u = get_site_transient("update_plugins");

echo "checked: " .
    count((array)($u->checked ?? [])) . PHP_EOL;

echo "response: " .
    count((array)($u->response ?? [])) . PHP_EOL;

echo "no_update: " .
    count((array)($u->no_update ?? [])) . PHP_EOL;
'

Wenn trotz installierter Plugins beispielsweise herauskommt:

checked: 0
response: 0

ist das auffällig.

Dann sollte der Datenbankfehler untersucht werden.

Diagnose-Skript für ungültige Updateinformationen

Wenn bereits feststeht, dass die Update-API funktioniert, kann folgender Test helfen herauszufinden, welcher Update-Eintrag nicht in wp_options.option_value gespeichert werden kann:

wp eval '
global $wpdb;

add_filter(
    "pre_set_site_transient_update_plugins",
    function($v) {

        global $wpdb;

        if (empty($v->checked)) {
            return $v;
        }

        echo PHP_EOL . "===== ZEICHENSATZ-TEST =====" . PHP_EOL;

        $parts = [
            "checked",
            "response",
            "no_update",
            "translations"
        ];

        foreach ($parts as $part) {

            $data = $v->$part ?? [];
            $serialized = maybe_serialize($data);

            $clean = $wpdb->strip_invalid_text_for_column(
                $wpdb->options,
                "option_value",
                $serialized
            );

            if (is_wp_error($clean)) {
                echo $part . ": ERROR: " .
                    $clean->get_error_message() .
                    PHP_EOL;

                continue;
            }

            if ($serialized === $clean) {
                echo $part . ": OK" . PHP_EOL;
                continue;
            }

            echo $part .
                ": INVALID / NICHT SPEICHERBAR" .
                PHP_EOL;

            if (is_array($data)) {

                foreach ($data as $key => $item) {

                    $s = maybe_serialize($item);

                    $c = $wpdb->strip_invalid_text_for_column(
                        $wpdb->options,
                        "option_value",
                        $s
                    );

                    if (
                        !is_wp_error($c) &&
                        $s !== $c
                    ) {
                        echo "  -> " .
                            $key .
                            PHP_EOL;
                    }
                }
            }
        }

        return $v;
    },
    PHP_INT_MAX
);

delete_site_transient("update_plugins");
wp_update_plugins();
'

Wichtig: Das ist ein Diagnosewerkzeug, kein Code, der dauerhaft in WordPress eingebaut werden sollte.

Checkliste: WordPress Plugin-Update fehlt

Wenn der Button „Jetzt aktualisieren“ plötzlich bei mehreren Plugins fehlt, empfiehlt sich folgende Reihenfolge:

1. Prüfen, ob tatsächlich neuere Plugin-Versionen existieren.
2. Dashboard → Aktualisierungen → Erneut prüfen ausführen.
3. Mit get_plugins() bzw. WP-CLI prüfen, ob WordPress das Plugin korrekt erkennt.
4. update_plugins auf checked, response und no_update untersuchen.
5. Verbindung zu api.wordpress.org kontrollieren.
6. Prüfen, ob wp_update_plugins() eine erfolgreiche HTTP-200-Antwort erhält.
7. Das Updateobjekt unmittelbar vor set_site_transient() kontrollieren.
8. $wpdb->last_error auf Datenbankfehler prüfen.
9. wp_options.option_value auf Datentyp und Zeichensatz untersuchen.
10. Falls notwendig, einzelne Update-Datensätze mit strip_invalid_text_for_column() testen.

Mit diesem Vorgehen lässt sich unterscheiden, ob das Problem durch

• Netzwerk/Firewall,
• einen Plugin-Filter,
• einen Object Cache,
• eine beschädigte Updateinformation,
• eine Datenbankstruktur
• oder einen nicht speicherbaren Zeichensatz

verursacht wird.

Fazit

Wenn WordPress keine Plugin-Updates mehr anzeigt, bedeutet das nicht automatisch, dass die Updateprüfung selbst defekt ist.

In unserem Fall funktionierte praktisch alles:

Plugin-Erkennung        ✓
WordPress.org API       ✓
HTTP-Verbindung         ✓
Versionsvergleich       ✓
Update gefunden         ✓

Erst beim letzten Schritt trat der Fehler auf:

Updateinformationen in Datenbank speichern   ✗

Der problematische Datensatz konnte schließlich auf Open Graph and Twitter Card Tags eingegrenzt werden. Nach dem Update dieses Plugins funktionierte auch die gesamte WordPress-Updateanzeige wieder.

Gerade bei einem Fehler, bei dem mehrere scheinbar unabhängige Plugins gleichzeitig keine Updates mehr anzeigen, lohnt es sich deshalb, nicht jedes Plugin einzeln zu untersuchen. Oft steckt ein gemeinsamer Fehler im zentralen WordPress-Update-Transient dahinter.

Sie benötigen Hilfe bei der WordPress-Aktualisierung?

KonVis unterstützt Unternehmen bei der Betreuung, Aktualisierung und technischen Prüfung bestehender WordPress-Internetseiten.

Hier finden Sie weitere Informationen WordPress Hilfe und Betreuung

Hier finden Sie weitere Informationen zu WordPress Internetseite von und mit Konvis