Stefan Kalscheuer
Forum Replies Created
-
Forum: Plugins
In reply to: [Liveticker (by stklcode)] RSS-FeedHallo Sebastian,
die URL ist zugegeben nicht besonders intuitiv, aber setzt sich aus dem Content-Type und der Titelform (Slug) des Tickers zusammen: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ß,
StefanForum: Plugins
In reply to: [Statify] Daten fehlen, dafür Views vom 7.2.2036Hallo 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.
-- SELECT zur Plausibilitätsprüfung
SELECTcreated, DATE_SUB(created, INTERVAL 3775 DAY) AScreated_fixedFROMwp_statifyWHEREcreated>= '2036-02-07' LIMIT 10;
-- Aktualisierung der Daten
UPDATEwp_statifySETcreated= DATE_SUB(created, INTERVAL 3775 DAY) WHEREcreated>= '2036-02-07';(ein Backup kann nie schaden, Verwendung auf eigene Gefahr)
Gruß,
Stefan- This reply was modified 5 months, 4 weeks ago by Stefan Kalscheuer. Reason: Statements ergänzt
Forum: Plugins
In reply to: [AntiVirus] DIsmissShould 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
In reply to: [AntiVirus] DIsmissLooks 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
In reply to: [Cachify] cachify_modify_output not workingHi 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).
add_filter(
'cachify_modify_output',
function( $data, $method, $hash, $cache_expires ) {
return $data . '<!-- additional comment line -->';
},
10, // priority (default: 10)
4 // number of arguments (default: 1)
);or
add_filter(
'cachify_modify_output',
function( $data ) {
return $data . '<!-- additional comment line -->';
}
);Cheers,
StefanForum: Plugins
In reply to: [Statify] Works with WordPress 6.8.1?Hi @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,
StefanForum: Plugins
In reply to: [Statify] Track subdomains as referrerIt depends on how you do the redirection. Statify evaluates the HTTP header
Refererfor 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,
StefanForum: Plugins
In reply to: [Cachify] Wich Header Cache-Control should be set?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,
StefanForum: Plugins
In reply to: [Cachify] Php fatal errorIssue with config validation is now fixed in 2.4.1 so the example above should work if you require authentication for Redis.
Forum: Plugins
In reply to: [Statify] Privacy / DatenschutzerklärungHi 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/Cheers,
StefanForum: Plugins
In reply to: [Cachify] Php fatal errorActually, it is supported. Documentation lacks little bit behind.
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
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))
… and probably also should improve error handling, so it does fail gracefully with an admin notice instead of passing the PHP error. (#316)
Cheers,
StefanForum: Plugins
In reply to: [Cachify] (HDD) Site Health Status – No page cacheHi 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,
StefanPS: You can look for the “<!– Cachify …” comment at the end of the HTML output (on second anonymous access where you expect a cached result). If this is present and response time is fast enough, Cachify does it’s job and the health check is just a bonus.
- This reply was modified 1 year, 5 months ago by Stefan Kalscheuer.
Forum: Plugins
In reply to: [Statify] Works with WordPress 6.6.2Just pushed a small maintenance update, essentially some internal details, but finally an updated “Tested up to”.
Please let us know if you experience any issues.
Forum: Plugins
In reply to: [Statify] Works with WordPress 6.6.2Yes, should work fine.
Just noticed that the update setting “Tested up to: 6.6” had an issue during deployment. Sorry for that.
Forum: Plugins
In reply to: [Cachify] Wordfence: Cachify Abandoned PluginCachify 2.4.0 was release today after a few weeks of additional testing and last minute corrections. If you experience any issues with the update please let us know.
