WordPress zeigt in der Administrationsleiste eine verfügbare Aktualisierung an, obwohl sämtliche Plugins, Themes und WordPress selbst auf dem neuesten Stand sind? Gerade bei einer WordPress-Multisite kann dieses Verhalten verwirrend sein.

In diesem Beitrag wird anhand eines konkreten Praxisfalls beschrieben, wie sich die Ursache mit einem kleinen PHP-Snippet identifizieren lässt.

Das Problem: WordPress meldet ein Update, das nicht existiert

In einer WordPress-Multisite-Installation mit WordPress 7.1.4 trat ein ungewöhnliches Verhalten auf.

In der Administrationsleiste einer Unterseite erschien dauerhaft das Update-Symbol mit der Zahl 1.

Die Überprüfung ergab jedoch:

• WordPress selbst war aktuell.
• Alle Themes waren aktuell.
• Die Pluginverwaltung zeigte keine verfügbaren Aktualisierungen.
• In der Netzwerkverwaltung wurden ebenfalls keine Updates angeboten.
• Eine erneute Überprüfung der Aktualisierungen änderte nichts.

Zusätzlich wurden innerhalb weniger Stunden mehrfach Aktualisierungen für die deutsche WordPress-Übersetzung (de_DE) angeboten. Diese Übersetzungen ließen sich zwar erfolgreich aktualisieren, wurden jedoch später erneut als verfügbar angezeigt.

Ob beide Auffälligkeiten zusammenhingen, war zunächst unklar.

Der WordPress-Website-Zustand liefert einen ersten Hinweis

Über das WordPress-Backend lässt sich unter folgendem Menüpunkt eine Systemdiagnose aufrufen:

Werkzeuge → Website-Zustand

Dort wurde ein kritisches Problem gemeldet:

Es gibt Plugins, die darauf warten, aktualisiert zu werden.

Zusätzlich erschien der Hinweis:

Deine Website hat 1 Plugin, das darauf wartet, aktualisiert zu werden.

Das war besonders interessant, da in der eigentlichen Pluginverwaltung kein entsprechendes Update angeboten wurde. Offenbar erkannte WordPress intern eine verfügbare Aktualisierung, stellte diese jedoch nicht in der gewohnten Oberfläche dar.

Mögliche Cache-Probleme ausschließen

Zunächst lag der Verdacht auf einem Cache-Problem. Bei WordPress können unterschiedliche Caching-Verfahren zum Einsatz kommen.

Seiten-Cache

Plugins wie WP Super Cache speichern fertig generierte HTML-Seiten, um die Ladezeiten für Besucher zu verbessern.

Persistenter Objektcache

Ein persistenter Objektcache wie Redis kann unter anderem Datenbankabfragen und WordPress-interne Informationen zwischenspeichern. Dazu gehören möglicherweise auch Informationen über verfügbare Aktualisierungen.

Überprüfung der Cache-Konfiguration

In der Netzwerkverwaltung lässt sich unter

Plugins → Installierte Plugins → Drop-in

prüfen, welche speziellen WordPress-Drop-ins installiert sind.

Im untersuchten Fall war lediglich folgende Datei vorhanden:

advanced-cache.php

Diese wird typischerweise von Seiten-Cache-Systemen verwendet.

Eine Datei namens

object-cache.php

war dagegen nicht vorhanden. Zusätzlich meldete der WordPress-Website-Zustand, dass kein persistenter Objektcache erkannt wurde. Damit erschien Redis als Ursache des Problems unwahrscheinlich.

Ein fehlendes object-cache.php-Drop-in beweist allerdings auch nicht, dass auf dem Server kein Redis installiert ist. Es spricht lediglich dagegen, dass WordPress Redis über einen üblichen persistenten Objektcache verwendet. Auch ein Test in einem privaten Browserfenster zeigte weiterhin die Update-Anzeige. Ein lokales Browsercache-Problem war daher ebenfalls unwahrscheinlich.

WordPress-Updateinformationen direkt auslesen

Da die üblichen Prüfungen kein Ergebnis lieferten, wurde ein kleines PHP-Diagnose-Snippet erstellt. WordPress speichert Informationen über Plugin-Aktualisierungen im sogenannten Site-Transient:

update_plugins

Diesen Wert kann man mit der WordPress-Funktion get_site_transient() auslesen. Bei Multisite-Installationen werden diese Plugin-Updateinformationen netzwerkweit verwaltet.

