Stefan Kalscheuer

Hallo Dirk,

offenbar hast du den Admin-Bereich durch eine Basic Authentication doppelt abgesichert. Hierunter f?llt auch der WP AJAX Endpunkt /wp-admin/admin-ajax.php, den Statify seit 1.7 zum Tracking nutzt. Statify scheint dein einziges Plugin zu sein, das diesen Endpunkt im Frontend nutzt, sonst w?re es sicher bereits aufgefallen.

Sieht man gut in Netzwerkübersicht der Entwicklerwerkzeuge im Browser. Wenn man die Anmeldung abbricht, liefert der Statify Aufruf Status 401.

Um Statify zu nutzen, solltest diesen Endpunkt von der Authentifizierung ausnehmen.

Gru?,
Stefan

Hallo Inga,

Bei den Fehlern sehr ich zwei js-fehler (preload und jquery) sowie 2 Fehler, die im Quellcode meiner Seite zu finden sind.
[…]
ich nehme an, dass das aktuelle Statify-Problem auf die beiden js-Script-Fehler zurückzuführen ist. Richtig?

Indirekt wahrscheinlich Ja. Wenn der Browser beim JS einmal in Fehler l?uft und das nicht im Skript selbst abgefangen wird, l?uft in der Kette danach auch nichts mehr weiter.

Was geladen wird, h?ngt natürlich von deinem Browsercache, den lokal im System installierten Schriftarten, etc. ab. Mein Testbrowser ist “jungfr?ulich”, also zu erwarten, dass ich mehr Ladefehler bekommen hatte.

Was bedeutet “CORS Sicherheitseinstellungen” und wo finde ich die?

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Im Prinzip setzt der Webserver oder die Anwendung HTTP-Header, die vorgeben, welche Ressourcen auf welche Weise von wo geladen werden dürfen. Ob das der Webserver macht, ein WordPress Plugin l?sst sich von au?en nicht sagen.

Das Problem betraf die Schriftarten, da sie von einer anderen (Sub)Domain kamen – scheint ja inzwischen gel?st.

—-

Die jetzt noch relevante Meldung ist

Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘self'”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-Oo1bdSPsp6CjaJ69F4foXm6agCkwFfBGUBZTPn9iRfM=’), or a nonce (‘nonce-…’) is required to enable inline execution.

