Post Views Counter mit WP-Optimize: korrekt zählen und Complianz einbinden

Warum HTTP 200 noch nicht bedeutet, dass der richtige Beitrag gezählt wird

Das Problem sah zuerst nach einem klassischen „Cache-Thema“ aus. Post Views Counter lief im REST-API-Modus, der Endpoint antwortete, aber beim Test auf dem gerade geöffneten Beitrag war die Zählung nicht zuverlässig nachvollziehbar. Erst als ich Page Cache, JavaScript-Minify, den aktuellen Post-Kontext und die Statistik-Einwilligung getrennt betrachtet habe, wurde der Fehler reproduzierbar.

Dieser Artikel beschreibt den konkreten Zustand von bybrzoza.com am 2. September 2026. Daraus folgt nicht, dass WP-Optimize grundsätzlich Post Views Counter beschädigt oder dass jede Website denselben Consent-Aufbau braucht. Entscheidend ist die Diagnosemethode und der auf dieser Installation bestätigte Runtime-Befund.

Getestete Umgebung

Vor dem Nachbauen sollte man die eigenen Versionen und den tatsächlich geladenen PVC-Asset-Pfad prüfen. In meinem Test war das post-views-counter/js/frontend.js.

1. Zuerst den Besitzer des Page Cache klären

Im Audit gab es tatsächlich eine doppelte Page-Cache-Konfiguration: WP-Optimize Page Cache und Cache Enabler waren gleichzeitig aktiv. WP-Optimize warnte selbst vor dem zweiten Cache-Plugin. Ich habe Cache Enabler deaktiviert, WP-Optimize als einzigen Page-Cache-Besitzer belassen, den Cache geleert und einen anonymen Smoke-Test gemacht.

Das war wichtig, um Störfaktoren zu entfernen. Es beweist aber nicht, dass der doppelte Page Cache den späteren PVC-Post-Kontext verursacht hat. Page Cache und Minify sind zwei getrennte Funktionen.

2. REST API 200 reicht nicht: Post-ID und Initiator prüfen

Post Views Counter unterstützt mehrere Zählmethoden; final nutzte ich REST API. Während der Diagnose gab es außerdem einen simplen Fehltest auf einer Page, obwohl der relevante Zähl-Scope Posts war. Das ist ein gutes Beispiel dafür, wie schnell man einen falschen Befund erzeugt.

Auf einem echten veröffentlichten Beitrag lieferte der PVC-Endpoint HTTP 200. Entscheidend war deshalb, in den DevTools pvcArgsFrontend, postID, Request-URL und Initiator zu vergleichen.

Solange das PVC-Frontend-JavaScript in einem zusammengeführten/minifizierten WP-Optimize-Bundle steckte, konnte der Request mit einem veralteten oder falschen Beitragskontext laufen. Der Transport sah erfolgreich aus, aber der sichtbare Zähler passte nicht zuverlässig zum aktuellen Beitrag.

3. Nicht Minify komplett abschalten, sondern nur PVC ausschließen

In WP-Optimize waren JavaScript-Minification und Merging aktiv. Die gezielte Änderung lag unter:

WP-Optimize → Minify → JavaScript → Exclude JavaScript from processing

Auf meiner Version wurde der Asset-Pfad mit folgendem eindeutigen Teil ausgeschlossen:

post-views-counter/js/frontend.js

Laut aktueller WP-Optimize-Dokumentation wird ein dort eingetragener Script-Asset sowohl aus Minification als auch aus Merging entfernt. Nach dem Speichern habe ich die Minify-/Cache-Dateien zurückgesetzt und einen neuen anonymen Test gemacht.

Danach wurde frontend.js separat geladen. Der Request kam vom richtigen Script, enthielt die korrekte aktuelle Post-ID und sowohl der sichtbare als auch der Backend-Zähler stiegen konsistent.

4. Erst danach den funktionierenden Zähler an Statistics-Consent binden

Auf dieser Website habe ich PVC als Statistik-Funktion behandelt. Das ist die Konfiguration dieser Installation und keine allgemeine Rechtsberatung.

