Title: Stefan Kalscheuer's Replies - page 4 | 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 - 46 through 60 (of 157 total) [←](https://wordpress.org/support/users/stklcode/replies/page/3/?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) 4 [5](https://wordpress.org/support/users/stklcode/replies/page/5/?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/5/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify shows nothing](https://wordpress.org/support/topic/statify-shows-nothing/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 4 months ago](https://wordpress.org/support/topic/statify-shows-nothing/#post-15203797) * Hi, * was anything else changed within the collection period (the last weeks or since whenever it worked)? Caching, theme, other plugins… Typically something does not simply stop working for no reason. * Assuming the output is correct, the obvious reason for “no data” is that there is no date, i.e. no visit was tracked within the configured period. * Reasons for this can vary. For Non-JS tracking every way of caching breaks data collection – however it’s quite tricky to get really no data at all, except for some cache-warming logic that does not trigger tracking by itself. * For JS tracking a theme that does not call `wp_footer()` and thus does not include the Statify script in the output DOM breaks tracking. Also some arbitrary JavaScript error in any other plugin/snipped might cause the browser to stop processing further scripts. I’ve also seen some “admin lockdown” attempts that block calls to `/wp-admin/admin-ajax.php`. * Both mechanisms are affected by exclusion filters, incorrect/missing user agent headers or similar. * Without any additional information about the plugin configuration or the site itself, we can only guess what’s happening here. * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Cachify plugin breaks Facebook sharing](https://wordpress.org/support/topic/cachify-plugin-breaks-facebook-sharing/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 5 months ago](https://wordpress.org/support/topic/cachify-plugin-breaks-facebook-sharing/#post-15093611) * Thanks for your analysis. I totally forgot about the pre-compressed stuff, seems obvious though. * Just checked GZ files generated by Cachify, they seem to be valid, so the PHP GZip module is not broken – at least in my test container. * My suspicion is that the response is missing the expected headers, so the compressed content is transmitted, but a strict client fails to read it without proper indication.( browsers do forgive quite a lot, so very likely no human visitor ever noticed an error) * I don’t have an Apache+WP site on hand to verify. If I’m right, an additional directive like this should fix the problem (documentation should be updated in this case): * ``` Header append Content-Encoding gzip Header append Vary Accept-Encoding ``` * Your site does provide the correct headers now that the server handles compression on-the-fly. (didn’t test that case yesterday) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Cachify plugin breaks Facebook sharing](https://wordpress.org/support/topic/cachify-plugin-breaks-facebook-sharing/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 5 months ago](https://wordpress.org/support/topic/cachify-plugin-breaks-facebook-sharing/#post-15088431) * Hi [@markhowellsmead](https://wordpress.org/support/users/markhowellsmead/), * the old post is now 7 months old without any answer, but I’d assume the reported issue is the very same: [Facebook always gets HTTP 206](https://wordpress.org/support/topic/facebook-always-gets-http-206/) * First pleas note that I do not have any clue what the FB debugger does. Nevertheless let’s try tracking down the issue. * According to the HTML signature you’re using HDD caching. Furthermore from reading the sources and plugin files, you’re using WP 5.8.2 with Cachify 2.3.2. * Next, let’s have a look into the response headers for cached and uncached requests( headers with different contents only): * **Cached:** * ``` Content-Type: text/html Last-Modified: Sat, 20 Nov 2021 18:16:13 GMT Etag: "199a8-61993b6d-97ee3b82b6c57da1;;;" Accept-Ranges: bytes Content-Length: 104872 ``` * **Uncached:** * ``` Content-Type: text/html; charset=UTF-8 X-Pingback: https://permanenttourist.ch/xmlrpc.php Link: ; rel="https://api.w.org/" Link: ; rel="alternate"; type="application/json" Link: ; rel=shortlink ``` * When static content (i.e. cached HTML file) is served, the webserver accepts partial content, indicated by the Accept-Ranges header ([MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges)), so 206 codes are probably fine when partial content is actually requested. * E.g. requests like * ``` $ curl -i -H 'Range: bytes=0-1024' https://permanenttourist.ch/2021/11/axalp-in-the-snow/ $ curl -i -H 'Range: bytes=1024-2048' https://permanenttourist.ch/2021/11/axalp-in-the-snow/ ``` * do exactly what they are expected to do, deliver first and second 1kB-slice with status 206 and header `Content-Range: bytes 0-1024/104872`. * Second the Content-Type header ([MDH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type)) is missing a charset value, that’s what _might_ lead to a bad encoding error. * Are you in control of any webserver settings? Do you have access to server logs that indicate the request headers the FB debugger uses? * Try opening a cached HTML file from the `wp-content/cache/cachify/` directory and verify the encoding in a text editor of choice. * Second thing I would try is placing an arbitrary HTML file anywhere on the server and see what the FB debugger does with that. * Cheers, Stefan - This reply was modified 4 years, 5 months ago by [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/). Reason: clean up the mess due to missing braces - This reply was modified 4 years, 5 months ago by [Steven Stern (sterndata)](https://wordpress.org/support/users/sterndata/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[NSFW] [Statify] Merkwürdige Quellenangabe](https://wordpress.org/support/topic/merkwurdige-quellenangabe/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 7 months ago](https://wordpress.org/support/topic/merkwurdige-quellenangabe/#post-14944974) * Hi Björn, * sieht auf den ersten Blick wie eine versuchte Header Injection aus. Es sind SQL Fragmente zu erkennen, die, wenn sie bspw. ganz naiv in ein Statement zur Statistikerfassung eingebunden werden, Daten abgreifen, verändern o.Ä. * Auf Statify trifft das nicht zu, hier wird bei den DB Operationen sauber escaped( offensichtlich, das Zeug ist ja da angekommen, wo es hin gehört). Also ist es hier glücklicher Weise nur Datenmüll. * Vielleicht sollte man die Plausibilitätsprüfung für Referrer URLs mal etwas nachschärfen. * Wobei das ganze mit `dbms_pipe` oder `pg_sleep` generell eher nicht so aussieht, als sei WordPress das Ziel, da diese Funktionen in den unterstützten MySQL/MariaDB Datenbanken so im Regelfall nicht existieren. * Sieht man immer wieder mal in verschiedensten Formen, gerne nachdem (oder kurz bevor) Sicherheitslücken in Serversoftware oder Frameworks bekannt werden. Dann füttert man sein Botnetz damit und lässt es auf das Internet los. Irgendein Zufallsopfer findet man immer. Je nach Popularität und Impact gern mal koordiniert hunderte Anfragen pro Minute (Confluence vor ein paar Wochen war großartig, eine Woche lang rund 5-10/s auf zwei eher kleinen Instanzen, erst Fernost, dann Osteuropa und etwas GCP/AWS, … aber da war das Potenzial auch nicht ohne, wenn’s klappt). Meist eher harmlos, kurz mal ein paar hundert über wenige Tage. (wenn nicht, sollte man etwas weiter analysieren, warum man so Fokus steht) * Wenn du Serverlogs im Zugriff hast, zeichnet sich ggf. ein simples Muster ab, sodass man ggf. wenige Subnetze sperren kann. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify Filter] DDNS nötig um eigene IP zu filtern?](https://wordpress.org/support/topic/ddns-notig-um-eigene-ip-zu-filtern/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 7 months ago](https://wordpress.org/support/topic/ddns-notig-um-eigene-ip-zu-filtern/#post-14921553) * Hallo [@lenaka](https://wordpress.org/support/users/lenaka/), * ich fürchte, ein DynDNS Dienst wird dir beim deinem Vorhaben nicht weiterhelfen. Damit kannst du zwar von außen immer gleich auf dein Netz zugreifen, umgekehrt ist die Zuordnung aber nicht zwangsläufig möglich. * Ein anderer Ansatz: Bist du i.d.R. auf der Seite eingeloggt? Wenn Ja, ist das Ausschließen angemeldeter Nutzer (Statify Standardeinstellung) eine Option? * Dritte Variante: Man könnte man mit wenigen Zeilen Code einen eigenen Filter schreiben, der z.B. auf ein individuelles Cookie o.Ä. prüft, das du in deinem Browser einmal hinterlegst. * Gruß, Stefan * —- * Ein wenig Hintergrund dazu: (nicht notwendig) * Was der Server sieht, ist einmal die IP Adresse des Clients und, sofern vorhanden, ein Reverse-DNS Eintrag zu dieser Adresse (angenommen die IP sei 198.51.100.42, dann i.d.R. etwas wie “198-51-100-42.pool.provider.example.com” – diese Einträge werden vom Eigentümer der IP gesetzt, bei Privatkunden also fast ausschließlich vom Provider vorgegeben). Welche Hostnamen auf die IP Adresse zeigen, ist nicht ohne weiteres herauszufinden, d.h. der Webserver weiß leider nicht ohne zusätzliche Abfragen, dass “lenaka.dyn.example.com” heute auf 198.51.100.42 zeigt. * Entweder man findet also einen anderen Weg, der WP Konfiguration mitzuteilen, welche IPs auszuschließen sind (eigenes Pseudo-DDNS-Plugin, sodass die IP nicht an einen DNS-Dienst, sondern an dein WP gesendet wird) oder man findet einen ganz anderen Weg. Ich schätze wenn ersteres kein Problem wäre, würden wir hier nicht darüber sprechen 😉 * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] POST admin-ajax](https://wordpress.org/support/topic/post-admin-ajax/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 10 months ago](https://wordpress.org/support/topic/post-admin-ajax/#post-14682954) * First of all please note, that the POST request is an asynchronous “fire and forget“ request and does not impact site rendering time or block the loading chain. * AJAX requests are not cached design. The actual processing time strongly depends on factors like the number of plugins that do initialize (some ignore AJAX and opt out early, some do full initialization) and finally of course the server performance. * Without detailed analysis and comparison on the actual platform, there is no general answer if improvements are possible or how. * > It takes longer than anything else. * Longer than cached, static files, is normal and expected. On my sites I do see a difference of 3-8ms for static files (including cached page markup) and 150- 200ms for AJAX POST. That is of course significantly more, but the absolute time is far from bad and I would not spend a minute of analysis in this case. I’ve seen times of 1s and more for a full, uncached WP cycle in the wild. That’s slow, but not quite unusual. * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Cachify with Elasticache](https://wordpress.org/support/topic/cachify-with-elasticache/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 10 months ago](https://wordpress.org/support/topic/cachify-with-elasticache/#post-14628535) * Hi, * > Whenever I configure it with the cluster endpoint URL / PORT it seems like > its not sending items to the Memcached cluster. * Just to be sure, you’re doing something like this, right? * `apply_filter( 'cachify_memcached_servers', fn () => [ [ '*****.cache.amazonaws. com', 11211 ] ] );` (or equivalent older PHP notation) * Note the nested array, because the result is passed to addServer**s**(). * > I have confirmed that I am able to access elasticache from the EC2 via telnet * Have you checked via PHP? E.g. with such simple roundtrip script using the same settings and methods _Cachify_ uses (just hacked down, might contain typos) * ``` setOptions( array( Memcached::OPT_COMPRESSION => false, Memcached::OPT_BUFFER_WRITES => true, Memcached::OPT_BINARY_PROTOCOL => true ) ); if ( ! $res ) die(" FAILED"); echo " ✓\nadd servers"; $res =$memcached->addServers( array( array( '*****.cache.amazonaws.com', 11211) ) ); if ( ! $res ) die(" FAILED"); echo " ✓\nwrite test object"; $res = $memcached->set( 'testkey', 'testvalue', 60 ); if ( ! $res ) die(" FAILED"); echo " ✓\nread test object"; $res = $memcached->get( 'testkey' ); if ( 'testvalue' !== $res ) { echo " FAILED\n"; print_r( $res ); exit(1); } echo " ✓\ndelete test object"; $res = $memcached->delete( 'testkey' ); if ( ! $res ) die(" FAILED"); echo " ✓"; ``` * If this didn’t do the job yet… Are you using the distribution’s or PECL extension for Memcached or the ElastiCache extension? Cachify always calls `addServers()` with `[['127.0.0.1', 11211]]` by default which might interfere with the autodiscovery feature. I haven’t tried yet, but you could try an empty argument in this case:` apply_filter( 'cachify_memcached_servers', fn () => [] );` * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify & Caching?](https://wordpress.org/support/topic/statify-caching/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 10 months ago](https://wordpress.org/support/topic/statify-caching/#post-14621945) * Hallo Axel, * das Problem ist immerhin einfach: Caching-Zeit länger als Nonce-Gültigkeit (s. o.) Die AJAX Anfrage von Statify liefert auf gecachten Seiten aktuell fast ausschließlich“ 403 Forbidden”, ohne Cache ordnungsgemäß 204. * Passt soweit ganz gut zur Beobachtung, direkt nach dem Neuaufbau des Caches sind die Daten frisch, alles gut. Dann laufen die Nonces zunehmend ab nach 8-12h werden zunehmend weniger Seiten erfasst. Bis der Cache neu aufgebaut wird, durch Ablauf oder Bearbeitung einzelner Inhalte, dann geht das Spiel von vorne los. * Bei entsprechend langen Cache-Zeiten würde es sich wohl anbieten, die Nonce-Prüfung für die Statistik zu deaktivieren (in den Statify Einstellungen). Sollte dieses Problem unmittelbar lösen. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify & Caching?](https://wordpress.org/support/topic/statify-caching/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 10 months ago](https://wordpress.org/support/topic/statify-caching/#post-14604899) * Hallo Axel, * jetzt sieht es etwas anders aus. Ohne Cache wird korrekter Weise _/wp-content/ plugins/statify/js/snippet.min.js_ eingebunden und ruft sauber _wp-ajax.php_ auf. Kommt mit Status 204 zurück, so sollte es sein. * Mit Cache fehlt das JS Snippet, dafür gibt es dann eine _/cache/wpfc-minified/…/… js_, in der eigentlich alle JS Ressourcen zusammengefasst werden sollten. * Die ist recht überschaubar, es fehlt aber auf jeden Fall Statify. Andere Ressourcen werden z.T. ganz normal eingebunden. * Ich sehe entsprechend auf der gecachten und “optimierten” Seite 2 Fehler: - Statify tut nichts - UberMenu muss auf Fallback zurückgreifen und liefert die Meldung in der Browserkonsole: - > Notice: UberMenu initialized via window.load. This indicates that an unrelated > error on the site prevented it from loading via the normal document ready > event. * Da aber ohnehin nur ein sehr kleiner Anteil der Skripte zusammengefasst wird, bringt dies Einstellung im gegebenen Szenario auch nicht allzu viel. Ich würde zunächst versuchen, diese Funktion abzuschalten: “JS kombinieren”. * Wenn das nicht hilft, wäre meine nächste _Vermutung_, dass es ein Problem beim Preload (“Vorlagen”) geben könnte, sodass Statify der Meinung ist, kein Skript einbinden zu müssen und die Seite entsprechend ohne gecacht wird. * Ich komme heute auf jeden Fall nicht mehr dazu, ein Testszenario aufzubauen und einmal zu debuggen, welche Kombination das Problem verursacht, werde es mir die Tage aber auf jeden Fall noch einmal ansehen. Ich weiß, dass _WP Super Cache_ und JS Zusammenfassung mit _Autoptimize_ keine Probleme machen, also kein generelles NoGo. Aber hier läuft es ganz offensichtlich nicht rund. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify & Caching?](https://wordpress.org/support/topic/statify-caching/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 10 months ago](https://wordpress.org/support/topic/statify-caching/#post-14602979) * Wenn die verlinkte Seite eine der betroffenen ist, fehlt hier jede Spur von Statify, auch wenn ich Laden am Cache vorbei durch willkürliche Parameter in der URL ( z.B. …?nocache – fast 10fache Ladezeit wird wohl ohne Cache sein) erzwinge. Das Problem liegt also nicht unmittelbar am Caching. * Du verwendest hier offenbar die WPFC JavaScript „Optimierung“, d.h. JS Ressourcen werden nicht direkt eingebunden, sondern zusammengefasst. Hier fehlt der Statify Teil auf jeden Fall – schlecht. * Ich habe die Einstellungen nicht vor Augen, ggf. kann man das Statify JS davon ausschließen. Das Plugin fügt die Ressource erst recht spät in der `wp_footer()` Phase hinzu, wenn vorher schon rausgesprungen wird, wäre das problematisch. * Die Seite wirft JavaScript Fehler durch einen eingebetteten Avia Cookie Consent Schnipsel, der ausgeführt wird, bevor JQuery geladen ist. Das sollte auf jeden Fall auch korrigiert werden, ob es mit dem Problem zusammenhängt schwer zu sagen. UnerMenu beklagt sich auch, dass die normale Initialisierung (sehr wahrscheinlich dadurch) nicht funktioniert und ein Fallback greifen musste. * Zu den Nonces. Ganz kurz: WP generiert für AJAX Anfragen Einmalcodes (Nonces), um zu legitimieren, dass die Anfrage wirklich von der Seite kommt. Sind nicht ewig gültig, daher kann es bei langen Caching-Zeiten vorkommen, dass die Anfragen mit Status 401 abgewiesen werden. Kann man abschalten, geht ja „nur“ um Statistik, also im Regelfall nichts kritisches. Sollte man im Hinterkopf haben, ist hier aber nicht das Problem. * [https://codex.wordpress.org/WordPress_Nonces](https://codex.wordpress.org/WordPress_Nonces) * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Statify & Caching?](https://wordpress.org/support/topic/statify-caching/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 10 months ago](https://wordpress.org/support/topic/statify-caching/#post-14600869) * Hallo Axel, * hast du JavaScript basierte Erfassung in den Statify Einstellungen aktiviert? Bei längeren Caching anzeigten ggf. mit abgeschalteter Nonce-Prüfung, falls die Gültigkeit nicht ebenfalls erhöht ist. Ohne wird bei Antworten aus dem Cache nichts erfasst und die Zahlen liegen entsprechend deutlich zu niedrig. * Ich betreibe selbst ein paar Seiten mit Statify und WP Super Cache und Caching- Zeiten 4-12h ohne Schwierigkeiten. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] cache folder](https://wordpress.org/support/topic/cache-folder-5/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 11 months ago](https://wordpress.org/support/topic/cache-folder-5/#post-14571910) * Hi [@peterkuwi](https://wordpress.org/support/users/peterkuwi/), * Cachify stores its data in a subdirectory `wp-content/cache/cachify`. * The `cache` directory must be readable and writable by the user running the PHP process and readble by the user running the webserver (if different). This should be the case already, otherwise several WP functions would complain. * Cachify creates the necessary structure during the installation. There should be no need to grant extended permissions manually (777 is most likely unnecessarily high, if the server is well configured, 77x or 75x is typically fine). * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[AntiVirus] Should not alert in PHP comments](https://wordpress.org/support/topic/should-not-alert-in-php-comments/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 11 months ago](https://wordpress.org/support/topic/should-not-alert-in-php-comments/#post-14495480) * You are right, comments usually won’t do any harm. * The theme file scan in the current version is pretty simple, as it scans each line of PHP sources and applies a set of expressions to them, mainly to identify potentially malicious code patterns. Many of them ca be used for good, too, so false positives in the first run are likely normal for complex themes. * A really dumb implementation that scans for `/*` or `//` won’t do the job here, as it’s easy to work around and target for false positives itself, so the routine has to be extended quite a bit. * We will note this (reasonable) request, but to be honest I would not expect to see this extension in the near future. However, everybody is invited to contribute. * Regards, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Cachify-Clearing-Cache deleting Reflinks?](https://wordpress.org/support/topic/cachify-clearing-cache-deleting-reflinks/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 years, 11 months ago](https://wordpress.org/support/topic/cachify-clearing-cache-deleting-reflinks/#post-14494723) * The “clear cache” button does exactly one thing: clear the cache. So afterwards all cached HTML content is gone and the pages will be re-built by WordPress on the next visit. * My intuition is: No, it does not break anything. But anyway it can be tested easily, right? Just simulate a regular user and flush the cache from another browser…. * Little more detail: There are only 2 scenarios I can imagine where clearing the cache removes something from the markup: 1. the link is _only_ present in the cached markup 2. the cached link is no longer available * For the former there is no realistic way to achieve this, because one would have to actively modify the cache data (this is likely not done accidentally). * For the latter case one could consider the cache to be outdated anyway. Relying on outdated cache in general is a really bad idea, because it can be cleared at any time by various actions. * **Edit:** apparently Torsten was faster. Left the reply window open for quite some time… * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify Filter] Admin Besuche und eigene IP wird geloggt](https://wordpress.org/support/topic/admin-besuche-und-eigene-ip-wird-geloggt/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [5 years, 3 months ago](https://wordpress.org/support/topic/admin-besuche-und-eigene-ip-wird-geloggt/#post-13998622) * Ich habe gerade einmal quergetestet. - leere WP 5.6 Installation - PHP 8.0 FPM mit nginx Webserver - Theme _OnePress_ 2.2.6 - Statify 1.8.1 JavaScript Tracking aktiviert, sonst default * Soweit alles gut, eingeloggte Besucher werden nicht gezählt, anonyme Nutzer schon. * Installation von _W3 Total Cache_ 2.1.0 und dann die folgenden Schritte abgearbeitet( nach jedem Punkt Statify getestet): - W3TC aktivieren, ohne Setup - Page Cache (Disk Enhanced) aktivieren - Minification aktivieren alle HTML Optionen (inline CSS/JS, line break) mit“ Minify” CSS (Combine & Minify) mit “Minify” JS (Combine & Minify) mit “JSMin” - Database Cache aktivieren (Disk) - “Don’t cache queries for logged in users” deaktivieren - Object Cache (Disk) aktivieren - Browser Cache aktivieren (Default Einstellungen) * Konnte (leider oder zum Glück, wie man’s nimmt) keine Fehlfunktion feststellen. * Mir fehlt an diesem Punkt leider etwas der Angriffspunkt für weitere Tests. Wenn du magst, kannst du mir die Inhalte der Optionen `w3tc_*` und `statify` zukommen lassen (falls irgendwas geheimes drinsteht raus damit oder privat per Mail/Slack) * Gruß, Stefan Viewing 15 replies - 46 through 60 (of 157 total) [←](https://wordpress.org/support/users/stklcode/replies/page/3/?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) 4 [5](https://wordpress.org/support/users/stklcode/replies/page/5/?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/5/?output_format=md)