Stefan Kalscheuer

We released Statify 2.0.2 a frew minutes ago. Issue should be fixed once the plugin gets updated.
Let us know if the issue persists.

OK, good catch. Dynamically generated content should be translated, but unfortunately the translations module was never acutally registered for the dashbaord script.

Thanks for reporting. Will be fixed with the next release.

Cross reference: https://github.com/pluginkollektiv/statify/pull/353

This issue should be fixed with update 2.0.1, released yesterday and confirmed in two other support threads.
But it was not part of this thread and is likely unrelated to potentially missing numbers, so let’s try not to mix up too many things here.

Vielen Dank, das freut uns zu lesen.

Die Funktionalität sollte weitgehend gleich sein, auch wenn sie auf technisch geänderter Basis daherkommt.

Extended Evaluation speichert im aktuellen Stand keine eigenen Daten speichert, diese lagen schon immer bei Statify selbst. Entsprechend geht bei der Deinstallation hier auch nichts verloren.
Kann man hier entsprechend flexibel entfernen oder, falls man es doch vermisst oder nochmal vergleichen mag, wieder installieren.

50% is really a lot to attribute to “just” a new bot detection system. Especially since it’s happening on four different websites.

I agree that a typical website should not have 50% non-user traffic that does not match any of the previously filtered keywords … but you never know for sure until you cross-check with server access logs.

The 1.8.5 filter was rather simple with some keywords to match:
bot, slurp, crawler, spider, curl, facebook, fetch, python, wget, monitor

I do have sites where my WAF filters out >2M bot/crawler requests per hour and I’ve seen others where some monitoring systems query the front page every 5 minutes that identify as Firefox or whatever…

I’m also going to try excluding the Statify script from caching so that it’s no longer bundled.

Should not a big issue in general. Most bundlers I’ve seen know are aware of cache-breakers or sentitive to plugin updates. And the tracking script rarely changes, so minor updates are fine even if cached.

Can you explain that part about the REST API to me? What does it have to do with Statify, and how can you tell if it’s blocked?

Statify 1.x JavaScript tracking sent a POST request to /wp-admin/admin-ajax.php
Statify 2.0 now uses an individual API endpoint at /wp-json/statify/v1/track

You should see such POST request with HTTP status 204 (No Content) in the browser console and the server’s access logs.

If there’s nothing, it’s likely an issue with the JavaScript inclusion.

If the API is blocked for whatever reasons (there are some guides out on the web that suggest disabling if with some custom plugin code for security or whatever reasons) it should fail, i.e. show HTTP error 401, 403 or similar. or maybe some CSRF failures in the browser console.

Update: I always assumed we are talking about JS based tracking here. If it’s the non-JS version (that doesn’t play well with caching), there’s a different issue obviously.

• This reply was modified 1 week ago by Stefan Kalscheuer.

Hi @jotbee,

Thanks for reporting and sorry for the issue.

Looks like we missed that one. Thought we tested it properly, but apparently German (Germany) returns just “de” and English US returns just “en”, so the full notation fell through… We will fix that ASAP and should make it robust, s.t. a user might see a non-localized version instead of nothing.

Cheers,
Stefan

Cross reference: https://github.com/pluginkollektiv/statify/issues/345

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.

-- SELECT zur Plausibilitätsprüfung
SELECT created, DATE_SUB(created, INTERVAL 3775 DAY) AS created_fixed FROM wp_statify WHERE created >= '2036-02-07' LIMIT 10;

-- Aktualisierung der Daten
UPDATE 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 9 months, 2 weeks ago by Stefan Kalscheuer. Reason: Statements ergänzt