Unter Complianz → Integrations → Script Center wurde eine Blockierregel angelegt:

• Name: Post Views Counter
• Action: Block a script, iframe or plugin
• URL/Script: post-views-counter/js/frontend.js
• Category: Statistics

Complianz weist in der eigenen Dokumentation darauf hin, für solche Regeln einen möglichst spezifischen URL- oder Script-Identifier zu verwenden. Ein zu breites Muster kann andere Scripts mit blockieren.

5. Runtime-Matrix: vor Auswahl, Deny und Accept

Die Verifikation lief in einer frischen privaten Browser-Sitzung auf einem echten veröffentlichten Beitrag. Entscheidend war das Browser-Verhalten, nicht nur die Complianz-Konfiguration im Backend.

6. Service und Cookie in Complianz dokumentieren

Script Center regelt, wann der Code ausgeführt wird. Zusätzlich sollte die Cookie Policy das Verhalten widerspiegeln, das ich im Browser tatsächlich gesehen habe. Dafür habe ich einen eigenen Service und Cookie-Eintrag gepflegt.

Die deutsche Funktionsbeschreibung lautet: „Speichert besuchte Beiträge und Sitzungsinformationen, um eine mehrfache Zählung von Seitenaufrufen zu verhindern.“ PL und EN wurden ebenfalls manuell gepflegt.

7. Eigenes Usage-Fragment blieb trotzdem Englisch

Hier muss man zwei Probleme auseinanderhalten. Den früheren Timing-Konflikt zwischen synchronisiertem Complianz-Dokument und Polylang „The language is set from content“ habe ich bereits separat dokumentiert: Complianz + Polylang: Cookie-Richtlinie bleibt Englisch – Fix.

Diesmal war das Hauptdokument bereits korrekt. Nur der automatisch erzeugte Usage-Satz des eigenen PVC-Service blieb gemischt:

• DE: Wir verwenden Post Views Counter für website statistics.
• PL: Używamy Post Views Counter dla website statistics.

Weder der manuell gepflegte Service Type noch Polylang String Translations änderten genau dieses Fragment.

8. Eng begrenzter Workaround mit cmplz_document_html

Die Complianz-Dateien selbst habe ich nicht verändert. Der bereits vorhandene MU-Plugin-Fix 0.1.0 wurde auf 0.2.0 erweitert. Die neue Funktion arbeitet nur im finalen HTML der synchronisierten EU Cookie Policy, nur für pl_PL und de_DE, nur für Complianz >=7.5.4 und <8.0.0. EN bleibt unverändert.

function bybrzoza_cmplz_localize_pvc_usage( string $html, string $type, int $post_id ): string {
    if ( $html === '' || is_admin() || wp_doing_ajax() || wp_doing_cron() ||
        ( defined( 'REST_REQUEST' ) && REST_REQUEST ) ) {
        return $html;
    }

    if ( ! function_exists( 'pll_current_language' ) || ! class_exists( 'COMPLIANZ' ) ) {
        return $html;
    }

    if ( ! defined( 'CMPLZ_VERSION' ) || ! isset( COMPLIANZ::$document ) ||
        ! method_exists( COMPLIANZ::$document, 'get_document_data' ) ) {
        return $html;
    }

    $cmplz_version = strtok( (string) CMPLZ_VERSION, '#' );
    if ( version_compare( $cmplz_version, '7.5.4', '<' ) ||
        version_compare( $cmplz_version, '8.0.0', '>=' ) ) {
        return $html;
    }

    $pll_locale = pll_current_language( 'locale' );
    $wp_locale  = get_locale();
    if ( ! is_string( $pll_locale ) || $pll_locale === '' || $pll_locale !== $wp_locale ) {
        return $html;
    }

    if ( ! in_array( $wp_locale, array( 'pl_PL', 'de_DE' ), true ) ) {
        return $html;
    }

    $document_data = COMPLIANZ::$document->get_document_data( $post_id );
    if ( ! is_array( $document_data ) || ( $document_data['type'] ?? '' ) !== 'cookie-statement' ) {
        return $html;
    }

    $region = $document_data['region'] ?? false;
    if ( ! $region && function_exists( 'cmplz_get_region_from_legacy_type' ) ) {
        $region = cmplz_get_region_from_legacy_type( 'cookie-statement' );
    }
    if ( $region !== 'eu' ) {
        return $html;
    }

    $replacements = array(
        'de_DE' => array(
            'old' => 'Wir verwenden Post Views Counter für website statistics',
            'new' => 'Wir verwenden Post Views Counter für Website-Statistiken',
        ),
        'pl_PL' => array(
            'old' => 'Używamy Post Views Counter dla website statistics',
            'new' => 'Używamy Post Views Counter dla statystyk witryny',
        ),
    );

    $replacement = $replacements[ $wp_locale ] ?? null;
    if ( ! is_array( $replacement ) ) {
        return $html;
    }

    return str_replace( $replacement['old'], $replacement['new'], $html );
}

