Title: Stefan Kalscheuer's Replies - page 7 | 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 - 91 through 105 (of 157 total) [←](https://wordpress.org/support/users/stklcode/replies/page/6/?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)… [6](https://wordpress.org/support/users/stklcode/replies/page/6/?output_format=md) 7 [8](https://wordpress.org/support/users/stklcode/replies/page/8/?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/8/?output_format=md) * 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-13045701) * [@hollo](https://wordpress.org/support/users/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](https://wordpress.org/support/users/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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Länder ein- oder ausschließen](https://wordpress.org/support/topic/lander-ein-oder-ausschliesen/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [5 years, 11 months ago](https://wordpress.org/support/topic/lander-ein-oder-ausschliesen/#post-12960876) * Hallo Markus, * aktuell ist es nicht Konfiguration möglich und auch nicht vorgesehen. Ich habe für mein Erweiterungs-Plugin “Statify Blacklist” bereits die selbe Anfrage auf dem Tisch liegen, daher ist das Thema nicht ganz neu. * Länder lassen auch entweder durch Verarbeitung der IP Adresse oder (unzuverlässigen) Auswertung der Sprach-Header im Browser ermitteln. Dazu müsste aber eine GeoIP PHP-Erweiterung samt Datenbank installiert sein oder Statify seine eigene Datenbank mitliefern. * Die Alternative, Browser-Header, ist sehr ungenau (die Hälfte meiner Rechner z.B. leben in en-US und nicht de-DE und Spambots halten sich eh nicht an Regeln) * Stand jetzt müsste man die Logik selbst implementieren und über den Hook `statify__skip_tracking` einbinden. * Achtung Eigenwerbung: Viel Spam lässt sich auch über Referrer Blackliste eliminieren. Entweder die eingebaute Kommentar-Blacklist oder selbst steuerbar über eine eigene Liste oder auch IP Subnetz-Filter mit der o.g. Erweiterung. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify causes 400 error (admin-ajax.php)](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [5 years, 11 months ago](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/#post-12946946) * Ich habe den Fehler _400_ mittlerweile reproduzierbar nachstellen können. * Er tritt auf, wenn Tracking für angemeldete Benutzer deaktiviert ist (wie von [@jazzminus](https://wordpress.org/support/users/jazzminus/) beschrieben), dann aber nur bei angemeldeten Benutzern. Grund ist, dass die AJAX Aktion in diesem Fall gar nicht registriert wird und der Endpunkt diese abweist. * **Das Fehlerbild ist harmlos**, da es nur auftritt, wenn sowieso nicht getrackt werden soll. Da es aber das Log mit unnötigen Meldungen zumüllt, werden wir das Problem mit einem kommenden Update korrigieren. ([https://github.com/pluginkollektiv/statify/pull/159](https://github.com/pluginkollektiv/statify/pull/159)) * —- * Der Fehler 403 hat eine andere Ursache, höchstwahrscheinlich eine zu lange bzw. nicht zum Nonce-Timeout passende Caching-Zeit. Etweder die Caching-Zeiten auf sicher <24h reduzieren oder die Nonce Lifetime entsprechend erhöhen ([https://codex.wordpress.org/WordPress_Nonces](https://codex.wordpress.org/WordPress_Nonces) section “Modifying the nonce lifetime”) - This reply was modified 5 years, 11 months ago by [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/). * 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, 11 months ago](https://wordpress.org/support/topic/crazy-counting/#post-12946894) * Because it seems to happen periodically, I’d suspect a caching issue here. Both random subpages I’ve checked have timestamps between 1 and 3 hours ago, so pretty fresh, and tracking works as expected. * You might verify my theory if you got access to the server’s access logs. WP AJAX requires a nonce to be transmitted for access to a certain action. Nonces are valid for 24h by default (not exactly, see codex link below for details on the tick structure). If an outdated nonce is used due to caching, the call to`/ wp-admin/admin-ajax.php` results in error 403 instead of correct 204. * After quick analysis you’re using _WP Fastest Cache_, _Autoptimize_ and finally the _Cloudflare_ cache. * Autoptimize is out, because the nonce is placed in the site markup directly, so the aggregated caching time of WPFC and Cloudflare is crucial here. * If I’m correct, you can either adjust the caching times or increase the nonce lifetime: [https://codex.wordpress.org/WordPress_Nonces](https://codex.wordpress.org/WordPress_Nonces)( section “Modifying the nonce lifetime”). * Plugins requiring a “fresh” nonce usually do validate the age in custom logic, so in most cases, a (reasonably) longer time should not raise any problems. * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify causes 400 error (admin-ajax.php)](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [5 years, 11 months ago](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/#post-12912119) * 403 am AJAX Endpunkt bedeutet für gewöhnlich Nonce, also Einmalcode zur Identifizierung abgelaufen. Diese sind standardmäßig 24h gültig. * Zumindest auf der Seite von [@blacckmamba](https://wordpress.org/support/users/blacckmamba/) war _Cache Enabler_ aktiv. Hier ist nicht zufällig eine längere Zeit konfiguriert? * [@jazzminus](https://wordpress.org/support/users/jazzminus/) Welche Fehlercodes erhälst du, auch 403 oder etwas anderes? Die Option für angemeldete Benutzer dürfte auf das Verhalten keinen Einfluss haben, aktiviert lediglich eine zweite AJAX Action mit dem selben Namen (rein technische Gründe, angemeldet und anonym sind im Backend getrennt) und nimmt einen Filter raus. Da Caching für angemeldete Nutzer aber meist deaktiviert ist, wäre das eine mögliche Erklärung. * Hättest du ansonsten ggf. eine öffentliche URL sodass wir das Problem nachvollziehen können? Wenn es zufällig die aus deinem Profil ist, dann erhalte ich Stand jetzt einen korrekten 204. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify causes 400 error (admin-ajax.php)](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [5 years, 11 months ago](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/#post-12905543) * Ich bekomme keinen 400, sondern korrekt 204. * In der Netzwerkübersicht der Entwicklertools finde ich den Aufruf so: * > Request URL: [https://*****/wp-admin/admin-ajax.php](https://*****/wp-admin/admin-ajax.php) > > Request Method: POST Status Code: 204 […] Form Data: _ajax_nonce: **********( > normaler Hex-String) action: statify_track statify_referrer: statify_target:/ * Identisch für eine zufällige Unterseite. Getestet mit aktuellen Chrome 83 und Firefox ESR 68 (Linux) ohne Plugins mit initial leeren Caches. * Kannst du Details wie die oben genannten über deinen Fehlerhaften Aufruf machen? 400 am AJAX Endpunkt bedeutet ja für gewöhnlich dass eine ungültige Action übergeben wurde. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify causes 400 error (admin-ajax.php)](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [5 years, 11 months ago](https://wordpress.org/support/topic/statify-causes-400-error-admin-ajax-php/#post-12899916) * Hi Blacc, * which versions of Statify and WordPress are you using? * And can you provide additional details about the failing request or a link to see the behavior? I’m especially interested in the transmitted POST body, i.e. the parameters “_ajax_nonce”, “action”, “statify_referrer” and “statify_target”. * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Top Referrer: eigene IP Adresse???](https://wordpress.org/support/topic/top-referrer-eigene-ip-adresse/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [5 years, 11 months ago](https://wordpress.org/support/topic/top-referrer-eigene-ip-adresse/#post-12888890) * Hallo Christian, * ist JavaScript Tracking aktiv? * **Wenn Ja:** Dann wird der Referer durch JavaScript im Browser ermittelt. * Die einfachste Erklärung wäre hier, dass es tatsächlich eine Umleitungen oder Links von der IP Adresse (also default vHost) auf deine Seite und diese werden auch aufgerufen. Das Verhalten der Header ist hier abhängig von der eingesetzten Weiterleitungstechnik und dem Browser des Clients. * Gibt es solche Links bzw. wo landest du, wenn du im Browser auf die IP zugreifst? * Oder eine – mir nicht konkret bekanntes – Browsererweiterung, die sowas zur “ Anonymisierung” setzt. Nicht unbedingt sinnvoll (man könnte den Referrer ja auch einfach leer lassen), aber hier gibt es einige seltsame Konstruktionen… * **Wenn Nein:** Dann wertet Statify den [“Referer” HTTP Header](https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Referer) aus. * Dann kann es neben der o.g. Möglichkeit sein, dass die Serverkonfiguration nicht optimal ist und die Header unvorteilhaft füllt. Wird PHP als FCGI oder FPM Modul eingesetzt, wird die Anfrage formal intern umgeleitet. Je nach Szenario müssen hier die Header korrekt durchgeschliffen werden. Gleiches Spiel für Reverse Proxy Setups. * Wenn du Zugriff auf Access-Logs des Webservers hast und hier die betreffenden Header rausloggen kannst, wäre das sicher aufschlussreich. * —- * Es kann natürlich auch eine seltsame Form vom Referer Spam sein oder irgendein exotischer Bot, der als Pseudo-Referer die Ziel-IP nutzt, oder ein Monitoring- System das durch den Filter fällt. In Statify 1.7.0 wurde die Filter-Liste für Bots unvollständig umgestellt und in 1.7.1 wieder nachgebessert… * Gruß, Stefan - This reply was modified 5 years, 11 months ago by [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] “Bei [Website-URL] anmelden. Deine Anmeldedaten werden sicher übertragen”](https://wordpress.org/support/topic/bei-website-url-anmelden-deine-anmeldedaten-werden-sicher-ubertragen/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 years ago](https://wordpress.org/support/topic/bei-website-url-anmelden-deine-anmeldedaten-werden-sicher-ubertragen/#post-12848469) * Hallo Dirk, * offenbar hast du den Admin-Bereich durch eine Basic Authentication doppelt abgesichert. Hierunter fällt auch der WP AJAX Endpunkt `/wp-admin/admin-ajax.php`, den Statify seit 1.7 zum Tracking nutzt. Statify scheint dein einziges Plugin zu sein, das diesen Endpunkt im Frontend nutzt, sonst wäre es sicher bereits aufgefallen. * Sieht man gut in Netzwerkübersicht der Entwicklerwerkzeuge im Browser. Wenn man die Anmeldung abbricht, liefert der Statify Aufruf Status 401. * Um Statify zu nutzen, solltest diesen Endpunkt von der Authentifizierung ausnehmen. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Seit Update 1.7.0 unvollständige Zählung](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 years ago](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/#post-12835145) * Hallo Inga, * > Bei den Fehlern sehr ich zwei js-fehler (preload und jquery) sowie 2 Fehler, > die im Quellcode meiner Seite zu finden sind. > […] ich nehme an, dass das aktuelle > Statify-Problem auf die beiden js-Script-Fehler zurückzuführen ist. Richtig? * Indirekt wahrscheinlich Ja. Wenn der Browser beim JS einmal in Fehler läuft und das nicht im Skript selbst abgefangen wird, läuft in der Kette danach auch nichts mehr weiter. * Was geladen wird, hängt natürlich von deinem Browsercache, den lokal im System installierten Schriftarten, etc. ab. Mein Testbrowser ist “jungfräulich”, also zu erwarten, dass ich mehr Ladefehler bekommen hatte. * > Was bedeutet “CORS Sicherheitseinstellungen” und wo finde ich die? * [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) * Im Prinzip setzt der Webserver oder die Anwendung HTTP-Header, die vorgeben, welche Ressourcen auf welche Weise von wo geladen werden dürfen. Ob das der Webserver macht, ein WordPress Plugin lässt sich von außen nicht sagen. * Das Problem betraf die Schriftarten, da sie von einer anderen (Sub)Domain kamen– scheint ja inzwischen gelöst. * —- * Die jetzt noch relevante Meldung ist * > Refused to execute inline script because it violates the following Content > Security Policy directive: “script-src ‘self'”. Either the ‘unsafe-inline’ > keyword, a hash (‘sha256-Oo1bdSPsp6CjaJ69F4foXm6agCkwFfBGUBZTPn9iRfM=’), or > a nonce (‘nonce-…’) is required to enable inline execution. * “Verursacht” durch eine “Content Security Policy” `default-src 'self'`. ([https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)) * Erfreulich, solche Einstellungen in freier Wildbahn zu finden, wird oft genug ignoriert. Allerdings hat CSP auch viele Fallstricke, da Systeme wie WordPress eben doch an diversen Stellen Inline-JS, also Skript-Blöcke im HTML einsetzen, ohne passende Behandlung. * Einfache Abhilfe könnte eine Erweiterung wie `script-src 'unsafe-inline' https:// ingalandwehr.de` schaffen oder auch beliebig komplexere Konfiguration. * Wo die Daten gesetzt werden, kann man von außen natürlich nur vermuten. Ich hoffe die Ansatzpunkte helfen weiter. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Seit Update 1.7.0 unvollständige Zählung](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 years ago](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/#post-12834989) * Hallo Raimund, * > Ich nehme an, damit ist der prüfende Blick in den Seitenquelltext gemeint […] > > Dort finde ich (in unserer Startseite) aber lediglich den Schnipsel (var statify_ajax > = …) und zwar am Seitenende. Das von Dir erwähnte Script (…ver=1.7.0) ist jedoch > nicht enthalten. Was bedeutet das nun für uns? Handlungsbedarf? * Ja, meinte ich. Das ist in deinem Fall so in Ordnung, da _Autoptimize_ das Skript schluckt und in die _autoptimize\_<…>.js_ am Ende der Seite integriert. Hier findest du den Statify-Abschnitt wieder (in deinem Fall ganz unten). * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Seit Update 1.7.0 unvollständige Zählung](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 years ago](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/#post-12834402) * Hallo Inga, * macht ja nichts. * HTML Code sieht man über REchtsklick -> Quellcode anzeigen (oder meist Strg+U bzw. Option+Cmd+U). In den “Entwickler-Tools” des Browsers (die man natürlich auch als Nicht-Entwickler benutzen darf), erreichbar meist über F12, gibt es i.d.R. einen Reiter “Netzwerk”, der die einzelnen Anfragen auflistet. * Sieht z.B. so aus (andere Browser vergleichbar): [https://developers.google.com/web/tools/chrome-devtools/network#load](https://developers.google.com/web/tools/chrome-devtools/network#load) * Deine Seite sieht nach flüchtiger Beurteilung prinzipiell gut aus (auch technisch 😉 ), d.h. das aktuelle Statify ist im Autoptimize Block enthalten und die Variable ist auch vorhanden. Soweit so gut. * Allerdings sehe ich in der Browserkonsole Fehlermeldungen, dass durch Sicherheitseinschränkungen Skriptausführung blockiert wird. Die betroffene Zeile ist ein “shariff”-Block, da hier aber abgebrochen wird, ist auch die “var statify_ajax = …” Zeile betroffen. Entsprechend wird das Skript später zwar aufgerufen, aber kann ohne Konfiguration nicht arbeiten. * Ich würde dir empfehlen, die Einstellungen der Seite einmal zu prüfen oder prüfen zu lassen. Das Problem betrifft tendenziell nicht nur Statify (die Methodik, wie WordPress die AJAX-Blocks initialisiert ist ja für alle gleich). Auch wird durch eine CORS Sicherheitseinstellung verhindert, dass diverse Schriftarten von der Subdomain “tgc.ingalandwehr.de”, was sicherlich auch nicht in deinem Sinn ist. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Seit Update 1.7.0 unvollständige Zählung](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 years ago](https://wordpress.org/support/topic/seit-update-1-7-0-unvollstandige-zahlung/#post-12834034) * Hallo Raimund, Hallo Inga * in 1.7 wurde das JavaScript-Tracking grundlegend umgestellt (von einer selbst gestalteten Methodik auf das deutlich leichtgewichtigere WP AJAX). Da zumindest Raimunds Seite ein Caching-Plugin nutzt, müsste der Cache nach der Aktualisierung des Plugins einmal geleert werden, damit der neue Skript-Teil in das HTML Markup kommt. Das ist wäre die wahrscheinlichste Erklärung. * _Cachify_ würde vom Plugin bei (de)aktivierung selbstständig geleert, aber es gibt ja noch viele andere, die nicht abgedeckt werden (WP Super Cache, W3 Total Cache, Cache Enabler, …), die nach dem Update einmal manuell geleert werden sollten. Das zu tun ist aber grundsätzlich bei vielen Plugin-Updates mit Auswirkungen am Frontend sinnvoll. * Wenn ich die Seite jetzt aufsuche, sehe ich im Browser-Log einen gültigen Statify Request mit Code 204 (Request auf “admin-ajax.php”). Schätzungsweise ist in der Zwischenzeit der Cache der Startseite abgelaufen oder wurde geleert. * Im HTML Markup muss das Statify Skript der aktuellen Version (“/wp-content/plugins/ statify/js/snippet.min.js?ver=1.7.0”) eingebunden sein (sofern nicht durch Autoptimize o.Ä. zusammgnestrichen) und ein kleiner Schnipsel mit dem Inhalt “var statify_ajax = …”. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Zeige Gesamtzahlen – Dashboard](https://wordpress.org/support/topic/zeige-gesamtzahlen-dashboard/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 years ago](https://wordpress.org/support/topic/zeige-gesamtzahlen-dashboard/#post-12825408) * > Wenn es schon um Gesamtzahlen geht, warum sollen denn nur Zahlen aus dem im > Widget eingestellten Zeitraum angezeigt werden. Ich finde, es könnte das Datum > von dem Tag der Erstaufbewahrung verwendet werden. * Genau so habe ich es in meiner Korrektur gemacht. Wenn die Änderung durchkommt, wird dann der gesamte Zeitraum der Datenbank korrekt ausgegeben. * So war die Funktion ursprünglich auch gedacht, dann kam die Trennung Anzeige/ Speicherung parallel dazu und am Ende hat keiner mehr so genau hingesehen, ob das wirklich zusammen passt… * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] favicon.ico](https://wordpress.org/support/topic/favicon-ico/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 years ago](https://wordpress.org/support/topic/favicon-ico/#post-12823607) * I’d never dare to call you stupid because of that. I’m sorry if I came across like that. Thee are lots of aspects to completely understand how the exact numbers are made up. * You are absolutely right, tracking the favicon accesses was incorrect. That’s why we excluded it from now on. If a user visits a real, countable target and loads the icon, **both** hits have been counted. So the only safe statement in this case is, your total number of hits is too high by 124. * One might think, the icon should be #1 in the list and the number should be at least as high as the sum of all other targets (even (uncounted) error pages have a favicon). But in fact not every page visit reloads the favicon from the server, it’s cached on the client. So 124 hits on the icon could be triggered by 124 ( new) visitors, but it could easily be 200, 500 or more (recurring) visitors. Hard to guess the real correlation. * Anyway the false hits will disappear after 14 days (or whatever number you configured). Viewing 15 replies - 91 through 105 (of 157 total) [←](https://wordpress.org/support/users/stklcode/replies/page/6/?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)… [6](https://wordpress.org/support/users/stklcode/replies/page/6/?output_format=md) 7 [8](https://wordpress.org/support/users/stklcode/replies/page/8/?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/8/?output_format=md)