“Verursacht” durch eine “Content Security Policy” default-src 'self'.
(https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

Erfreulich, solche Einstellungen in freier Wildbahn zu finden, wird oft genug ignoriert.
Allerdings hat CSP auch viele Fallstricke, da Systeme wie WordPress eben doch an diversen Stellen Inline-JS, also Skript-Bl?cke im HTML einsetzen, ohne passende Behandlung.

Einfache Abhilfe k?nnte eine Erweiterung wie script-src 'unsafe-inline' https://ingalandwehr.de schaffen oder auch beliebig komplexere Konfiguration.

Wo die Daten gesetzt werden, kann man von au?en natürlich nur vermuten. Ich hoffe die Ansatzpunkte helfen weiter.

Gru?,
Stefan

Hallo Raimund,

Ich nehme an, damit ist der prüfende Blick in den Seitenquelltext gemeint […]
Dort finde ich (in unserer Startseite) aber lediglich den Schnipsel (var statify_ajax = …) und zwar am Seitenende.
Das von Dir erw?hnte Script (…ver=1.7.0) ist jedoch nicht enthalten.
Was bedeutet das nun für uns? Handlungsbedarf?

Ja, meinte ich. Das ist in deinem Fall so in Ordnung, da Autoptimize das Skript schluckt und in die autoptimize_<…>.js am Ende der Seite integriert. Hier findest du den Statify-Abschnitt wieder (in deinem Fall ganz unten).

Gru?,
Stefan

Hallo Inga,

macht ja nichts.

HTML Code sieht man über REchtsklick -> Quellcode anzeigen (oder meist Strg+U bzw. Option+Cmd+U). In den “Entwickler-Tools” des Browsers (die man natürlich auch als Nicht-Entwickler benutzen darf), erreichbar meist über F12, gibt es i.d.R. einen Reiter “Netzwerk”, der die einzelnen Anfragen auflistet.

Sieht z.B. so aus (andere Browser vergleichbar): https://developers.google.com/web/tools/chrome-devtools/network#load

Deine Seite sieht nach flüchtiger Beurteilung prinzipiell gut aus (auch technisch ?? ), d.h. das aktuelle Statify ist im Autoptimize Block enthalten und die Variable ist auch vorhanden. Soweit so gut.

Allerdings sehe ich in der Browserkonsole Fehlermeldungen, dass durch Sicherheitseinschr?nkungen Skriptausführung blockiert wird. Die betroffene Zeile ist ein “shariff”-Block, da hier aber abgebrochen wird, ist auch die “var statify_ajax = …” Zeile betroffen. Entsprechend wird das Skript sp?ter zwar aufgerufen, aber kann ohne Konfiguration nicht arbeiten.

Ich würde dir empfehlen, die Einstellungen der Seite einmal zu prüfen oder prüfen zu lassen. Das Problem betrifft tendenziell nicht nur Statify (die Methodik, wie WordPress die AJAX-Blocks initialisiert ist ja für alle gleich). Auch wird durch eine CORS Sicherheitseinstellung verhindert, dass diverse Schriftarten von der Subdomain “tgc.ingalandwehr.de”, was sicherlich auch nicht in deinem Sinn ist.

Gru?,
Stefan

Hallo Raimund,
Hallo Inga

in 1.7 wurde das JavaScript-Tracking grundlegend umgestellt (von einer selbst gestalteten Methodik auf das deutlich leichtgewichtigere WP AJAX). Da zumindest Raimunds Seite ein Caching-Plugin nutzt, müsste der Cache nach der Aktualisierung des Plugins einmal geleert werden, damit der neue Skript-Teil in das HTML Markup kommt. Das ist w?re die wahrscheinlichste Erkl?rung.

Cachify würde vom Plugin bei (de)aktivierung selbstst?ndig geleert, aber es gibt ja noch viele andere, die nicht abgedeckt werden (WP Super Cache, W3 Total Cache, Cache Enabler, …), die nach dem Update einmal manuell geleert werden sollten. Das zu tun ist aber grunds?tzlich bei vielen Plugin-Updates mit Auswirkungen am Frontend sinnvoll.

Wenn ich die Seite jetzt aufsuche, sehe ich im Browser-Log einen gültigen Statify Request mit Code 204 (Request auf “admin-ajax.php”).
Sch?tzungsweise ist in der Zwischenzeit der Cache der Startseite abgelaufen oder wurde geleert.

Im HTML Markup muss das Statify Skript der aktuellen Version (“/wp-content/plugins/statify/js/snippet.min.js?ver=1.7.0”) eingebunden sein (sofern nicht durch Autoptimize o.?. zusammgnestrichen) und ein kleiner Schnipsel mit dem Inhalt “var statify_ajax = …”.

Gru?,
Stefan

Wenn es schon um Gesamtzahlen geht, warum sollen denn nur Zahlen aus dem im Widget eingestellten Zeitraum angezeigt werden. Ich finde, es k?nnte das Datum von dem Tag der Erstaufbewahrung verwendet werden.

Genau so habe ich es in meiner Korrektur gemacht. Wenn die ?nderung durchkommt, wird dann der gesamte Zeitraum der Datenbank korrekt ausgegeben.

So war die Funktion ursprünglich auch gedacht, dann kam die Trennung Anzeige/Speicherung parallel dazu und am Ende hat keiner mehr so genau hingesehen, ob das wirklich zusammen passt…

Gru?,
Stefan

I’d never dare to call you stupid because of that. I’m sorry if I came across like that. Thee are lots of aspects to completely understand how the exact numbers are made up.

You are absolutely right, tracking the favicon accesses was incorrect. That’s why we excluded it from now on.
If a user visits a real, countable target and loads the icon, both hits have been counted.
So the only safe statement in this case is, your total number of hits is too high by 124.

One might think, the icon should be #1 in the list and the number should be at least as high as the sum of all other targets (even (uncounted) error pages have a favicon).
But in fact not every page visit reloads the favicon from the server, it’s cached on the client. So 124 hits on the icon could be triggered by 124 (new) visitors, but it could easily be 200, 500 or more (recurring) visitors. Hard to guess the real correlation.

Anyway the false hits will disappear after 14 days (or whatever number you configured).

Es sollte das Datum des ?ltesten angezeigten Eintrages sein, also identisch mit dem Tooltip des ersten Punkts im Diagramm – bei Default-Einstellung 14 Tage zurück.

Bei mir stimmt es auf allen Installationen überein. Wenn es bei dir weder das ?lteste Datum der Anzeige noch das ?lteste Datum der Datenbank ist, w?ren ein paar weitere Details hilfreich, um das Problem nachzustellen (welches Datum, eingestellte Zeitr?ume, Zeitzone, etc.)

Gru?,
Stefan

Nachtrag: Ich habe gerade nochmal genauer hingesehen und auf einem kleinen Anzeigezeitraum per Hand nachgerechnet… Meine Aussage zum Datum ist korrekt, aber die Gesamtzahl entspricht allen Aufrufen, nicht nur den angezeigten. Die Daten passen also nicht zueinander.
Kommt auf die Liste für 1.7.1

• This reply was modified 4 years, 10 months ago by Stefan Kalscheuer.

Hallo André,

tats?chlich wird hier die Gesamtzahl des angezeigten Zeitraums ausgegeben, der ja nicht mehr gleich Speicher-Zeitraum sein muss.

Hier haben sich ein paar Neuerungen gegenseitig überholt, daher passt die Bezeichnung nicht perfekt. Ich pers?nlich würde hier eher noch 1-2 Werte mehr ausgeben: Heute, Gesamt in Anzeige, Gesamt in Datenbank (falls abweichend).
Ggf. noch Gesamtzahl seit Beginn, auch wenn keine Details für den Zeitraum mehr bekannt sind.

Gru?,
Stefan

Hi @dieter93 and @jamesosborne,

Statify 1.7 has been released today which includes the named changes.

It worked on my test instances (otherwise we probably would not have released the feature) with the AMP plugin active and no additional changes.
Javascript Tracking should be enabled (settings descrition is extended by “… or AMP”), otherwise only the first hit before any caching will be counted.

Hopefully it also works for you. Would love to see you feedback on this.

Cheers,
Stefan

My question is still, who is asking for the favicon?

About everybody. The webbrowser tries to find an icon to display in the title bar. If nothing is specified, the default is “favicon.ico” and most browsers try this, even if not specified explicitly.

WordPress integrated a redirection to the default “W” icon, if there is none. Otherwise you would see lots of 404 errors in the server logs, because there is no icon.

Cheers,
Stefan

PS: Statify 1.7 has finally been released today! This solves the “favicon.ico” problem even without JS tracking.

This has already been addressed by myself (https://github.com/pluginkollektiv/cachify/pull/189)
Wondering why is hasn’t been published yet… Will trigger the team on that.

Based on the title I assume you might have already found the changelog somewhere else. If not, the full changelog can always be found on GitHub: https://github.com/pluginkollektiv/cachify/blob/master/CHANGELOG.md

Cheers,
Stefan

Good catch, Thorsten.

We should probably add an exclusion for this in the upcoming Statify release.

Edit: To be fixed with 1.7 (https://github.com/pluginkollektiv/statify/pull/144)

The client is redirected to the real favicon (HTTP 302) by WordPress. Apparently plugins are already loaded at this point, s.t. Statify has tracked the visit.

200ms TTFB for the favicon redirect – I got sites that are served within 20ms (uncached) total.. You want to fix this at the other side, e.g. by copying the “favicon.ico” file to the root directory or defining a custom icon path in the theme.

Cheers,
Stefan

• This reply was modified 4 years, 10 months ago by Stefan Kalscheuer.
• This reply was modified 4 years, 10 months ago by Stefan Kalscheuer.

Hi,

the favicon URL appears in the top list because it is really accessed that many times and dynamically served through WordPress, not provided as a real static file. About every client will access this icon, so you likely have twice as much hits in total.

I guess you are not using any kind of caching backend and Statify in default configuration, i.e. JavaScript Tracking disabled.
In addition you are most likely using a theme or plugin that servers the favicon dynamically, because Statify would never notice access to static files.

Please provide some additional information on your setup, s.t. we can reproduce the scenario and investigate on a fix for Statify, if possible.

Besides such scenario being close to worst case in terms of performance (but that’s not the point here), the most simple solution for your case would be turning on the ?JavaScript Tracking“ option. Doing so, the client browser triggers the tracking action through JS included in your posts/pages, but definitely never in favicon or similar cases.

Cheers,
Stefan

• This reply was modified 4 years, 10 months ago by Stefan Kalscheuer.

There are several possibilities to track downloaded files.

Serve through PHP
* breaks with caching
* probably way out of scope for Statify

Intercept through PHP with redirect to real file
* can get tricky with caching, but possible
* does not accurately track number of downloads, only number of redirections to the actual link
* also way out of scope for Statify

Intercept with JavaScript
* only works with JS tracking
* can get tricky on which links the interception should be appended and which not
* does not actually track downloads, but clicks on the link

All assuming you use default WP file management. There are several Download manager or monitoring Plugins available for WordPress which provide such features. I don’t think such feature is really suitable for Statify

Regards,
Stefan