Diagnose-Snippet erstellen

Für die Diagnose wurde das Plugin Code Snippets verwendet. Ein entsprechendes Snippet lässt sich alternativ auch über eine eigene Administrations-Erweiterung einbinden.

Folgender PHP-Code gibt aus, welche Plugin-Aktualisierungen WordPress intern registriert hat:

add_action('admin_notices', 'check_plugin_updates');
add_action('network_admin_notices', 'check_plugin_updates');

function check_plugin_updates() {

    if (!is_super_admin() || !current_user_can('update_plugins')) {
        return;
    }

    if (!isset($_GET['check_plugin_updates'])) {
        return;
    }

    $updates = get_site_transient('update_plugins');

    echo '<div class="notice notice-info" style="padding:15px;">';
    echo '<h3>WordPress Plugin-Update-Diagnose</h3>';

    if (empty($updates->response)) {
        echo '<p>Keine Plugin-Updates im Update-Transient gefunden.</p>';
    } else {
        foreach ($updates->response as $plugin => $data) {

            echo '<p><strong>Plugin:</strong> '
                . esc_html($plugin) . '<br>';

            echo '<strong>Installierte Version:</strong> '
                . esc_html($updates->checked[$plugin] ?? 'Unbekannt')
                . '<br>';

            echo '<strong>Gemeldete neue Version:</strong> '
                . esc_html($data->new_version ?? 'Unbekannt')
                . '</p>';
        }
    }

    echo '</div>';
}

Hinweis: Bei Verwendung von Code Snippets darf kein zusätzliches <?php eingefügt werden, sofern der Editor bereits PHP-Code erwartet.

Snippet aktivieren

Das Snippet sollte nur im Administrationsbereich ausgeführt werden. Anschließend ruft man das Dashboard einer betroffenen Website mit einem zusätzlichen URL-Parameter auf.

Beispiel mit anonymisierter Domain:

https://www.example.com/wp-admin/index.php?check_plugin_updates=1

Bei einer Multisite-Unterseite mit eigenem Pfad könnte die Adresse beispielsweise so aussehen:

https://www.example.com/unterseite/wp-admin/index.php?check_plugin_updates=1

Der Parameter aktiviert die Diagnoseausgabe. Das Snippet liest die gespeicherten Updateinformationen lediglich aus. Es nimmt keine Änderungen an Plugins, Themes oder WordPress selbst vor.

Das Ergebnis: Ein verstecktes Plugin-Update

Die Diagnose brachte schließlich die Ursache ans Licht.

WordPress meldete folgende Aktualisierung:

WordPress Plugin-Update-Diagnose

Plugin:
newsletter-extensions/extensions.php

Installierte Version:
1.4.1

Gemeldete neue Version:
1.4.2

Damit war klar:

WordPress hatte tatsächlich eine neuere Plugin-Version registriert, zeigte die Aktualisierung jedoch nicht in der normalen Pluginverwaltung an.

Der betreffende Eintrag gehörte zum Plugin:

Newsletter – Addons Manager and Support

Dieses Plugin ist eine Erweiterung für das WordPress-Plugin „Newsletter“ des Newsletter-Teams.

In der Pluginverwaltung war Version 1.4.1 installiert.

Ein Updatehinweis auf Version 1.4.2 fehlte jedoch.

Die Ursache der permanenten Update-Anzeige war damit identifiziert.

Warum das Update nicht regulär angeboten wurde, ließ sich anhand der Diagnose allein allerdings nicht abschließend feststellen.

Die Lösung: Plugin manuell aktualisieren

Da das betroffene Plugin weiterhin aktiv verwendet wurde, kam eine einfache Deinstallation nicht infrage. Stattdessen wurde die Aktualisierung manuell durchgeführt.

Schritt 1: Datensicherung erstellen

Vor dem manuellen Austausch eines Plugins sollte ein aktuelles Backup vorhanden sein. Bei einer WordPress-Multisite ist besonders wichtig, dass sowohl die Datenbank als auch die relevanten WordPress-Dateien gesichert werden.

Schritt 2: Aktuelle Plugin-Version herunterladen

Die benötigte Version sollte ausschließlich von einer vertrauenswürdigen Quelle bezogen werden.Für den Newsletter Addons Manager bietet der Hersteller entsprechende Downloads und Installationsanleitungen an.

