Du verwendest PS Stats für WordPress und hast das Tracking aktiviert, aber es werden keine Daten auf der Seite Zusammenfassungsbericht angezeigt oder wenn Du zu „PS Stats-Berichterstellung“ gehst.
Beim Tracking von Besuchern speichert PS Stats Informationen über jede einzelne Aktion Deiner Besucher. Dies nennt man Rohdaten. Von Zeit zu Zeit (normalerweise etwa stündlich) erstellt PS Stats aus diesen Rohdaten aggregierte Berichte. Zum Beispiel wird ein Bericht generiert, der besagt, dass
5 Besucher aus den Vereinigten Staaten kommen oder 3 Besucher, die Firefox als Browser verwenden. Diese aggregierte Berichterstellung wird als Archivierung bezeichnet und läuft im Hintergrund über WordPress Cron (WP-Cron).
Wenn in einem der beiden Berichte Daten angezeigt werden, handelt es sich wahrscheinlich um ein Archivierungsproblem. Wenn in diesen beiden Berichten keine Daten angezeigt werden, kann es sich tatsächlich um ein Tracking-Problem handeln.
Wir empfehlen Dir, auch das ausgewählte Datum zu überprüfen. Wenn Du beispielsweise PS Stats gerade erst installiert hast, stelle sicher, dass Du Dir die Daten von heute ansiehst. Wenn Du PS Stats schon länger verwendest, solltest Du Dir die Daten von gestern oder der letzten Woche ansehen.
Wenn Du wenig Traffic hast, möchtest Du sicherstellen, dass Du in dieser Zeit tatsächlich Besuche auf Deiner Webseite hattest. Wir empfehlen Dir, im Inkognito-Modus auf Deine Webseite zuzugreifen, damit Du von WordPress abgemeldet bist. Falls Du Deine eigene IP ausgeschlossen hast, möchtest Du vielleicht auch von Deinem Telefon oder so auf Deine Webseite zugreifen.
Ein weiteres Anzeichen dafür, dass Du Probleme mit der Archivierung hast, kann sein, wenn der letzte Archivierungs-Cronjob seit einiger Zeit nicht erfolgreich war. Um herauszufinden, wann es zuletzt erfolgreich gelaufen ist, gehe zu „PS Stats => Diagnostics“ (ältere Versionen haben einen Menüpunkt „Matomo Analytics => System Report“). Dort findest Du einen Abschnitt namens „Crons“, der Dir anzeigt, wann die Archivierung zuletzt abgeschlossen wurde.
Wenn das Datum neben „Zuletzt beendet“ in der Zeile „Archiv“ eine Weile zurückliegt, tritt wahrscheinlich ein Fehler während des Archivierungsvorgangs auf.
Der nächste Schritt besteht darin, auf der Systemberichtsseite zu überprüfen, ob Fehler oder Warnungen vorhanden sind, die behoben werden müssen. Zum Beispiel könnte es sagen, dass eine MySQL-Berechtigung fehlt. Nicht alle Warnungen oder Fehler beziehen sich möglicherweise auf die Archivierung und im Zweifelsfall pinge uns einfach an, um ein Problem zu erstellen. Wir helfen gerne.
Um zu überprüfen, ob die Archivierung funktioniert, wenn Du sie manuell auslöst, scrolle zum oberen Rand der Seite Systembericht und klicke auf Fehlerbehebung.
Klicke nun auf die Schaltfläche „Berichte archivieren“.
Es kann einige Sekunden oder Minuten dauern, bis dies abgeschlossen ist, abhängig von Deiner Servergröße und der Anzahl der Besuche/Seitenaufrufe Deiner Webseite. Überprüfe nach Abschluss, ob am Anfang der Seite Fehler oder Warnungen angezeigt werden. Möglicherweise siehst Du einige Warnungen oder Fehler, die wie folgt aussehen (falls vorhanden, teile uns dies mit, indem Du ein Problem erstellst, siehe unten):
Du solltest auch überprüfen, ob die „PS Stats => Zusammenfassung“ oder einer der anderen PS Stats-Berichte jetzt Daten anzeigen.
Wenn immer noch keine Daten angezeigt werden oder die Archivierung beim manuellen Auslösen, aber nicht beim Cron funktioniert hat, empfehlen wir die Dateiprotokollierung zu aktivieren . Stelle sicher, dass diese beiden Optionen in Deiner wp-config.php
aktiviert sind:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
Nun empfehlen wir, einige Stunden zu warten, bis der Cron wieder läuft (der Cron läuft normalerweise stündlich). Je nach Konfiguration werden alle Fehler oder Warnungen in Deiner Word/ClassicPress- wp-content/debug.log
Datei oder ähnlichem protokolliert . Du kannst PS Stats-bezogene Protokolle erkennen, wenn sie das WortPSStats
enthalten .
Wenn Du im Debug-Log keine Warnungen oder Fehler findest, empfehlen wir, wenn möglich einen Blick in das PHP-Fehlerprotokoll oder Dein Webserver-Fehlerprotokoll zu werfen.
Jetzt ist es an der Zeit, uns über Dein Problem zu informieren, indem Du ein Issue in unserem GitHub Issue Tracker erstellst. In der Problembeschreibung kannst Du Dein Problem so detailliert wie möglich beschreiben und dann den Systembericht sowie alle Fehler- oder Warnmeldungen einfügen, die Du finden kannst.
Es ist wichtig, immer ein Problem zu erstellen, wenn Du Probleme mit der Archivierung hast, damit wir es beheben und das Problem auch für andere Benutzer vermeiden können. Wenn das Problem aus irgendeinem Grund nicht behoben werden kann oder wir nicht genügend Informationen erhalten, um es zu beheben, gibt es möglicherweise Problemumgehungen:
Dies kann ein Workaround sein, wenn der Systembericht Supports Async Archiving
=> Yes
in der PSStats
Kategorie sagt . Dann kann es möglich sein, dass das Deaktivieren dieser Funktion hilft. Du kannst dies tun, indem Du die wp-config.php
bearbeitest und die folgende Zeile hinzufügst:
define( 'PSSTATS_SUPPORT_ASYNC_ARCHIVING', false );
Du klickst in deinem WordPress auf „PS Stats Reporting“, „PS Stats Admin“ oder „PS Stats Tag Manager“ und die Seite wird nicht oder nur teilweise geladen. Dies kann verschiedene Gründe haben.
Bitte überprüfe in Deinem Browser, ob eine Werbeblocker-Erweiterung oder ähnliches aktiv ist. Wenn ja, deaktiviere es und versuche es erneut. Wenn Du den Brave-Browser verwendest, musst Du möglicherweise blockierende Skripte oder den gesamten Schild deaktivieren.
Bevor Du weitere Fehler behebst, empfehlen wir Dir, den Punkt „PS Stats => Diagnostics“ (ältere Versionen haben einen Menüpunkt „PS Stats => System Report“) auf Fehler oder Warnungen zu überprüfen, die das Problem möglicherweise erklären könnten.
wp-content/plugins/matomo/app/index.php
, wp-content/plugins/psstats/app/psstats.php
und optionalwp-content/plugins/psstats/app/piwik.php
Bitte teile uns mit, welches Plugin Du verwendest, indem Du ein Problem erstellst (siehe unten) und welche Funktion Du aktiviert hast, die dieses Problem möglicherweise verursacht. Wir werden versuchen, es zu reproduzieren und zu umgehen.
Wenn Du den Apache-Webserver verwendest, sollten die Dinge sofort ohne Probleme funktionieren, es sei denn, ein Sicherheits-Plugin blockiert etwas (siehe oben). Wenn Du weißt, dass Du einen anderen Webserver verwendest, z. B. NGINX, musst Du möglicherweise bestimmte Dateien auf die Whitelist setzen, damit der Benutzer darauf zugreifen kann, wenn ein HTTP 403-Fehler auftritt. Dies sind typischerweise:
wp-content/plugins/psstats/app/index.php
(für die PS Stats-Berichts-UI)wp-content/plugins/psstats/app/psstats.php
(für das PS Stats-Tracking)wp-content/uploads/psstats/psstats.js
(für den PS Stats JS-Tracking-Code)Wenn das Problem nicht behoben ist, kannst Du unten ein Problem erstellen und uns alle Erkenntnisse mitteilen, die Du gefunden hast.
Der nächste Schritt besteht darin, ein Issue in unserem PS Stats Issue Tracker zu erstellen. In der Problembeschreibung kannst Du Dein Problem so detailliert wie möglich beschreiben und dann den Systembericht sowie alle Dir aufgefallenen Fehler- oder Warnmeldungen einfügen. Im Idealfall teilst Du uns auch mit, welchen Webserver Du verwendest (z. B. Apache oder Nginx) und füge nach Möglichkeit alle zugehörigen Fehler oder Protokolle aus der Aktivierung von WP_DEBUG ein.
Wenn Du Probleme mit dem Plugin haben, helfen wir Dir gerne und beheben das Problem.
Zuerst solltest Du immer zu „PS Stats => Diagnostics“ gehen, um zu überprüfen, ob ein Fehler oder eine Warnung vorliegt. Wenn das Plugin nicht einmal installiert wird oder sofort abstürzt, kannst Du Dir dennoch den Systembericht anzeigen lassen (siehe weiter unten). Damit wir Dein Problem beheben können, wenn der Systembericht keinen Fehler enthält, musst Du den Debug-Modus ( WP_DEBUG
) in WordPress aktivieren.
Um das Debugging zu aktivieren, bearbeite bitte die wp-config.php
Datei und füge die folgende Zeile hinzu:
define( 'WP_DEBUG', true );
Standardmäßig werden die Fehler und Warnungen innerhalb der HTML-Seiten angezeigt (die andere Konstante WP_DEBUG_DISPLAY
ist standardmäßig auf true gesetzt). Du kannst auch alle Fehler in einer debug.log
Datei innerhalb des /wp-content/
Verzeichnisses speichern , indem Du die folgende Zeile hinzufügst:
define( 'WP_DEBUG_LOG', true );
Erfahre mehr auf der WP_DEBUG WordPress.org-Seite.
Wenn möglich, empfehlen wir Dir, auch Dein allgemeines PHP- und Webserver-Fehlerprotokoll anzusehen.
Gehe in WordPress in das Admin-Panel und klicke unter „PS Stats“ auf „Diagnose“.
Klicke auf die Schaltfläche „Systembericht kopieren“, um den Bericht in Deine Zwischenablage zu kopieren.
Hinweis: Wenn Du das Plugin überhaupt nicht installieren kannst, aktualisiere bitte Deine wp-config.php
Datei und füge die folgende Zeile hinzu:
define( 'PSSTATS_SAFE_MODE', true );
Dadurch wird sichergestellt, dass der PS Stats-Systembericht auch dann funktioniert, wenn Du das Plugin nicht installieren kannst.
Klicke hier für eine detaillierte Schritt-für-Schritt-FAQ zum Abrufen des Systemberichts.
Wenn Du WP_DEBUG
immer aktiviert hast und feststellst, dass keine nützlichen Nachrichten protokolliert werden, kannst Du die Protokollierung von PS Stats-spezifischen Protokollnachrichten deaktivieren, indem Du die folgende Zeile in Deine wp-config.php
einfügst:
define( 'PSSTATS_DEBUG', false );
Wenn Du möchtest, dass das Plugin alle Nachrichten protokolliert (für Debugging-Zwecke), füge die folgende Zeile zu Deiner wp-config.php
hinzu:
define( 'PSSTATS_DEBUG', true );
Sieh Dir diese FAQ an.
Sieh Dir diese FAQ an.
Der nächste Schritt besteht darin, ein Issue in unserem PS Stats Issue Tracker zu erstellen. In der Problembeschreibung kannst Du Dein Problem so detailliert wie möglich beschreiben und anschließend den Systembericht sowie eventuelle Fehler- oder Warnmeldungen einfügen.
Wenn Du mit der Fehlerbehebung fertig bist, bearbeite die wp-config.php
Datei und setze die Konstante auf false:
define( 'WP_DEBUG', false );
Es gibt drei Möglichkeiten, alle Daten, die PS Stats in Deiner WordPress-Datenbank und Deinem Dateisystem gespeichert hat, vollständig zu löschen.
Wenn Du WP-CLI installiert hast und das PS Stats-Plugin noch in Deinem WordPress installiert ist, kannst Du einfach diesen Befehl ausführen:
wp psstats uninstall --force
Bitte beachte dass Du den plugin uninstall
Befehl eventuell später ausführen möchtest, da PS Stats sonst möglicherweise sofort zurückgesetzt/neu installiert wird.
wp plugin deactivate --uninstall psstats
Aktiviere das Entfernen aller Daten wie in dieser FAQ beschrieben und aktiviere anschließend das Plugin nach Möglichkeit wieder in Deinem WordPress. Dann kannst du das Plugin im WordPress Plugins Manager deaktivieren und deinstallieren und alle Daten sollten weg sein.
Gehe folgendermaßen vor, um die Daten manuell zu löschen:
$WPTABLEPREFIX_psstats_*
beispielsweise alle Tabellen, deren Name so lautetwp_psstats_*
wp_options
Tabelle, deren Wert mit psstats%
beginnt. Zum Beispiel mit dieser Abfrage:delete from wp_options where option_name like 'psstats%'
wp_usermeta
Tabelle, deren Wert mit psstats_%
beginnt. Zum Beispiel mit dieser Abfrage:delete from wp_usermeta where meta_key like 'psstats_%'
wp-content/uploads/psstats directory
wp-content/cache/psstats directory
falls vorhandenWenn Du WP-MultiSite verwendest, musst Du auch Daten aus der wp_sitemeta
Tabelle wie folgt löschen :delete from wp_sitemeta where meta_key like 'psstats%'
Du musst auch den psstats
Ordner im uploads
Verzeichnis jeder Webseite entfernen . Wenn zum Beispiel die Upload-Verzeichnisse gespeichert sind, kannst Du im wp-content/uploads/sites/$BLOG_ID/
ausführen:
rm -rf wp-content/uploads/sites/*/psstats
Dies sollte die meisten, wenn nicht alle Daten entfernen, die PS Stats in Deiner WordPress-DB und Deinem Ordner speichert.
Übergeordnet: PS Stats Handbuch Erste Schritte