Hi,
bei mir zählt Statify seit dem 23.06. keine Aufrufe mehr. Das letzte Statify Update wurde am 17.06. gemacht. Liegt also nicht unbedingt an dieser Version, da ja dann noch 6 Tage aufgezeichnet wurde.
Ich nutze Cache Enabler und Statify ist auf Tracking via JavaScript eingestellt.
Grüße
Torsten
Was ich bisher rausgefunden habe: Wenn ich das Plugin Statify Blacklist deaktiviere, dann zählt Statify wieder (alle Aufrufe, natürlich auch meine eigenen)… Scheinbar kollidieren die beiden miteinander. Wundere mich dann allerdings immer noch, wieso dann nicht direkt nach dem Update von Statify dieser Fehler auftrat.
@hollo inwiefern hast du dir von einer Erhöhung de Cache-Lebensdauer eine Besserung erhofft? Durch die Änderungen mit Statify 1.7 wird eine Caching-Dauer von 24h und mehr unter Umständen problematisch (für viele andere Plugins ebenfalls), da AJAX Einmalcodes in WordPress Standardmäßig nur „bis zu 24h“ gültig sind. Ich würde es demnach eher mit einer Verringerung der Zeit versuchen und bei Erfolg und einer späteren Erhöhung hierauf darauf achten, dass die Punkte zusammenpassen.
Ich kenne WP Optimize nicht im Detail, daher kann ich Stand jetzt nur spekulieren. Wie hast du das Caching von der Zeit ma abgesehen konfiguriert? Preloading aktiv? Browsercache für HTML aktiv?
—-
@knodderdachs Ich bin Autor des genannten Plugins und betreibe es selbst in verschiedenen Konfigurationen, wobei mir noch kein derartiger Konflikt aufgefallen ist. Am relevanten Teil der Statify Filterlogik hat sich beim letzen Update auch nichts getan… Kannst du mir sagen, welche Filter du aktiviert hattest, damit ich die Möglichkeit habe, das Phänomen nachzuvollziehen?
Wenn die Diskussion länger werden könnte, gern auch in einem eigenen Support-Thread zum passenden Plugin, um hier nicht zu sehr zu mischen.
@stklcode Hi, ich habe meine (feste) IP-Adresse filtern lassen. Das hat auch immer gut funktioniert, bis eben vor ein paar Tagen. Dein Plugin gibt’s in der aktuellen Version ja schon etwas länger und auch Statify lief, wie geschrieben, schon ein paar Tage ohne Auffälligkeiten. Weil ich nicht wusste, was ich machen könnte, habe ich einfach mal dein Plugin deaktiviert und die Statistik hat sich wieder gefüllt. Zur Cache Dauer: habe Cache Enabler so eingestellt, dass der Cache nie verfällt, außer bei neuen Kommentaren, neuen Artikeln oder Pluginupdates.
Thread Starter
Holger
(@hollo)
@stklcode In einem anderen Thread hier zum gleichen Problem, wurde empfohlen die Cache Lebensdauer zu ändern, allerdings nicht in welche Richtung. Sie zu erhöhen war also mein erster Versuch. Ich versuch es jetzt mal in die andere Richtung und schaue ob es was bringt.
Preloading ist nicht aktiv,
Eine Einstellung den Browsercache für HTML zu aktivieren habe ich nicht gefunden.
P.S.: Das Deaktivieren von Statify Blacklist hat bei mir keine Änderung gebracht.
Ich hatte in einem anderen Thread einmal die Nonce-Problematik angeschnitten: https://wordpress.org/support/topic/crazy-counting/#post-12946894
Weniger als 24h ist im Regelfall unkritisch (nicht exakt, im Zweifelsfall lieber etwas weniger wählen). Je nach Szenario können sich aber mehrere Caches (WP Plugin, Webserver, Proxy, Browser) und so effektiv länger das selbe HTML liefern.
Geht man höher, kann man die Gültigkeit der Nonces auch mit erhöhen (https://codex.wordpress.org/WordPress_Nonces).
Keine pauschale Empfehlung, dafür gibt es zu viele Faktoren, aber kürzere Zeitspanne mit automatischen Preloading kann eine Alternative sein.
Zur Cache Dauer: habe Cache Enabler so eingestellt, dass der Cache nie verfällt, außer bei neuen Kommentaren, neuen Artikeln oder Pluginupdates.
Siehe meine vorherige Ausführung, das kann die sinkenden Zugrriffszahlen erklären. Mit der Zeit sind alle relevanten Seiten >24h im Cache und wenn es dann ein paar Tage keine Änderungen und Plugin-Updates gibt… Falls Deaktivieren eines Plugins die Invalidierung triggert oder im selben Zuge evtl. ein anderes Updates gemacht wurde, kann das Verhalten ebenfalls passen.
PS: Ich habe es schon mehrfach in anderen Threads erwähnt: Wenn es ein Caching-Problem ist, sollten sich verstärkt Aufrufe mit Status-Code 403 auf admin-ajax.php im Server-Log finden, sofern einsehbar.
@stklcode Habe es nun nochmal mit leerem Cache ausprobiert und es scheint zu klappen 🙂 Habe die Cache Dauer nun mal testweise auf 20 Stunden gestellt und werde es beobachten. Melde mich, sollte es auf Dauer nicht funktionieren. Danke schon mal.
@stklcode Nein, geht leider nach einiger Zeit nicht mehr. Sobald ich das Plugin deinstalliere (und dann den Cache lösche) zählt Statify wieder. Wenn der Cache nicht gelöscht wird, dann zählt Statify auch nicht.
Ich habe mir deine Seite (ich habe einfach mal knodderdachs.de geraten) seit gestern einmal angesehen.
<!-- Cache Enabler by KeyCDN @ 29.06.2020 19:29:41 (webp gzip) -->
Aufruf um 19:31, also ganz frisch, Tracking OK.
Aufruf heute gegen 8:15 – OK
Aufruf heute gegen 14:00 – OK
Aufruf heute 17:20 – Fehler 403 (kein Tracking, Nonce abgelaufen).
Aufruf heute, 17:30 – Fehler 403, immer noch die 20h+1m alte Seite
Aufruf heute, 17:35 mit willkürlochem Parameter ?foo (kein Cache dank Parameter) – Tracking OK
Weder AJAX Nonces, noch die Cron Tasks zur Cache-Leerung sind eine exakte Wissenschaft. Nonces sind laut offizieller Aussage “12-24h” gültig… Cron, sofern nicht extern getriggert, hängt vom Nutzungsverhalten ab, daher lebt die Seite (wie zu erwarten) nach 20h + 5min immer noch.
Wenn du keinen anderen Grund hast, der dagegen spricht und eine hohe Cache-Dauer behalten möchtest würde ich empfehlen, die Nonce-Lifetime zu erhöhen (z.B. 36 oder 48h), sodass der Unsicherheitsfaktor kleiner wird. (Link in vorherigen Beitrag beschreibt die Auswirkungen).
@stklcode Ja, das ist die richtige Adresse. Stimmt, der Cache ist immer noch aufgebaut und wirft bei snippet.min.js einen Fehler 403. Das wundert mich allerdings, da ich gestern Abend die Cachedauer auf 12 Stunden gestellt habe. Cron wird extern getriggert.
Den Cache wollte ich ursprünglich so lange wie sich nichts ändert, erhalten, da die Website dann einfach schneller ist. Ich will aber auch, dass Statify (und evtl. andere Plugins, bei denen ich bisher evtl. noch nichts gemerkt habe) einwandfrei funktionieren.
Geht die Erhöhung der Nonce-Lifetime nicht mit einem höheren Sicherheitsrisiko einher?
Das wundert mich allerdings, da ich gestern Abend die Cachedauer auf 12 Stunden gestellt habe. Cron wird extern getriggert.
Das wären eigentlich recht ideale Bedingungen. Allerdings kenne ich das Caching Plugin nur flüchtig, daher kann ich hier mögliche Ursachen auch nur raten.
Ich verwende selbst oft ~12h, was bei hoher Nutzerzahl und/oder externem Trigger eigentlich +/- 15min hinkommt…
Geht die Erhöhung der Nonce-Lifetime nicht mit einem höheren Sicherheitsrisiko einher?
Ja und Nein. Es kommt letztlich etwas darauf an, wofür sie konkret genutzt werden.
Es sind (offensichtlich) keine wirklichen Einmaltoken. Plugins, die Nonces als solche verwenden, sollten diese auch unmittelbar nach Verwendung aktiv invalidieren oder eine eigene Methodik mitbringen. Im Falle von Statify eher unkritisch.
(man könnte sich fast überlegen, die Prüfung deaktivierbar zu machen… bis 1.6 gab es die gar nicht – sollten wir im Team mal diskutieren)
Den Cache wollte ich ursprünglich so lange wie sich nichts ändert, erhalten, da die Website dann einfach schneller ist.
In solchen Fällen liefert eine (zuverlässige) 12h Dauer und ein Preload-Trigger (externes Cron verwendest du ja bereits) aus Anwendersicht gleichermaßen schnelle Ergebnisse.
WP Rocket empfiehlt bspw. 10h oder weniger, um gänzlich sicher zu gehen, also min. Nonce-Lifetime minus Cron-Puffer.
Letztlich muss irgendwo ein Kompromiss aus Client-Performance, Server-Last und Sicherheit her. Ob das 8h Preload oder 48h Nonce-Lifetime ist, ist pauschal kaum zu beantworten.
@stklcode Habe die Dauer nun mal auf 8 Stunden eingestellt und beobachte weiter.
@stklcode Habe nun herausgefunden, woran es liegen könnte. Scheinbar kann Statify den Cache selbst gar nicht löschen, da ich das seinerzeit so konfiguriert habe, dass die Ausführung von PHP komplett umgangen wird und direkt die gecachten Seiten ausgegeben werden, sofern sie existieren. In der Statify Anleitung steht drin, dass in diesem Fall die Einstellung zur Cache Expiry nicht funktioniert, da der Aufruf für diese PHP Funktion übergangen wird. Ist mir bisher nie aufgefallen, da ich den Cache auch maximal aufrecht erhalten wollte…
Habe das Löschen des Cacheverzeichnis nun per Cronjob auf alle 10 Stunden eingestellt und beobachte weiter.
Statify kann den Cache niemals zeitgesteuert löschen, egal welches Caching Plugin zum Einsatz kommt und wie dieses konfiguriert ist. Warum auch, ist ja gar nicht seine Aufgabe…
Ich nehme an du beziehst dich auf diesen Doku-Artikel: https://statify.pluginkollektiv.org/de/documentation/settings/#js-tracking
Der Hinweis hier bezieht sich darauf, dass bei Caching zwingend JavaScript verwendet werden muss.
Was es kann ist einmalig beim Speichern der Konfiguration den Cache leeren, falls das Plugin Cachify eingsetzt wird. Um die periodische Leerung des Caches muss sich das Caching Plugin selbst kümmern. I.d.R. geschieht dies über WP Cron.
Ich verwende selbst einige Kostellationen, z.T. mit Caching-Plugin + ReverseProxy Cache und einen externen Trigger für WP-Cron, das funktioniert bislang recht stabil. Ich kenne Cache Enabler nicht gut genug, aber auch hier sollte es eine derartige Einstellung geben, die ohne semi-manuelles Löschen der Dateien auskommt.
@stklcode Sorry, habe mich verschrieben. Cache Enabler kann nicht selbst den Cache löschen, wenn es so eingestellt ist, dass PHP umgangen wird und die gecachten Seiten gleich ausgeliefert werden. https://www.keycdn.com/support/wordpress-cache-enabler-plugin#will-cache-enabler-s-expiry-function-still-work-if-i-m-using-the-advanced-snippet
