Title: Stefan Kalscheuer's Replies - page 2 | 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 - 16 through 30 (of 157 total) [←](https://wordpress.org/support/users/stklcode/replies/?output_format=md) [1](https://wordpress.org/support/users/stklcode/replies/?output_format=md) 2 [3](https://wordpress.org/support/users/stklcode/replies/page/3/?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/3/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Wordfence: Cachify Abandoned Plugin](https://wordpress.org/support/topic/wordfence-cachify-abandoned-plugin/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year, 9 months ago](https://wordpress.org/support/topic/wordfence-cachify-abandoned-plugin/#post-17934301) * Well, you’re right. But making a little dummy change like raising the compatibility flag does not make the plugin “maintained” by strict definition … Frankly, it also doesn’t really make it worse than just ignoring warnings. * The next release 2.4.0 is currently in preparation (finally, after 3 years). We can try to push forward a final test round. (GitHub release PR with beta package, if someone’s curious to try it: [https://github.com/pluginkollektiv/cachify/pull/303](https://github.com/pluginkollektiv/cachify/pull/303)) * If there’s no movement by end of the week I will give 2.3 a quick test with WP 6.6 and maybe just raise the compatibility if there’s no reason against. (I won’t do it blindly) - This reply was modified 1 year, 9 months ago by [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/). Reason: add GitHub release reference * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Works with static sites?](https://wordpress.org/support/topic/works-with-static-sites/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year, 11 months ago](https://wordpress.org/support/topic/works-with-static-sites/#post-17775313) * You still need the `admin-ajax.php` endpoint available (or REST API at `wp-json` with the next release) – obviously, data must be processed and stored somewhere. And make sure that the _Statify_ JS is included in the static markup during generation. * If both is given, tracking should work fine the same way it does with cached sites. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[AntiVirus] Warnmeldung bei Prüfsummenverifikation](https://wordpress.org/support/topic/warnmeldung-bei-prufsummenverifikation-2/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [2 years, 5 months ago](https://wordpress.org/support/topic/warnmeldung-bei-prufsummenverifikation-2/#post-17227675) * Hallo AW, * ich würde behaupten Nein. Wir verwenden in _AntiVirus_ den “_rest\_enabled_” Hook nicht. Um den Verursacher hier zu finden, müsstet du vermutlich einmal per Volltextsuche durch die WP Installation gehen. * Die Meldung ist letztlich auch nur eine Warnung, die Funktionalität ist auch in WP 6.4 noch vorhanden. * Ich erinnere mich an manche Stellen im Netz, wo insb. in den Anfängen der WP API mal empfohlen wurde, den Zugriff u.A. mit diesem Befehl zu unterbinden. Falls das zufällig in der functions.php passiert ist, wäre das eine Erklärung für die Abweichung. Aber das passiert ja eigentlich nicht “aus versehen” im laufenden Betrieb… * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[AntiVirus] Warnmeldung bei Prüfsummenverifikation](https://wordpress.org/support/topic/warnmeldung-bei-prufsummenverifikation-2/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [2 years, 5 months ago](https://wordpress.org/support/topic/warnmeldung-bei-prufsummenverifikation-2/#post-17222550) * Hallo AW, * der Zusammenhang mit dem PHP 8.2 Update ist spannend, dafür habe ich auf Anhieb keine Idee. Kann natürlich auch zeitlicher Zufall sein. * Die Warnung besagt, dass die Prüfsumme der Datei “wp-includes/functions.php” nicht mit der in der WordPress API gemeldeten übereinstimmt – also möglicher Weise manipuliert wurde oder fehlerhaft ist. * Du kannst natürlich die Prüfsummen-Prüfung in den Einstellungen deaktivieren. Dann gibt es keine Warnung mehr, aber wird eben auch nicht mehr geprüft. * Wenn du die “wp-includes/functions.php” nicht bewusst verändert hast, solltest du prüfen, ob sie ggf. fremd oder durch Fehler verändert wurde. Entweder die Hammermethode “Version 6.4.1 erneut installieren” (auf der Update Seite im Admin Dashboard) oder etwas präziser die aktuell laufende WP Version herunterladen ( [https://wordpress.org/download/releases/](https://wordpress.org/download/releases/)), entpacken und die “functions.php” abgleichen bzw. überschreiben. * Gruß, Stefan * Forum: [Reviews](https://wordpress.org/support/forum/reviews/) In reply to: [[AntiVirus] bug in the new version](https://wordpress.org/support/topic/bug-in-the-new-version-2/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [2 years, 6 months ago](https://wordpress.org/support/topic/bug-in-the-new-version-2/#post-17210425) * **Update:** We just released v1.5.1 which includes a small fix that should resolve this issue. * Forum: [Reviews](https://wordpress.org/support/forum/reviews/) In reply to: [[AntiVirus] bug in the new version](https://wordpress.org/support/topic/bug-in-the-new-version-2/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [2 years, 6 months ago](https://wordpress.org/support/topic/bug-in-the-new-version-2/#post-17206484) * Thanks for reporting this. * We will have a look into the issue and push a bugfix as soon as possible. * GitHub reference: [https://github.com/pluginkollektiv/antivirus/issues/135](https://github.com/pluginkollektiv/antivirus/issues/135) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] How reliable is Statify in recording page visits?](https://wordpress.org/support/topic/how-reliable-is-statify-in-recording-page-visits/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [2 years, 6 months ago](https://wordpress.org/support/topic/how-reliable-is-statify-in-recording-page-visits/#post-17205788) * It’s not only bots and crawlers, also error pages, logged-in users, access to the admin dashboard, etc. * And a fair amount of HTTP(S) requests is simply additional resources, images, videos, scripts, stylesheets, fonts, icons, API calls, … So one real page “visit“ can easily make 20 requests – of which _Statify_ counts 1. * Also the _Statify_ tracking via JS itself is one additional request, which at least doubles the numbers in the access logs. * There is a chance that Statify is misconfigured and thus counts less hits than it should. E.g. when using a “long“ page cache that exceeds nonce lifetime (default is 12h IIRC). In this case you might see numerous requests to the _Statify_ endpoint with error 403 in the logs. * But after acc, a factor of let’s say 10 to 100 (strongly depends on some factors) between actual page views by humans and HTTP requests in the access logs is something you should expect in normal operation. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Database size](https://wordpress.org/support/topic/database-size-10/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [2 years, 8 months ago](https://wordpress.org/support/topic/database-size-10/#post-17042216) * The answers strongly depend on some factors. * Every visit has an ID (8 Byte) and a date (3 Byte). Plus referrer URL and request path which can vary from 0 to 255 characters (i.e. each 1020 Byte worst case) * Plus DB index overhead. Minus potential optimization from the DB backend, both paths and referrers are often duplicated. * From a real-world site I have 4000 visits in a database with a total of 560 KiB storage (224 KiB data, 336 KIb index). So roughly 150 KiB per 1000 visits, maybe 200-250 should be a fair estimate. * (if aggregation will be there anytime in the future, the reduced size will also depend on the distribution of targets and referrers) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Pass mobile friendly check](https://wordpress.org/support/topic/pass-mobile-friendly-check/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [3 years ago](https://wordpress.org/support/topic/pass-mobile-friendly-check/#post-16729947) * Cachify does not generate any CSS/JS files in the cache directory, there are just cached HTML files that must not be accessed directly. * If I look at the cached contents, e.g. _/wp-content/cache/cachify/index.html_ I do see the original JS/CSS ressources in the markup, e.g. `` * If that’s not the case on your site, there might be a different problem. IIRC _Cachify_ never should have done such thing… * My guess is that the issue has nothing to do with the _robots.txt_ (at least not with the default generated one) or any CSS/JS insinde the “cachify” directory at all. Google most likely complains about missing cachability of the resources, e.g. missing `Expires` header to tell the browser that the file should be cached. * Maybe you could share a link if the site is publicly available, so we might actually see the issue. - This reply was modified 3 years ago by [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Was bedeutet “Nicht erlaubte Verweise”](https://wordpress.org/support/topic/was-bedeutet-nicht-erlaubte-verweise/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [3 years, 2 months ago](https://wordpress.org/support/topic/was-bedeutet-nicht-erlaubte-verweise/#post-16572545) * > Das bedeutet, ohne diese unerlaubten Verweise müssten sich die Zugriffszahlen > drastisch reduzieren. * Wie “drastisch” das ist, kann man pauschal nicht sagen. Das hängt ganz wesentlich davon ab, wie der Traffic der Seite so aussieht und ob in der Sperrliste etwas dazu passendes eingetragen ist. * Eine leere Sperrliste ändert gar nichts. Eine unpassende genauso wenig. * Ich habe Seiten mit 5.000 solcher Aufrufe pro Tag gesehen, auf anderen sind es 5 pro Monat… * > Würde ich aber bei deaktivierten Zustand diese Verweise nicht in der Übersicht( > Statify Extended) sehen müssen? * Ja. Wenn du es aktuell deaktiviert hast, kannst du in den Top-Listen, Extended Evaluation oder der Datenbank sehen, was da so reinkommt und ggf. Sperrlisten anpassen. * > Ich hatte nämlich dazu schonmal gelesen, dass man irgendwie selbst eine Blacklist > erstellen muss, mit einem weiteren Plugin. * Die Listen müssen befüllt werden und am besten zum Seitentraffic passen. Standardmäßig sind sie leer. * Oftmals kann man dazu auf weit verbreitete Standardlisten zurückgreifen und diese ggf. automatisch aktualisieren. Dazu gibt es z.B. ebenfalls vom _Pluginkollektiv_ das Plugin [Block List Updater](https://de.wordpress.org/plugins/blacklist-updater/).( welches automatisch aus[ Comment Blocklist for WordPress (GitHub)](https://github.com/splorp/wordpress-comment-blacklist) aktualisiert) * Wenn Referrer- und Kommentar-Spam deutlich auseinander gehen oder man aus anderen Gründen unterschiedliche Filter benötigt, kann man auf andere Filterplugins zurückgreifen, z.B. [Statify Filter](https://de.wordpress.org/plugins/statify-blacklist/) (das auch noch IP oder aufgerufene Seiten filtern kann – muss aber auch individuell konfiguriert werden) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Was bedeutet “Nicht erlaubte Verweise”](https://wordpress.org/support/topic/was-bedeutet-nicht-erlaubte-verweise/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [3 years, 2 months ago](https://wordpress.org/support/topic/was-bedeutet-nicht-erlaubte-verweise/#post-16572173) * Dabei handelt es sich um das Ausschließen von Seitenaufrufen, bei denen die Herkunft( Verweis / Referrer) einem Muster aus der eingebauten Sperrliste entspricht. ( oder eine solche Herkunft vorgegakuelt wird, als Werbung durch die Hintertür oder schlicht Spam, Stichwort “Referrer Spam” ([Wikipedia](https://de.wikipedia.org/wiki/Referrer-Spam))). * _WordPress _ bietet eine eingebaute Sperrliste für Kommentare (Einstellungen > Diskussion > Kommentar-Sperrliste). Wenn das Häkchen bei “Nicht erlaubte Verweise” gesetzt ist, wird die gleiche Sperrliste auch von _Statify_ herangezogen, um Aufrufe entsprechend von der Zählung auszuschließen. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify führt Zugriffe von eigener Startseite unter Verweise auf](https://wordpress.org/support/topic/statify-fuhrt-zugriffe-von-eigener-startseite-unter-verweise-auf/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [3 years, 3 months ago](https://wordpress.org/support/topic/statify-fuhrt-zugriffe-von-eigener-startseite-unter-verweise-auf/#post-16385806) * “Geht nicht” gibt’s nicht. Es gibt nur keinen trivialen Schalter dafür. * Du kannst über den “statify__skip_tracking” Hook ([https://statify.pluginkollektiv.org/de/documentation/hooks/](https://statify.pluginkollektiv.org/de/documentation/hooks/)) nahezu beliebige Aufrufe von der Zählung ausschließen. * Oder etwas komfortabler mit dem “Statify Filter” Plugin ([https://de.wordpress.org/plugins/statify-blacklist/](https://de.wordpress.org/plugins/statify-blacklist/)) einen Referrer-Filter konfigurieren, der Herkunft mit einem Regulären Ausdruck wie “/.+” oder “^(?!https?:).+” oder ähnlich so filtern, dass diese eben rausfallen. * Das ganze hat einen Nachteil: Nicht jeder Browser sendet die Referrer-Header auch vollständig mit. Links mit “no-referrer” (findet man für interne Links eher weniger) geben das explizit an, gibt aber auch vermeintliche Privacy-Plugins, die das Filtern. Letztendlich ist die Anzahl “ohne Herkunft” daher naturgemäß verrauscht und kann auch im Standardzustand interne Sprünge enthalten.Mit dieser Unschärfe muss man leben, wenn man auf weitere Tracking-Maßnahmen wie Cookies, Sessiondaten o.Ä. verzichtet. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify führt Zugriffe von eigener Startseite unter Verweise auf](https://wordpress.org/support/topic/statify-fuhrt-zugriffe-von-eigener-startseite-unter-verweise-auf/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [3 years, 4 months ago](https://wordpress.org/support/topic/statify-fuhrt-zugriffe-von-eigener-startseite-unter-verweise-auf/#post-16382407) * Das ist eine Fehlannahme. * _Statify_ zählt Seitenaufrufe, keine Besucher. Also in logischer Konsequenz alle Aufrufe, die nicht durch einen der vordefinierten Filter fallen (Bots, eingeloggte Benutzer, Fehlerseiten, etc.). Ob die Aufrufe von intern, extern oder unbekannter Quelle stammen, spielt dabei erstmal keine Rolle. * Was möchtest du genau tun? Aufrufe mit interner Herkunft gar nicht erfassen ( also quasi einen Besucher- und keinen Aufrufzähler bauen) oder die interne Herkunft nur aus den Top-Listen ausblenden, die Aufrufe aber trotzdem zählen? * Ersteres wäre vergleichsweise einfach umsetzbar, gibt aber einige Gründe dagegen, letzteres ist momentan nicht Umsetzbar, aber eine gute Idee für eine Erweiterung der Anzeigeeinstellungen. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Counter als neue Spalte in Betragstabelle anzeigen](https://wordpress.org/support/topic/counter-als-neue-spalte-in-betragstabelle-anzeigen/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [3 years, 5 months ago](https://wordpress.org/support/topic/counter-als-neue-spalte-in-betragstabelle-anzeigen/#post-16299921) * Den/die Post Typ(ein), für den/die du das Feld definieren möchtest. Bei Beiträgen und Seiten tendenziell wohl “post“ und “page“. ([https://wordpress.org/support/article/post-types/](https://wordpress.org/support/article/post-types/)) * Wie das Feld heißt, spielt keine große Rolle. Muss eindeutig sein und grundsätzlich wäre etwas sprechendes wie “visits“, “visit_count“, “statify_hits“ o.Ä. wohl sinnvoll. * Wie du an die Daten kommst, ist klar? Wenn sich die Permalinks der Seite nicht ändern, genügt hier ein Reverse-Lookup in der Statify-Tabelle gefiltert nach “ target“ Spalte. * Wenn sich der Link zur Seite geändert haben sollte, wird es etwas komplexer, dann muss man durch die Revisionen gehen in der Hoffnung und ganz streng genommen auch zeitlich Filtern, um Überschneidungen zu vermeiden. Kommt das nicht regelmäßig vor, ist der Fall wohl erstmal vernachlässigbar. * Wenn der Plan war, direkt eine Meta Spalte am Beitrag zu füllen, kann das natürlich auch direkt im Hook nach der Erfassung des Besuchs geschehen. In dem Fall ist ja nur die momentane URL interessant. * Gruß, Stefan - This reply was modified 3 years, 5 months ago by [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] WordPress compatibility](https://wordpress.org/support/topic/wordpress-compatibility-12/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [3 years, 5 months ago](https://wordpress.org/support/topic/wordpress-compatibility-12/#post-16223065) * Hi Arno, * sorry for the late response. * You are right, the plugin in the current version 2.3.2 _should_ work fine with latest WordPress 6.1. * The team is currently working on finalizing the long planned update to 2.4 (nothing breaking), but unfortunately little short of time. If we don’t manage to push this update in the next days, we probably add a round of testing and raise the compatibility flag for 2.3 * Cheers, Setfan Viewing 15 replies - 16 through 30 (of 157 total) [←](https://wordpress.org/support/users/stklcode/replies/?output_format=md) [1](https://wordpress.org/support/users/stklcode/replies/?output_format=md) 2 [3](https://wordpress.org/support/users/stklcode/replies/page/3/?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/3/?output_format=md)