add_filter( 'cmplz_document_html', 'bybrzoza_cmplz_localize_pvc_usage', 20, 3 );

Der String-Ersatz ist absichtlich service-spezifisch. Sobald Complianz den Text selbst korrekt ausgibt, verschwindet das alte exakte Fragment und der Workaround wird automatisch zum No-op. Ab Complianz 8.x greift der Versions-Guard ebenfalls nicht mehr; dann ist ein neuer Source-Audit nötig.

9. Ergebnis in PL, DE und EN

Nach Deployment von 0.2.0 und Purge wurde die öffentliche Cookie Policy in allen drei Sprachen kontrolliert:

• PL: „Używamy Post Views Counter dla statystyk witryny.“ / „1 dzień“ / polnische Funktion;
• DE: „Wir verwenden Post Views Counter für Website-Statistiken.“ / „1 Tag“ / deutsche Funktion;
• EN: „We use Post Views Counter for website statistics.“ / „1 day“ / englische Funktion.

Fehlspuren, die Zeit gekostet haben

• Website Scan bei 50%: einmal 100% mit 18 Cookies, später wieder 50%. Kein bewiesener PVC-Root-Cause und kein sinnvoller Completion Gate.
• Test auf einer Page: bei relevantem Scope Posts nicht aussagekräftig.
• HTTP 200: bestätigt Transport, nicht den richtigen Post-Kontext.
• Nur Cache purgen: ohne Initiator und postID zu kontrollieren fehlt der eigentliche Nachweis.
• Polylang String Translations: für viele Texte sinnvoll, aber in diesem Custom-Usage-Fragment ohne Wirkung.

Rollback und Update-Checks

Für die WP-Optimize-Änderung ist der Rollback einfach: den PVC-Eintrag aus der Exclusion-Liste entfernen, speichern, Minify/Cache zurücksetzen und erneut testen. Für den MU-Plugin-Teil kann man die vorherige 0.1.0 wiederherstellen oder die zusätzliche 0.2.0-Funktion entfernen und anschließend die öffentliche Policy erneut prüfen.

Nach einem PVC-Update muss der echte frontend.js-Pfad neu kontrolliert werden. Nach einem WP-Optimize-Update prüfe ich die Exclusion erneut. Nach Complianz- oder Polylang-Updates reicht zunächst ein gezielter PL → DE → EN Smoke-Test. Den Complianz-8.x-Guard sollte man nicht einfach entfernen, sondern zuerst den aktuellen Source nachvollziehen.

Fazit

Die Lösung war nicht „mehr Cache leeren“, sondern die Schichten auseinanderzunehmen: ein Page-Cache-Besitzer, der richtige Beitrag und Request, ein einzelner Minify-Ausschluss, danach Consent und Cookie-Dokumentation. So lässt sich jeder Schritt einzeln testen und zurückrollen.

Quellen und weiterführende Links

• Post Views Counter — WordPress.org
• WP-Optimize — einzelne JavaScript-Dateien ausschließen
• Complianz — Script Center / Integrationen
• Complianz — Hooks und Filter
• Polylang — String Translations

Hat dir diese Anleitung geholfen?
Wenn sie dir etwas Zeit oder Nerven gespart hat, kannst du mir einen Kaffee ausgeben.