Offizielle Dokumentation:

https://www.thenewsletterplugin.com/documentation/installation/how-to-install-the-addons-manager

Schritt 3: Plugin über die Netzwerkverwaltung hochladen

In der WordPress-Netzwerkverwaltung folgenden Bereich öffnen:

Plugins → Plugin hinzufügen → Plugin hochladen

Anschließend die heruntergeladene ZIP-Datei auswählen.

Schritt 4: Vorhandene Version ersetzen

WordPress erkennt normalerweise, wenn das hochgeladene Plugin bereits installiert ist. In diesem Fall kann die vorhandene Version durch die hochgeladene Version ersetzt werden. Vor der Bestätigung sollten der Plugin-Name und die Versionsinformationen sorgfältig geprüft werden. Die bestehende Installation wird dadurch aktualisiert, ohne das Plugin vorher vollständig deinstallieren zu müssen.

Schritt 5: Aktualisierung kontrollieren

Nach erfolgreicher Aktualisierung sollte die Pluginverwaltung die neue Version anzeigen. Im vorliegenden Fall konnte die manuelle Aktualisierung erfolgreich durchgeführt werden.

Warum konnte WordPress das Update erkennen, aber nicht anzeigen?

Diese Frage lässt sich nicht in jedem Fall eindeutig beantworten. WordPress verwendet interne Datenstrukturen, um verfügbare Plugin-Aktualisierungen zu verwalten.

Die Funktion

get_site_transient('update_plugins')

liefert unter anderem die gespeicherten Informationen zu verfügbaren Plugin-Updates. Die eigentliche Pluginverwaltung verwendet diese Informationen ebenfalls, verarbeitet sie jedoch zusätzlich für die Darstellung in der Administrationsoberfläche. Bei Plugins mit eigenen Update-Mechanismen oder externen Update-Servern können Unstimmigkeiten entstehen.

Mögliche Ursachen sind beispielsweise:

• Unvollständige oder inkonsistente Updateinformationen.
• Besonderheiten der Updateverwaltung eines Drittanbieter-Plugins.
• Veraltete gespeicherte Aktualisierungsdaten.
• Filter oder eigene Anpassungen, die Updateinformationen beeinflussen.

Im beschriebenen Fall wurde nicht abschließend festgestellt, weshalb die Aktualisierung in der Pluginverwaltung fehlte. Die Diagnose zeigte jedoch eindeutig, welches Plugin WordPress intern als aktualisierungsbedürftig betrachtete.

8. Was ist mit den wiederkehrenden Übersetzungsupdates?

Parallel zum Plugin-Problem wurden mehrfach Aktualisierungen für die deutsche WordPress-Übersetzung angeboten.

Dabei erschien die Meldung:

Aktualisierung der Übersetzungen für WordPress (de_DE) …

Die Aktualisierung wurde jeweils erfolgreich abgeschlossen.

Dieses Verhalten kann unterschiedliche Ursachen haben. Dazu gehören beispielsweise inkonsistente Versionsinformationen oder Schwierigkeiten bei der Erkennung installierter Sprachpakete.

Wichtig ist jedoch die Unterscheidung:

Das versteckte Plugin-Update konnte mit dem Diagnose-Snippet eindeutig identifiziert werden. Für die wiederkehrenden Übersetzungsupdates ließ sich dagegen noch keine gesicherte Ursache feststellen.

9. Diagnose-Snippet anschließend deaktivieren

Das PHP-Snippet dient ausschließlich der Fehlersuche. Sobald die Ursache gefunden wurde, sollte es wieder deaktiviert und gegebenenfalls gelöscht werden. Eine dauerhafte Ausführung ist nicht notwendig. Außerdem sollte die Diagnose nicht öffentlich zugänglich gemacht werden, da sie interne Informationen über installierte Plugins und Versionsstände enthält. Im gezeigten Beispiel ist die Ausgabe deshalb auf berechtigte Administratoren beschränkt.

Weiterführende Informationen

WordPress Developer Resources – get_site_transient()

WordPress Developer Resources – wp_get_update_data()

WordPress Developer Resources – wp_get_translation_updates()

Newsletter – Offizielle Dokumentation zum Addons Manager

https://www.thenewsletterplugin.com/documentation/installation/how-to-install-the-addons-manager