{"id":21044,"date":"2026-10-02T23:18:42","date_gmt":"2026-10-02T21:18:42","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=21044"},"modified":"2026-10-02T23:19:05","modified_gmt":"2026-10-02T21:19:05","slug":"stats4u-wordpress-plugin-funktionsweise","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/stats4u-wordpress-plugin-funktionsweise\/","title":{"rendered":"So funktioniert das WordPress-Plugin Stats4U: Z\u00e4hlercode, Platzierung, Einwilligung und Anfragen"},"content":{"rendered":"

Stats4U ist ein Besucherz\u00e4hler von LW IT Solutions: ein kleines Bild auf der Website, das Seitenaufrufe z\u00e4hlt, dazu eine Statistik auf stats4u.net<\/a> mit Herkunft der Besucher, Verweildauer, Scrolltiefe und den Besuchern, die gerade online sind. Ein Konto braucht es nicht, die Z\u00e4hlernummer gen\u00fcgt. F\u00fcr WordPress gibt es dazu ein eigenes Plugin. Es steht seit dem 29.09.2026 im Plugin-Verzeichnis von WordPress.org<\/a>, in Version 1.6.0, und sein Quelltext liegt \u00f6ffentlich auf GitHub<\/a>.<\/p>\n

Dieser Beitrag zeigt, wie das Plugin arbeitet: wie es einen eingef\u00fcgten Z\u00e4hlercode liest, wie es den Z\u00e4hler hinter den Seitenfu\u00df eines beliebigen Themes setzt, wie es auf ein Einwilligungswerkzeug wartet und was der Browser danach an stats4u.net schickt. Alles ist auf einer lokalen Testinstallation mit WordPress 7.1.2, PHP 8.4 und Twenty Twenty-Five am 02.10.2026 nachgemessen, mit dem Plugin aus dem Verzeichnis. Am Ende stehen der Weg durch das Review von WordPress.org und alle Links.<\/p>\n

Vom eingef\u00fcgten Code zum Z\u00e4hler<\/h2>\n

Unter \u201eEinstellungen \u2192 Stats4U\u201c f\u00fchrt ein Assistent in f\u00fcnf Schritten durch die Einrichtung: Z\u00e4hler, Aussehen, Platzierung, Einwilligung, fertig. Wer alles auf einer Seite haben will, w\u00e4hlt stattdessen die eigene Konfiguration. Im ersten Schritt kommt der Code hinein, den der Generator auf stats4u.net ausgibt. Daf\u00fcr gibt es drei Wege: ein vorhandener Code, ein Knopf, der den Generator \u00f6ffnet und den Code am Ende zur\u00fcckbringt, oder eine neue Z\u00e4hlernummer auf Anfrage. Die beiden letzten Wege laufen aus dem Browser der Administratorin oder des Administrators, nicht vom Server.<\/p>\n

Der Generator kennt mehrere Formate, und das Plugin nimmt sie alle an. Die Tabelle zeigt, was stats4u_code_lesen()<\/code> aus zw\u00f6lf Eingaben gemacht hat:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Eingef\u00fcgt<\/th>\nErgebnis<\/th>\n<\/tr>\n<\/thead>\n
HTML, Bild mit Link<\/td>\nNummer, Entwurf, dunkler Modus und Gr\u00f6\u00dfe 150 %<\/td>\n<\/tr>\n
BBCode<\/td>\nNummer, Entwurf, dunkler Modus<\/td>\n<\/tr>\n
Markdown<\/td>\nNummer, Entwurf, Sprache Deutsch<\/td>\n<\/tr>\n
Skript-Code mit s4u.js<\/code><\/td>\nNummer, Entwurf, dunkler Modus, Z\u00e4hlweise \u201eeinmalige Besucher\u201c, Sprache Polnisch<\/td>\n<\/tr>\n
Bildadresse allein<\/td>\nNummer und Entwurf<\/td>\n<\/tr>\n
alte Langform ?action=pic&s4uid=\u2026<\/code><\/td>\nNummer und Entwurf<\/td>\n<\/tr>\n
nur die Nummer, auch mit #<\/code><\/td>\nNummer, Entwurf bleibt<\/td>\n<\/tr>\n
Adresse der Statistikseite \/live\/<Nummer><\/code><\/td>\nNummer<\/td>\n<\/tr>\n
Statistikseite mit eigenem Namen<\/td>\nHinweis: Code oder Nummer einf\u00fcgen<\/td>\n<\/tr>\n
Globus-Widget globe.js<\/code><\/td>\nHinweis: das Plugin zeigt Bildz\u00e4hler<\/td>\n<\/tr>\n
beliebiger Text<\/td>\nHinweis: Code nicht erkannt<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Auf der Seite steht danach nicht mehr das Bild allein, sondern das offizielle Skript des Dienstes, dasselbe <script src=\"https:\/\/www.stats4u.net\/s4u.js\" data-id=\"\u2026\" async><\/code>, das der Generator ausgibt. Bis Version 1.4.0 setzte das Plugin nur das Bild. Das war leichter, aber ein Browser schickt mit einem Bild von einem fremden Server nur die Domain der Website mit, nicht die Seite und nicht die Herkunft des Besuchers. Erst das Skript liefert diese Angaben und dazu Verweildauer, Scrolltiefe und \u201ejetzt online\u201c. Welche Form am Platz des Z\u00e4hlers steht, entscheidet eine einzige Funktion:<\/p>\n

\/\/ stats4u.php (excerpt)\nfunction stats4u_zaehler_teile($e) {\n    $daten = stats4u_skript_daten($e);\n    if (stats4u_cmp($e) === null) {\n        return array('skript' => array('src' => STATS4U_SKRIPT, 'async' => true) + $daten);\n    }\n    stats4u_wartet(true);\n    return array('platzhalter' => $daten);\n}\n\nfunction stats4u_html() {\n    $e = stats4u_einstellungen();\n    if ($e['id'] === '') { return ''; }\n    $t = stats4u_zaehler_teile($e);\n    if (isset($t['skript'])) {\n        return '<span class=\"stats4u-zaehler\">' . trim(wp_get_script_tag($t['skript'])) . '<\/span>';\n    }\n    return '<span class=\"stats4u-zaehler\" data-stats4u=\"' . esc_attr(wp_json_encode($t['platzhalter'])) . '\"><\/span>';\n}<\/code><\/pre>\n
Ohne Einwilligungswerkzeug ist das ein Skript-Tag, gebaut mit wp_get_script_tag()<\/code>, das jedes Attribut maskiert. Mit einem Werkzeug ist es ein leerer Platzhalter, der die Angaben des Z\u00e4hlers als JSON tr\u00e4gt. Dazu sp\u00e4ter mehr.<\/p>\n
Hinter dem Seitenfu\u00df jedes Themes<\/h2>\n
Ab Werk erscheint der Z\u00e4hler direkt unter dem Seitenfu\u00df des Themes. Das klingt einfach, aber WordPress kennt keine Stelle \u201enach dem Fu\u00df\u201c. Der \u00fcbliche Haken wp_footer<\/code> liegt kurz vor <\/body><\/code>. Bis Version 1.3.0 hing der Z\u00e4hler dort, und auf einer Seite, deren body<\/code> als Flexbox angelegt ist, stand er dann als Spalte neben dem Inhalt, auf halber H\u00f6he. Seit 1.3.1 puffert das Plugin die Ausgabe ab dem Ende von wp_head<\/code>, sucht im Puffer den Seitenfu\u00df und setzt den Z\u00e4hler dahinter. Als Seitenfu\u00df gilt ein Element, das sich als solcher ausweist:<\/p>\n
\/\/ stats4u.php (excerpt)\nfunction stats4u_ist_seitenfuss($name, $tag) {\n    if (preg_match('\/(?<![\\w-])role\\s*=\\s*[\"\\']?contentinfo\\b\/i', $tag)) { return true; }\n    if (preg_match('\/(?<![\\w-])itemtype\\s*=\\s*[\"\\']?[^\"\\'>]*WPFooter\/i', $tag)) { return true; }\n    $namen = array('colophon', 'footer', 'site-footer', 'main-footer', 'page-footer', 'global-footer',\n                   'elementor-location-footer');\n    if ($name === 'footer') { $namen[] = 'wp-block-template-part'; }\n    foreach (array('id', 'class') as $attr) {\n        if (preg_match('\/(?<![\\w-])' . $attr . '\\s*=\\s*(?:\"([^\"]*)\"|\\'([^\\']*)\\'|([^\\s>]+))\/i', $tag, $m)) {\n            $wert = strtolower(($m[1] ?? '') . ($m[2] ?? '') . ($m[3] ?? ''));\n            if (array_intersect(preg_split('\/\\s+\/', trim($wert)), $namen)) { return true; }\n        }\n    }\n    return false;\n}<\/code><\/pre>\n
Unter mehreren Kandidaten gewinnt der letzte \u00e4u\u00dferste, damit der Z\u00e4hler bei Themes, die ein <footer><\/code> in einen weiteren Fu\u00dfbereich stecken, unter dem ganzen Balken steht. Fehlt ein erkennbarer Fu\u00df, kommt der Z\u00e4hler ans Ende der Seite. Bis das Skript das Bild gezeichnet hat, blendet eine CSS-Regel mit :has()<\/code> den leeren Kasten aus, damit kein Rand als L\u00fccke stehen bleibt. Seit Version 1.6.0 \u00fcbernimmt diese Arbeit der R\u00fcckruf des Ausgabepuffers; das Plugin gibt die gepufferte Seite nicht mehr selbst aus. Diese \u00c4nderung kam aus dem Review von WordPress.org.<\/p>\n
Auf der Testinstallation landete der Z\u00e4hler bei jeder Einstellung an der beschriebenen Stelle. \u201eUnter dem Fu\u00df\u201c setzte ihn direkt hinter <\/footer><\/code>, \u201eim Fu\u00df\u201c davor, \u201eam Ende der Seite\u201c vor die Skripte am Schluss. \u201eUnter dem Inhalt\u201c setzte ihn nur auf Einzelseiten, nicht auf der Startseite. Die Ecken setzten ihn fest unten rechts oder links, und \u201enirgends automatisch\u201c lie\u00df ihn weg. F\u00fcr eigene Pl\u00e4tze gibt es den Block \u201eStats4U counter\u201c und den Shortcode <\/span><\/code>, in einer Vorlage als do_shortcode( '<\/span>' )<\/code>. Block und Shortcode auf derselben Seite ergaben zwei Z\u00e4hler, der Block mit seiner eigenen Ausrichtung.<\/p>\n
Erst nach der Einwilligung<\/h2>\n
Wer ein Einwilligungswerkzeug nutzt, w\u00e4hlt es im vierten Schritt aus. Zur Wahl stehen 27 Eintr\u00e4ge: 25 Werkzeuge, CookieYes zus\u00e4tzlich im alten Modus und die WP Consent API, dazu jedes Werkzeug, das Skripte \u00fcber eigene Attribute sperrt. Am Platz des Z\u00e4hlers steht dann ein leerer span<\/code> mit den Angaben in data-stats4u<\/code>. Am Ende der Seite steht ein kleines Freigabeskript, das das Werkzeug erst nach der Einwilligung ausf\u00fchrt und das dann in jeden Platzhalter das offizielle s4u.js<\/code> setzt. Gemessen sah das so aus:<\/p>\n\n\n\n\n\n\n\n\n\n
Werkzeug<\/th>\nFreigabeskript im HTML<\/th>\n<\/tr>\n<\/thead>\n
Complianz<\/td>\n<script type=\"text\/plain\" data-category=\"statistics\"><\/code><\/td>\n<\/tr>\n
Cookiebot<\/td>\n<script type=\"text\/plain\" data-cookieconsent=\"statistics\"><\/code><\/td>\n<\/tr>\n
consented.eu<\/td>\n<script type=\"text\/plain\" data-consented=\"stats4u\"><\/code><\/td>\n<\/tr>\n
CookieYes<\/td>\n<script data-cookieyes=\"cookieyes-analytics\" src=\"\u2026\/freigabe.js\"><\/code><\/td>\n<\/tr>\n
WP Consent API<\/td>\nInline-Skript, das wp_has_consent()<\/code> fragt und auf \u00c4nderungen h\u00f6rt<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In keinem dieser F\u00e4lle stand s4u.js<\/code> direkt im HTML. F\u00fcr Werkzeuge, die nur Skripte mit eigener Adresse freigeben, wie CookieYes, bindet das Plugin die Datei freigabe.js<\/code> ein. Bei der WP Consent API pr\u00fcft das Skript zuerst, ob \u00fcberhaupt ein Einwilligungstyp gesetzt ist, weil wp_has_consent()<\/code> ohne Typ auch nach einer Ablehnung true<\/code> liefert. F\u00fcr ein Werkzeug, das nicht in der Liste steht, lassen sich eigene Attribute eintragen. Dabei kommen nur type<\/code>, class<\/code> und data-*<\/code> durch:<\/p>\n
\/\/ stats4u.php (excerpt)\nfunction stats4u_eigene_attribute($roh) {\n    $aus = array('type' => 'text\/plain');\n    if (preg_match_all('\/([a-zA-Z][a-zA-Z0-9_.:-]*)\\s*=\\s*(?:\"([^\"]*)\"|\\'([^\\']*)\\'|([^\\s\"\\'>]+))\/', (string) $roh, $m, PREG_SET_ORDER)) {\n        foreach ($m as $a) {\n            $name = strtolower($a[1]);\n            if (!preg_match('\/^(data-[a-z0-9_.:-]+|class|type)$\/', $name)) { continue; }\n            $wert = $a[2] !== '' ? $a[2] : ((isset($a[3]) && $a[3] !== '') ? $a[3] : ($a[4] ?? ''));\n            $aus[$name] = substr(preg_replace('\/[^A-Za-z0-9 _.:\\\/,#-]\/', '', $wert), 0, 80);\n        }\n    }\n    return $aus;\n}<\/code><\/pre>\n
Ein eingetragenes onload=\"alert(1)\"<\/code> fehlte in der Ausgabe; \u00fcbrig blieben type=\"text\/plain\"<\/code> und data-category=\"statistics\"<\/code>.<\/p>\n
\n\"Vom
Das Plugin Stats4U setzt das offizielle Z\u00e4hlerskript an die gew\u00e4hlte Stelle; gez\u00e4hlt wird im Browser, der WordPress-Server ruft stats4u.net nie auf<\/figcaption><\/figure>\n
Was der Browser an stats4u.net schickt<\/h2>\n
F\u00fcr diese Messung lief ein Chrome mit frischem Profil, in dem jede Anfrage angehalten wurde. Nur die Skriptdatei s4u.js<\/code> selbst durfte geladen werden. Jede andere Anfrage an stats4u.net wurde mitgeschrieben und dann abgebrochen, damit keine Testz\u00e4hlung beim Dienst ankam. Die Seite blieb 70 Sekunden offen, danach wurde wegnavigiert.<\/p>\n\n\n\n\n\n\n\n\n\n
Zeitpunkt<\/th>\nAnfrage<\/th>\nInhalt<\/th>\n<\/tr>\n<\/thead>\n
beim Laden<\/td>\ns4u.js<\/code><\/td>\n13.237 Bytes \u00fcbertragen, mit Brotli, eine Stunde im Cache, kein Set-Cookie<\/code><\/td>\n<\/tr>\n
beim Laden<\/td>\naction=cfg<\/code>, GET<\/td>\nnur die Z\u00e4hlernummer: Einstellungen des Z\u00e4hlers<\/td>\n<\/tr>\n
beim Laden<\/td>\naction=pic<\/code>, Bild<\/td>\nZ\u00e4hlernummer, Entwurf, dunkler Modus, Sprache, Seitenadresse, Herkunft und eine Zufallszahl gegen Caches; diese Anfrage z\u00e4hlt<\/td>\n<\/tr>\n
nach 60 s<\/td>\naction=ping<\/code>, POST<\/td>\nnur die Z\u00e4hlernummer, f\u00fcr \u201ejetzt online\u201c<\/td>\n<\/tr>\n
beim Verlassen<\/td>\naction=puls<\/code>, Beacon<\/td>\nZ\u00e4hlernummer, Seitenadresse, sichtbare Sekunden, Scrolltiefe und Ladezeit<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Nach dem Laden standen im Browser keine Cookies und nichts im lokalen Speicher. Das Skript machte den Z\u00e4hler zu einem Link auf seine Statistikseite, https:\/\/www.stats4u.net\/live\/<Nummer><\/code>. Diesen Link setzt der Dienst, nicht das Plugin; ein Z\u00e4hler, der auf stats4u.net als nicht \u00f6ffentlich eingestellt ist, verweist auf die Startseite des Dienstes. Der WordPress-Server selbst ruft stats4u.net nie auf: Im Code des Plugins steht kein einziger HTTP-Aufruf. Die Vorschau auf der Einstellungsseite und im Editor tr\u00e4gt den Parameter rl=1<\/code> und z\u00e4hlt nicht.<\/p>\n
Mehrsprachig und ohne Neuaufbau<\/h2>\n
Steht die Sprache des Z\u00e4hlers auf \u201ewie die Seite\u201c, setzt das Plugin sie je Aufruf aus dem Gebietsschema. Mit Polylang trug der Z\u00e4hler auf der englischen Startseite data-lang=\"en\"<\/code>, auf der deutschen de<\/code> und auf der polnischen pl<\/code>. Themes, die Seiten ohne Neuaufbau wechseln, z\u00e4hlen ohne Hilfe nur die erste Seite. F\u00fcr sie gibt es das Ereignis s4u:seiteweg<\/code>, das die Verweildauer der alten Seite abschlie\u00dft, und nach einer Einwilligung die Funktion window.stats4uAn()<\/code>, die neue Platzhalter f\u00fcllt. Diese Website nutzt genau diesen Weg. Auf ihr l\u00e4uft Stats4U 1.6.0 mit consented.eu, und ihr Seitenwechsel ohne Neuaufbau l\u00f6st vor jedem Tausch s4u:seiteweg<\/code> aus.<\/p>\n
Durch das Review von WordPress.org<\/h2>\n
Die erste Einreichung wurde am 26.09.2026 zur\u00fcckgestellt. Das Review-Team verlangte, jeden Wert erst bei der Ausgabe zu maskieren, auch bei HTML, das eine Funktion zur\u00fcckgibt, und keine \u00dcbersetzungsdateien im Paket mitzuliefern. Version 1.6.0 setzt das um. Jede Ausgabe l\u00e4uft \u00fcber esc_html()<\/code>, esc_attr()<\/code>, esc_url()<\/code>, wp_kses()<\/code> oder wp_print_script_tag()<\/code>, und den Z\u00e4hler hinter den Seitenfu\u00df setzt der R\u00fcckruf des Ausgabepuffers. Die 18 \u00dcbersetzungen, die bis 1.5.0 im Paket lagen, liegen jetzt als Vorlage im GitHub-Repository; \u00fcbersetzt wird auf translate.wordpress.org<\/a>, und WordPress l\u00e4dt die Sprachpakete von selbst. Am 29.09.2026 gab das Review-Team Stats4U frei.<\/p>\n
Beim L\u00f6schen entfernt das Plugin seine Option und die gemerkte Ansicht der Einstellungsseite. Gemessen: Option mit 236 Bytes und Ansicht vorher vorhanden, danach beide weg. Der Z\u00e4hler auf stats4u.net und seine Statistik bleiben bestehen.<\/p>\n
Alle Links<\/h2>\n