Stefan Kalscheuer

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.

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)

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. (welches automatisch aus Comment Blocklist for WordPress (GitHub) 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 (das auch noch IP oder aufgerufene Seiten filtern kann – muss aber auch individuell konfiguriert werden)

“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/) nahezu beliebige Aufrufe von der Zählung ausschließen.

Oder etwas komfortabler mit dem “Statify Filter” Plugin (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.

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/)

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.