Statify und WP-Optimize

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.

@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://www.ads-software.com/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.www.ads-software.com/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