Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Borlabs Cookie: Debug-Konsole deaktivieren (v2 & v3)

    · von
    DSGVO

    Die Debug-Konsole von Borlabs Cookie schalten Sie im WordPress-Backend unter Borlabs Cookie → Einstellungen aus: die Option Debug Console deaktivieren und speichern. In Version 3.4 sind die Einstellungen in mehrere Seiten aufgeteilt, der Schalter sitzt bei den Plugin-Optionen (den genauen Weg zeigen wir gleich). In der 2er-Reihe liegt der Schalter ebenfalls unter Einstellungen, dort beim Stichwort „Debug“. Wer es versionsunabhängig und update-sicher erzwingen will, setzt einen Filter in die functions.php:

    add_filter('borlabsCookie/frontendResources/disableDebugConsole', '__return_true');

    Bleibt das Diagnose-Panel danach trotzdem sichtbar, liegt das fast immer an genau zwei Dingen: Sie sind noch als Administrator angemeldet (nur dann zeigt Borlabs die Konsole überhaupt an), oder ein Cache liefert die alte Datei aus. Beide Fälle klären wir unten Schritt für Schritt – samt sauberer Kontrolle, die nicht bloß Ihren eigenen Browserstand „repariert“.

    Seit Version 3.2 (26. September 2024) ist die Debug-Konsole kein reines console.log-Rauschen mehr, sondern ein frei verschiebbares Diagnose-Overlay im Frontend. Es erscheint nur für angemeldete Administratoren – normale Besucher sehen es nie. Sie können das Panel vertikal ziehen, um darunterliegende Elemente zu erreichen, und es listet eine Reihe von Selbsttests auf, die bei der Einrichtung wirklich hilfreich sind:

    PrüfpunktWas er bedeutetWo Sie ihn korrigieren
    Config is loadedDie Konfigurationsdatei wird überhaupt geladenCache-/Optimierungs-Plugin, das JS zusammenfasst
    Config is placed correctlyDie Config liegt vor dem Kern-JavaScriptReihenfolge/Optimierung der Skripte
    Cookie Domain is set correctlyDie hinterlegte Cookie-Domain stimmtEinstellungen → Domain
    Plugin URL is set correctlyDie Plugin-URL passtEinstellungen → Plugin URL
    REST-API erreichbarKein 404 auf die REST-SchnittstellePermalinks / Server-Konfiguration
    Analytics / Site KitTracking wird korrekt geblockt bzw. freigegebenService- und Script-Blocker

    Die letzten beiden Punkte sind jung: Den REST-API-Test hat Borlabs mit Version 3.3 ergänzt, damit 404-Fehler auf die Schnittstelle sofort auffallen. Und seit Version 3.4.1 (28. April 2026) bezieht die Analytics-Prüfung ausdrücklich auch Google Site Kit ein. Wenn Sie Site Kit einsetzen, lohnt vor dem Abschalten ein kurzer Blick, ob der Blocker greift – Details dazu unter Borlabs & Google Site Kit.

    Wichtig zur Abgrenzung: Wenn nicht ein Overlay auftaucht, sondern die Browser-Konsole bei jedem Besucher mit Borlabs-Meldungen vollläuft, ist das nicht die Debug-Konsole, sondern der Entwickler-„JavaScript-Log“. Den aktiviert man über die Konstante BORLABS_COOKIE_DEV_MODE_ENABLE_DEBUG_INTERFACE in der wp-config.php – sie schreibt interne JS-Prozesse in die Konsole und blendet zusätzlich den Menüpunkt System › Debug ein. Diese Ebene behandeln wir separat unter Borlabs Debug abschalten. Ebenfalls kein Fall für den Debug-Schalter sind rote Uncaught …-Fehler: Das sind echte JavaScript-Fehler, die bestehen bleiben, egal ob Debug an oder aus ist.

    Prüfen Sie zuerst unter Plugins → Installierte Plugins, welche Version läuft. Aktuell (Stand Juli 2026) ist 3.4.2 vom 11. Juni 2026 die neueste Ausgabe. So gehen Sie in der 3er-Reihe vor:

    1. Im WordPress-Backend links Borlabs Cookie öffnen.
    2. In die Einstellungen wechseln.
    3. Die Option Debug Console suchen und deaktivieren.
    4. Mit Speichern bestätigen.

    Zwei Details sparen hier viel Sucherei. Erstens hat Borlabs mit Version 3.4 einen Anzeigemodus der Einstellungen eingeführt (auf der Seite Admin- & Plugin-Einstellungen). Steht dieser auf „Vereinfacht“, blendet das Plugin fortgeschrittene Optionen bewusst aus – gedacht für nicht-technische Redakteure. Finden Sie den Schalter nicht, stellen Sie den Modus zuerst auf „Standard“; dann erscheinen alle Optionen inklusive der Debug Console. Zweitens ist die Debug Console seit Version 3.2.3 (14. Oktober 2024) bei Updates standardmäßig deaktiviert. Bei einer frischen Neuinstallation ist sie dagegen weiterhin aktiv, damit Sie während der Einrichtung sofort Diagnosedaten sehen. Genau deshalb taucht sie so oft auf frisch aufgesetzten Projekten auf, die direkt live gegangen sind.

    Wo der Schalter seit Version 3.4 sitzt

    Mit Version 3.4 (6. Februar 2026) hat Borlabs die frühere Sammelseite Einstellungen auseinandergezogen. Die inhaltlichen Optionen verteilen sich jetzt auf drei Bereiche – Allgemeine Einstellungen, Consent-Einstellungen und Cookie-Einstellungen. Die reinen Plugin- und Admin-Schalter dagegen – etwa der Anzeigemodus der Einstellungen, Meta-Box anzeigen und Drittanbieter-Cache leeren – wanderten auf eine eigene Seite Admin- & Plugin-Einstellungen.

    Die Debug Console gehört zu genau dieser Klasse technischer Schalter und liegt in 3.4 aller Voraussicht nach auf der Seite Admin- & Plugin-Einstellungen. Taucht sie dort nicht auf, prüfen Sie Allgemeine Einstellungen. Verlassen sollten Sie sich auf keine der beiden Positionen: Beschriftungen und Menüpfade haben sich zwischen 3.0 und 3.4 mehrfach verschoben. Der robuste Weg, der jede Umbenennung übersteht, ist der Filter aus dem nächsten Abschnitt.

    Versionsunabhängig per Filter erzwingen

    Wenn Sie mehrere Kundenprojekte in unterschiedlichen Unterversionen betreuen oder sich schlicht nicht auf die exakte Menüposition verlassen wollen, schalten Sie die Konsole per Filter ab. Das ist die zuverlässigste Methode und überlebt jedes Update:

    add_filter('borlabsCookie/frontendResources/disableDebugConsole', function (bool $status = false) {
    return true;
});

    Den Code legen Sie in die functions.php Ihres Child-Themes oder in ein Code-Snippet-Plugin (z. B. WPCode) – nicht ins Eltern-Theme, dort überschreibt das nächste Theme-Update Ihre Änderung. Die Kurzform '__return_true' aus dem ersten Absatz tut exakt dasselbe; die ausführliche Variante ist nur leichter zu lesen und zu kommentieren. Borlabs stellt für die Frontend-Ressourcen weitere Filter nach demselben Muster bereit:

    Filter-HookWirkung
    …/disableDebugConsoleDebug-Konsole im Frontend abschalten
    …/disableJavaScriptLoadingBorlabs-JavaScript gar nicht laden
    …/disableCssLoadingBorlabs-CSS gar nicht laden
    …/disabledOnRestRequestRessourcen bei REST-Anfragen unterdrücken (Standard: true)

    Alle beginnen mit dem Präfix borlabsCookie/frontendResources/. Für den Zweck „Konsole im Livebetrieb still“ brauchen Sie nur den ersten. Beim letzten ist zu beachten: Borlabs lädt seine Ressourcen bei REST-Anfragen ohnehin schon nicht – der Hook existiert nur, um genau dieses Standardverhalten bei Bedarf umzukehren. Die beiden mittleren sind für Sonderfälle wie Page-Builder oder eine eigene Ladelogik gedacht; wer sie ohne Grund setzt, legt Consent-Banner oder -Styling lahm.

    Läuft bei Ihnen noch die 2er-Reihe, finden Sie die Einstellung so:

    1. Borlabs Cookie → Einstellungen öffnen.
    2. Zur Option Debug bzw. Debug-Modus scrollen.
    3. Den Schalter deaktivieren bzw. das Häkchen entfernen.
    4. Unten mit Einstellungen speichern bestätigen.

    Borlabs pflegt die offizielle Dokumentation inzwischen nur noch für die 3er-Reihe, und die 2er-Konsole war schlichter (eher konsolenlastige Ausgaben als das heutige Overlay). Der Filter aus dem vorigen Abschnitt greift zudem erst ab Version 3; in 2.x bleibt der Schalter in den Einstellungen der einzige Weg. Läuft bei Ihnen noch 2.x, ist der Umstieg auf Version 3 ohnehin überfällig – schon wegen der Kompatibilität mit aktuellem WordPress und PHP: Version 3.4 unterstützt PHP 7.4 bis 8.5.

    „Deaktiviert – und trotzdem sichtbar“: die zwei üblichen Ursachen

    Sie haben den Schalter umgelegt, laden neu – und die Konsole ist noch da. In fast allen Fällen ist eine dieser beiden Ursachen schuld. Arbeiten Sie sie in dieser Reihenfolge ab:

    1. Sie sind noch angemeldet. Das Overlay erscheint ausschließlich für eingeloggte Administratoren. Solange Sie im Backend angemeldet sind, sehen Sie es weiter – Ihre Besucher aber längst nicht mehr. Öffnen Sie die Seite in einem Inkognito-/Privatfenster oder loggen Sie sich aus. Verschwindet die Konsole dort, war nie ein echtes Problem da: Für die Öffentlichkeit war sie bereits unsichtbar.

    2. Ein Cache liefert die alte Datei. Borlabs generiert seine Frontend-Dateien beim Speichern neu; bis diese debug-freie Version überall ankommt, kann eine zwischengespeicherte Kopie weiter mit Ausgaben antworten. Gehen Sie von günstig nach aufwändig vor:

    • Browser-Cache: Hart neu laden (Strg + F5) oder privates Fenster nutzen.
    • Caching-Plugin: WP Rocket, LiteSpeed Cache, W3 Total Cache o. Ä. komplett leeren – vor allem minifiziertes/kombiniertes JavaScript hält die alte Version hartnäckig fest. Speziell zu WP Rocket: WP Rocket & Borlabs Cookie.
    • Server-/Objekt-Cache: Bei Nginx-FastCGI, Varnish oder Redis/Memcached über das Hosting-Panel (Plesk, Managed WordPress) leeren.
    • CDN: Bei Cloudflare & Co. den Edge-Cache leeren (Cloudflare: „Purge Everything“).
    • Borlabs-Dateien neu schreiben: Einen eigenen „Frontend-Dateien leeren“-Knopf gibt es nicht – diese Dateien entstehen beim Speichern der Einstellungen neu. Speichern Sie nach dem Umlegen des Schalters deshalb bewusst noch einmal; die Detailschritte stehen unter Borlabs Cache zurücksetzen.

    Meist ist nach dem privaten Fenster oder Schritt 2 Ruhe. Wie WordPress-Caches zusammenspielen und wo sie sitzen, lesen Sie unter Wo finde ich den WordPress-Cache?.

    Sauber prüfen, dass die Konsole still ist

    Kontrollieren Sie das Ergebnis so, dass Sie den Besucherstand testen und nicht Ihren eigenen:

    1. Ein Inkognito-Fenster öffnen – oder sich vollständig aus dem WordPress-Backend ausloggen.
    2. Ihre Seite aufrufen und die Entwicklertools öffnen (F12), Reiter Konsole.
    3. Einmal neu laden und den Cookie-Dialog bedienen (annehmen und in einem zweiten Durchgang ablehnen), damit auch die Consent-Aktionen durchlaufen.

    Erscheinen kein Overlay und keine Borlabs-Meldungen mehr, ist der Debug-Modus im Produktivbetrieb sauber abgeschaltet. Ein pragmatischer Arbeitsmodus für die Zukunft: Debug in einer Staging-Umgebung aktiv lassen, live aus. So behalten Sie das Diagnosewerkzeug, ohne es je in der Öffentlichkeit zu vergessen. Wie Sie Ihr Consent-Setup von Grund auf sauber aufsetzen, zeigt Optimale Einstellungen für Borlabs Cookie.

    FAQ

    Sehen meine Besucher die Debug-Konsole überhaupt? Das Diagnose-Overlay in Version 3 nicht – es wird nur angemeldeten Administratoren gezeigt. Was Besucher sehen können, sind console.log-Meldungen aus dem separaten Entwickler-„JavaScript-Log“, den die Konstante BORLABS_COOKIE_DEV_MODE_ENABLE_DEBUG_INTERFACE in der wp-config.php einschaltet. Diese Ausgaben stellen Sie über die Konstante ab, nicht über den Debug-Console-Schalter – siehe Borlabs Debug abschalten.

    Ich finde die Option „Debug Console“ nirgends – wo ist sie? Drei Gründe sind typisch. Erstens steht der Anzeigemodus seit Version 3.4 vielleicht auf „Vereinfacht“ und blendet fortgeschrittene Optionen aus – auf „Standard“ umstellen. Zweitens wurde die Seite Einstellungen in 3.4 aufgeteilt; suchen Sie auf Admin- & Plugin-Einstellungen und Allgemeine Einstellungen. Drittens läuft womöglich noch eine 2.x-Version, in der die Option schlicht „Debug“ heißt. Prüfen Sie zuerst die installierte Version unter Plugins.

    Brauche ich eine bestimmte Borlabs-Lizenz, um die Konsole abzuschalten? Nein. Borlabs Cookie ist zwar kostenpflichtig und hat keine Gratis-Version – die Lizenzen laufen als Jahresabo und unterscheiden sich nur in der Website-Zahl: Personal 49 € (1 Website), Business ab 79 € (3), 109 € (5) und 179 € (10), Agency ab 229 € (25) bis 499 € (99 Websites), jeweils pro Jahr und zzgl. MwSt. (Stand 2026). Doch die Debug Console ist ein Kern-Feature und in jeder Stufe enthalten. Schalter und Filter funktionieren unabhängig vom Tarif.

    Ist eine aktive Debug-Konsole ein DSGVO-Problem? Nicht per se. Sie zeigt technische Consent- und Konfigurationszustände, keine personenbezogenen Daten Dritter. Trotzdem gehört sie im Livebetrieb aus: Sie legt interne Konfiguration offen und wirkt unfertig. Ein sauberer Auftritt ist Teil eines professionellen, DSGVO-konformen Setups.

    Verbessert das Abschalten meinen PageSpeed spürbar? Nein. Die paar Diagnose-Aufrufe haben auf Ladezeit und Core Web Vitals praktisch keinen messbaren Effekt. Der Grund zum Abschalten ist Diskretion und Sauberkeit, nicht Performance.

    Die Konsole meldete, dass Analytics nicht blockiert wird – hilft das Abschalten? Nein, im Gegenteil: Diese Meldung ist ein echter Hinweis, den Sie zuerst beheben sollten. Sie besagt, dass ein Tracking-Skript ohne Einwilligung lädt. Bringen Sie erst den Script-Blocker in den Borlabs-Einstellungen in Ordnung – konkret zu Google Analytics unter Analytics wird nicht blockiert – und schalten Sie die Konsole danach ab.

    → Mehr zum Thema: Alle Artikel unter DSGVO