Title: Stefan Kalscheuer's Replies | 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 - 1 through 15 (of 157 total) 1 [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)… [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/2/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Liveticker (by stklcode)] RSS-Feed](https://wordpress.org/support/topic/rss-feed-272/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [4 months, 3 weeks ago](https://wordpress.org/support/topic/rss-feed-272/#post-18763827) * Hallo Sebastian, die URL ist zugegeben nicht besonders intuitiv, aber setzt sich aus dem Content-Type und der Titelform (Slug) des Tickers zusammen: * ```wp-block-code https://example.com/scliveticker_tick/feed/?scliveticker_ticker=... ``` * In deinem Fall käme am Ende dann “notfallinfo” dran. * Vielleicht sollte ich mal einen Link in der Ticker-Übersicht einfügen, damit man den immer findet, ohne dass man den RSS-Link im Shortcode reinkonfiguriert. * Gruß, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Daten fehlen, dafür Views vom 7.2.2036](https://wordpress.org/support/topic/daten-fehlen-dafur-views-vom-7-2-2036/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [6 months, 3 weeks ago](https://wordpress.org/support/topic/daten-fehlen-dafur-views-vom-7-2-2036/#post-18694959) * Hallo Ute, * ein Zeitfehler auf dem System wäre tatsächlich auch meine erste Vermutung gewesen. Statify verlässt sich wie die meiste Software auf die Serverzeit, die offenbar ein wenig in der Zukunft lag. * Wenn der Zeitraum bekannt ist, könnte man natürlich ein SQL Statement schreiben, das die Einträge zurück in die Vergangenheit holt, also alles vom 07.02.2036 auf den 07.10.2025 korrigiert oder bei mehrtägiger Störung alles aus dem Zeitraum um 3775 Tage zurück. * ```wp-block-code -- SELECT zur PlausibilitätsprüfungSELECT created, DATE_SUB(created, INTERVAL 3775 DAY) AS created_fixed FROM wp_statify WHERE created >= '2036-02-07' LIMIT 10;-- Aktualisierung der DatenUPDATE wp_statify SET created = DATE_SUB(created, INTERVAL 3775 DAY) WHERE created >= '2036-02-07'; ``` * (ein Backup kann nie schaden, Verwendung auf eigene Gefahr) * Gruß, Stefan - This reply was modified 6 months, 3 weeks ago by [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/). Reason: Statements ergänzt * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[AntiVirus] DIsmiss](https://wordpress.org/support/topic/dismiss-2/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [7 months ago](https://wordpress.org/support/topic/dismiss-2/#post-18684332) * Should be fixed with 1.6.1 * Briefly tested with different browsers and a couple of simulated findings across multiple theme files (1-3 per file), looks good for me. * Please let us know if you still experience issues. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[AntiVirus] DIsmiss](https://wordpress.org/support/topic/dismiss-2/) * Plugin Author [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [7 months ago](https://wordpress.org/support/topic/dismiss-2/#post-18683614) * Looks like this problem appears on multiple issues within one file. Due to a regression from rewriting the JavaScript in 1.6 only the last “dismiss” button actually works while click listeners of previous buttons get removed in the loop. * Unable to reproduce the problem with one issue per file, even with multiple files. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] cachify_modify_output not working](https://wordpress.org/support/topic/cachify_modify_output-not-working/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [8 months, 3 weeks ago](https://wordpress.org/support/topic/cachify_modify_output-not-working/#post-18615575) * Hi Rayaan, * thanks for reporting this. I guess you have added something close to our doumentation. * Looks like the documented example is incorrect and triggers an error: * > Too few arguments to function … 1 passed in … and exactly 4 expected * Depending on your use case, either remove the additional parameters or add the number of arguments explicitly (default is 1, we support up to 4). * ```wp-block-code add_filter( 'cachify_modify_output', function( $data, $method, $hash, $cache_expires ) { return $data . ''; }, 10, // priority (default: 10) 4 // number of arguments (default: 1)); ``` * or * ```wp-block-code add_filter( 'cachify_modify_output', function( $data ) { return $data . ''; }); ``` * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Works with WordPress 6.8.1?](https://wordpress.org/support/topic/works-with-wordpress-6-8-1-2/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [11 months ago](https://wordpress.org/support/topic/works-with-wordpress-6-8-1-2/#post-18514647) * Hi [@graphicsmgr](https://wordpress.org/support/users/graphicsmgr/), * Yes, Statify should run fine on WordPress 6.8, having a couple of instances up and running for months without issues. * Plugin metadata is now also updated. Though I had done this already – obviously not, sorry for that. * Let us know, if you experience any issues. * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Track subdomains as referrer](https://wordpress.org/support/topic/track-subdomains-as-referrer/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year ago](https://wordpress.org/support/topic/track-subdomains-as-referrer/#post-18460947) * It depends on how you do the redirection. Statify evaluates the HTTP header ` Referer` for that purpose. And little bit on the browser used, but default configurations should behave very similar. * An HTTP 301 or 302 redirection typically preserves the original Referer header, so if you directly access the page from a QR code, it’s most likely empty. * You could add a minimalistic landing page with a link or button like “You will be redirected to … otherwise click here.” and add a line of JavaScript that automatically clicks on that link. (`document.getElementById('my-link').click()`). Doing so, _Statify_ should see the landing page, i.e. your subdomain as referrer and add it to the usual list. * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Wich Header Cache-Control should be set?](https://wordpress.org/support/topic/wich-header-cache-control-should-be-set/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year, 1 month ago](https://wordpress.org/support/topic/wich-header-cache-control-should-be-set/#post-18420249) * Cachify does not set any headers. If you should set any … well, short answer is “it depends”. * Cached pages are kind of static for a certain timespan. But keep in mind, you have no control over client-side caches. So if you set “Cache-Control” or “Expires” to let’s say “access plus 12 hours” in your Apache/nginx config snippet and you hit the “flush cache” button in WordPress, clients might see the old page for up to 12 hours, if accessed previously. So new content it not immediately visible or some link might point to a deleted page. * If there’s another caching proxy, CDN or similar between the site and your clients, it’s yet another decision to be made, where to cache. 1h public cache with a single proxy could theoretically result in 2h delay on the client. * On mostly static sites with long caching times this can be tolerable. On sites with faster dynamic content, that’s likely not what you want. * Caching still reduces server load, even without client-side caching. Serving static HTML is rather cheap compared to complete page rendering. A compromise can be long-time server-side (e.g. Cachify set to 24h) and short-time client- side (“Cache-Control: max-age=900, private” – 15min from access in the browser), so switching between pages within a short timeframe reduces network traffic. * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Php fatal error](https://wordpress.org/support/topic/php-fatal-error-457/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year, 2 months ago](https://wordpress.org/support/topic/php-fatal-error-457/#post-18336393) * Issue with config validation is now fixed in 2.4.1 so the example above should work if you require authentication for Redis. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Statify] Privacy / Datenschutzerklärung](https://wordpress.org/support/topic/privacy-datenschutzerklarung/) * Plugin Support [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year, 3 months ago](https://wordpress.org/support/topic/privacy-datenschutzerklarung/#post-18295884) * Hi Gerdski, * We consider Statify compliant with GDPR and BDSG (Germany) regulations. You may make it transparent and inform your users about the fact that their page visits are counted, but we do not store or process any personal information like IPs, do not use cookies or session data and do not transfer any data to external entities. So there should be no requirement to do so. * The term “track” appears in some places, but actually it’s more counting than tracking. The database does not contain any more data than you see on the dashboard. * Little more words on this topic can be found here (in English and German): [https://statify.pluginkollektiv.org/documentation/privacy/](https://statify.pluginkollektiv.org/documentation/privacy/) * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] Php fatal error](https://wordpress.org/support/topic/php-fatal-error-457/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year, 3 months ago](https://wordpress.org/support/topic/php-fatal-error-457/#post-18278549) * Actually, it _is_ supported. Documentation lacks little bit behind. * ```wp-block-code add_filter( 'cachify_redis_servers', function( $server ) { // default: $server = [ 'localhost '] return [ '127.0.0.1', // host/ip/path (required) 6379, // port 6379 by default, -1 for socket 2.0, // timeout in seconds null, // unused 0, // retry interval in milliseconds 3.0, // read timeout in seconds [ 'auth' => [ 'username', 'password' ] ] ];} ); ``` * Supporeted since PHPRedis 5.3, see [https://github.com/phpredis/phpredis/tree/5.3.7?tab=readme-ov-file#connect-open](https://github.com/phpredis/phpredis/tree/5.3.7?tab=readme-ov-file#connect-open) * **BUT:** apparently there’s a bug in v2.4.0, so the last parameter is rejected. Validation is also limited to PHPRedis 5.x syntax, not 6.x… * We will fix this in 2.4.1. (issue [#315 (GitHub)](https://github.com/pluginkollektiv/cachify/issues/315)) * … and probably also should improve error handling, so it does fail gracefully with an admin notice instead of passing the PHP error. ([#316](https://github.com/pluginkollektiv/cachify/issues/316)) * Cheers, Stefan * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Cachify] (HDD) Site Health Status – No page cache](https://wordpress.org/support/topic/hdd-site-health-status-no-page-cache/) * [Stefan Kalscheuer](https://wordpress.org/support/users/stklcode/) * (@stklcode) * [1 year, 5 months ago](https://wordpress.org/support/topic/hdd-site-health-status-no-page-cache/#post-18143922) * Hi Micha, * thanks for bringing this up. Unfortunately, the observation is correct in some scenarios. * Do you have any specific web server (seeing Apache httpd headers on the linked site, likely .htaccess) configuration applied or just enabled Cachify without further steps? * **Cache served through _Cachify_** WordPress is initialized, _Cachify _reads cached data from DB or in your case HDD and serves it to the client (most parts of the page generation is then skipped). * In this scenario no caching-related HTTP headers are sent. We should probably add these with a following update… * **Cache directly served through web server** Your web server reads cached files from HDD and serves them to the client. * In this scenario it depends on your (or your provider’s) configuration. You will likely get “last-modified” and “etag” automatically with only our minimal config snippet (.htaccess or nginx conf) in place. * Cheers, Stefan * PS: You can look for the “