Title: Stefan Kalscheuer's Replies - page 6 | WordPress.org

---

# Stefan Kalscheuer

  [  ](https://wordpress.org/support/users/stklcode/)

 *   [Profile](https://wordpress.org/support/users/stklcode/)
 *   [Topics Started](https://wordpress.org/support/users/stklcode/topics/)
 *   [Replies Created](https://wordpress.org/support/users/stklcode/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/stklcode/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/stklcode/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/stklcode/engagements/)
 *   [Favorites](https://wordpress.org/support/users/stklcode/favorites/)

 Search replies:

## Forum Replies Created

Viewing 15 replies - 76 through 90 (of 157 total)

[←](https://wordpress.org/support/users/stklcode/replies/page/5/?output_format=md)
[1](https://wordpress.org/support/users/stklcode/replies/?output_format=md) [2](https://wordpress.org/support/users/stklcode/replies/page/2/?output_format=md)
[3](https://wordpress.org/support/users/stklcode/replies/page/3/?output_format=md)…
[5](https://wordpress.org/support/users/stklcode/replies/page/5/?output_format=md)
6 [7](https://wordpress.org/support/users/stklcode/replies/page/7/?output_format=md)…
[9](https://wordpress.org/support/users/stklcode/replies/page/9/?output_format=md)
[10](https://wordpress.org/support/users/stklcode/replies/page/10/?output_format=md)
[11](https://wordpress.org/support/users/stklcode/replies/page/11/?output_format=md)
[→](https://wordpress.org/support/users/stklcode/replies/page/7/?output_format=md)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Cachify] Disable GZ ?](https://wordpress.org/support/topic/disable-gz/)
 *  [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 8 months ago](https://wordpress.org/support/topic/disable-gz/#post-13324570)
 * You’re welcome.
 * I personally wasn’t aware of these files or at least it wasn’t really on my mind
   until yesterday. I like the idea and opened a corresponding issue to maybe remove
   or allow disabling GZ-generation in future releases: [https://github.com/pluginkollektiv/cachify/issues/197](https://github.com/pluginkollektiv/cachify/issues/197)
 * Cheers,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Cachify] Disable GZ ?](https://wordpress.org/support/topic/disable-gz/)
 *  [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 8 months ago](https://wordpress.org/support/topic/disable-gz/#post-13318786)
 * Hi,
 * actually the _generation_ of gzipped files for HDD caching is not optional and
   hard-coded. _Usage_ is optional though, as you can simply ignore these files 
   and don’t have to do anything with them. So there is no option to control that
   feature. Only way to get around is removing line 166 from _inc/cachify\_hdd.class.
   php_…
 * What is configurable is minification (remove empty lines and comments from HTML).
 * But you got a good point here. With native on-the-fly compression support in 
   most Webservers the additional generation should be optional to reduce unnecessary
   overhead.
 * Cheers,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Merkwürdige Seiten in der Google Search Console](https://wordpress.org/support/topic/merkwurdige-seiten-in-der-google-search-console/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 9 months ago](https://wordpress.org/support/topic/merkwurdige-seiten-in-der-google-search-console/#post-13184264)
 * Hallo Dieter,
 * darüber, wie diese URLs in den Suchindex geraten sind, lässt sich leider nur 
   mutmaßen.
 * Bis _Statify_ 1.6 wurden solche URLs tatsächlich zum Tracking genutzt, allerdings
   sollten diese auf die Home-URL der Seite zeigen, nicht auf eine Unterseite (also
   i.d.R. `/?statify_referrer=...&statify_target=...`) und liefern dann auch keine
   gültige Seite, sondern eine leere Antwort.
    Bis 1.5 wurde dazu ein Pseudo-Element`
   <script>` eingebunden, danach erfolgte der Aufruf direkt aus dem JavaScript heraus.
   Aber eigentlich nie direkt durch einen Link oder Benutzeraufruf.
 * Seit 1.7 werden solche Aufrufe nicht mehr verarbeitet, entsprechend läuft der
   ganz normale _WordPress_ Zyklus durch (Ergebnis s.u.)
 * Vermutlich kamen hier diverse Punkte zusammen. Eine mögliche Erklärung wäre, 
   dass eine Seite, die vor dem Statify 1.7 Update bereits im Cache lag, solche (
   nicht mehr funktionierenden) Tracking-Aufrufe abgesetzt hat, die dann eine normale
   HTML Seite liefern. Eines der eingebunden Google Skripte könnte diesen Aufruf
   als gültig interpretiert haben (ist er ja auch) und entsprechend hat der Suchindex
   diese URL gelernt.
    Ggf. kam noch ein Theme-Wechsel oder eine Umkonfiguration
   dazu, was die Seite 4 erklären würde. Den Punkt finde ich aber hier eher zweitrangig.
 * > Ich finde das sehr merkwürdig, da die URLs aufrufbar sind und eine Blogübersicht
   > zeigen.
 * Dieser Teil ist tatsächlich das einzig nicht merkwürdige.
    `/page/<Nummer>` ist
   ein Standardmechanismus von _WordPress_, der auf die entsprechende Seite der 
   Blog-Übersicht verweist. Bei vielen Themes, die die Standardmethodik zum Blättern
   nicht nutzen – so wie deines – wird der zusätzliche Parameter einfach ignoriert.
   Du kannst auch `/page/99999` aufrufen. _Statify_ hat hiermit nichts zu tun, der
   Parameter am Ende tut nichts.
 * Nach flüchtiger Übersicht deiner Seite sieht das ganze eigentlich soweit gut 
   aus und es sind keine Hinweise auf eine derartige URL oder ähnliche Überreste
   alter _Statify_-Verhalten auffindbar.
 * Gruß,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Pageviews do not count from 0](https://wordpress.org/support/topic/pageviews-do-not-count-from-0/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/pageviews-do-not-count-from-0/#post-13135448)
 * You can fill the database yourself and migrate data from the other system. The
   model is quite simple, one row per visit.
 * Sample SQL (replace “wp“ if changed):
    `INSERT INTO wp_statify(created, referrer,
   target) VALUES ('2020-07-17', 'https://www.pluginkollektiv.org', '/some/page');`
 * or if you prefer PHP with WP logic:
 *     ```
       $wpdb->insert(
         $wpdb->statify,
         array(
           'created'  => '2020-07-17',
           'referrer' => 'https://www.pluginkollektiv.org',
           'target'   => '/some/page',
         )
       );
       ```
   
 * Referrer and target optional, if only daily counts are of interest. If you have
   aggregates like date => count, you have to add that much entries.
 * Remember configuring an adequately long storage time, otherwise the data is cleaned
   up automatically 😉
 * Cheers,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Display statify dashboard for editors](https://wordpress.org/support/topic/display-statify-dashboard-for-editors/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/display-statify-dashboard-for-editors/#post-13135408)
 * Hi,
 * currently this is possible using a filter hook `statify__user_can_see_stats` (
   [https://statify.pluginkollektiv.org/documentation/hooks/#user_can_see_stats](https://statify.pluginkollektiv.org/documentation/hooks/#user_can_see_stats))
 * You case would be something like the example from the docs:
 *     ```
       add_filter(
           'statify__user_can_see_stats',
           current_user_can('edit_others_pages' )
       );
       ```
   
 * A more convenient configuration is planned for next point release 1.8, however
   no ETA yet. ([https://github.com/pluginkollektiv/statify/issues/106](https://github.com/pluginkollektiv/statify/issues/106))
 * Cheers,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Statify und WP-Optimize](https://wordpress.org/support/topic/statify-und-wp-optimize/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/statify-und-wp-optimize/page/2/#post-13070891)
 * Schön zu hören.
    Das sieht soweit korrekt aus. Status 204 (“No Content”) ist 
   beabsichtigt, da der Aufruf keinerlei Inhalt zurück übermittelt. Die Information,
   ob der Aufruf gezählt oder gefiltert wurde wird nicht zurück gespiegelt, lediglich
   die Erkenntnis dass die Verarbeitung erfolgreich war. Im Fehlerfall gibt es entsprechende
   4xx/5xx Status.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Date one day behind in dashboard](https://wordpress.org/support/topic/date-one-day-behind-in-dashboard/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/date-one-day-behind-in-dashboard/#post-13068004)
 * Joah… Ich zitiere aus dem WP Core Code: “This is the best attempt to reverse 
   that operation into a local time to use.”
 * Der übergebene Zeitpunkt wird als UTC gesehen und der Offset (erneut) herausgerechnet.
   Meine Vermutung hier wäre, dass es von der System und/oder PHP-Zeitzone abhängt,
   was die Rechnung hier tut. Auf meinem lokalen Testsystem (alle Zeitzonen einheitlich
   Europe/Berlin) passt es. Im Container (System+PHP auf UTC, WP Berlin) verschiebt
   es sich nach vorne, was unkritisch ist. Aber eben so kann ein negativer Offset
   reinkommen, dann sind wir bei Uhrzeit 00:00:00 (wir speichern ja nur das Datum)
   eben einen Tag zurück.
 * Wir speichern hier bereits “lokale” Zeitstempel, d.h. die Zone interessiert uns
   bei der Ausgabe gar nicht mehr. Wir sollten also entweder alles als “UTC” ansehen
   oder Konversion gänzlich ignorieren (z.B. gemäß Thorstens Vorschlag).
 * Gruß,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Date one day behind in dashboard](https://wordpress.org/support/topic/date-one-day-behind-in-dashboard/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/date-one-day-behind-in-dashboard/#post-13066948)
 * Hi Peer,
 * you’re talking about the date shown in the tooltip of the rightmost chart entry,
   right?
 * Obvious question in advance: Is there data for “today” that could be shown?
    
   If _Statify_ didn’t count anything (correctly or by error), nothing can be displayed,
   as we do not fill gaps yet.
 * > also after the 1.7.2 update […]
 * 1.7.2 fixed the number days evaluated for the top lists, not the chart. However
   the fix only affected the oldest entry (e.g. with 14 days configured, “today –
   14” had been evaluated, so 15 days in total).
 * The definition of “today” has changed in 1.7.0 though. _Statify_ now only relies
   on the PHP server date where the database server date had been evaluated for 
   the dashboard output before. Both times obviously don’t need to match for several
   reasons.
 * I cannot reproduce your issue on several test and live sites, all of them show
   03.07.2020 (which is correct now at 09:50 CEST).
 * Is your WP date and time(zone) correct? (can easily be verified on the general
   settings page, all examples there are generated from current timestamp)
 * Cheers,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Statify und WP-Optimize](https://wordpress.org/support/topic/statify-und-wp-optimize/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/statify-und-wp-optimize/page/2/#post-13060026)
 * Alles klar, das macht mehr Sinn 😉
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Statify und WP-Optimize](https://wordpress.org/support/topic/statify-und-wp-optimize/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/statify-und-wp-optimize/#post-13059991)
 * _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](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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Statify und WP-Optimize](https://wordpress.org/support/topic/statify-und-wp-optimize/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/statify-und-wp-optimize/#post-13054746)
 * > 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 _Einmal_token. 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Statify und WP-Optimize](https://wordpress.org/support/topic/statify-und-wp-optimize/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/statify-und-wp-optimize/#post-13054525)
 * 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).
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Crazy counting](https://wordpress.org/support/topic/crazy-counting/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/crazy-counting/#post-13050325)
 * I just had a short look at your site again.
 * The WP AJAX call give an error code 403 (i.e. my visit to the front page was 
   not counted) and last lines of the HTML markup show a caching time 58 hours ago.
 * >  Cache file created on: 2020-06-27T07:52:14+00:00
   >  Current time: 2020-06-29T17:
   > 59:22+00:00
 * Reason for the 403 is most likely the ~24h (or at least below 58h) nonce lifetime
   here.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Erratic Stats](https://wordpress.org/support/topic/erratic-stats-2/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/erratic-stats-2/#post-13048058)
 * Hi,
 * sorry for the late response. I assume you’re running the latest stable WP and
   plugin versions, i.e. WP 5.4.x with Statify 1.7.x and JavaScript tracking enabled.
 * Is there any pattern like decreasing counts every x days or is it a more or less
   random distribution?
 * Could you check server logs for calls to _/wp-admin/admin-ajax.php_?
    Every regular,
   countable page hit should be followed by such call with empty response and status
   204.
 * Missing requests could indicate a problem with the JS resources, s.t. the tracking
   is not triggered. 4xx error codes might indicate a caching conflict here.
 * Cheers,
    Stefan
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Statify] Statify und WP-Optimize](https://wordpress.org/support/topic/statify-und-wp-optimize/)
 *  Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/)
 * (@stklcode)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/statify-und-wp-optimize/#post-13045891)
 * Ich hatte in einem anderen Thread einmal die Nonce-Problematik angeschnitten:
   [https://wordpress.org/support/topic/crazy-counting/#post-12946894](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](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.

Viewing 15 replies - 76 through 90 (of 157 total)

[←](https://wordpress.org/support/users/stklcode/replies/page/5/?output_format=md)
[1](https://wordpress.org/support/users/stklcode/replies/?output_format=md) [2](https://wordpress.org/support/users/stklcode/replies/page/2/?output_format=md)
[3](https://wordpress.org/support/users/stklcode/replies/page/3/?output_format=md)…
[5](https://wordpress.org/support/users/stklcode/replies/page/5/?output_format=md)
6 [7](https://wordpress.org/support/users/stklcode/replies/page/7/?output_format=md)…
[9](https://wordpress.org/support/users/stklcode/replies/page/9/?output_format=md)
[10](https://wordpress.org/support/users/stklcode/replies/page/10/?output_format=md)
[11](https://wordpress.org/support/users/stklcode/replies/page/11/?output_format=md)
[→](https://wordpress.org/support/users/stklcode/replies/page/7/?output_format=md)