Support » Plugin: Statify » Statify und WP-Optimize

  • Resolved Holger

    (@hollo)


    Hallo Allerseits,

    ich nutze Statify schon seit einiger Zeit und bin mehr als zufrieden damit. Aus Gründen der Seitenoptimierung habe ich vor ein paar Tagen WP-Optimize installiert und das Caching aktiviert. Seit dem werden bei mir statt täglich ca. 600 Besucher nur noch etwa 80 gezählt.

    Ich hab mich hier schon etwas schlau gemacht und in Statify das Tracking per Java Script aktiviert und in WP-Optimize die Cache Lebensdauer von 24 auf 48 Stunden erhöht. Leider ohne den gewünschten Erfolg.

    Könnt ihr mir ein paar Empfehlungen geben, welche Einstellungen ich n beiden Plugins vornehmen muss, damit die Zählung der Aufrufe wieder stimmt?

    Beste Grüße,
    Holger

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 18 total)
  • Torsten

    (@knodderdachs)

    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

    Torsten

    (@knodderdachs)

    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.

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    @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.

    Torsten

    (@knodderdachs)

    @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.

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    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.

    Torsten

    (@knodderdachs)

    @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.

    Torsten

    (@knodderdachs)

    @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.

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    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).

    Torsten

    (@knodderdachs)

    @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?

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    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.

    Torsten

    (@knodderdachs)

    @stklcode Habe die Dauer nun mal auf 8 Stunden eingestellt und beobachte weiter.

    Torsten

    (@knodderdachs)

    @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.

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    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.

    Torsten

    (@knodderdachs)

    @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

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘Statify und WP-Optimize’ is closed to new replies.