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

    Borlabs Cookie Debug Console ausblenden

    · von
    DSGVO

    Um die Borlabs Cookie Debug Console im Frontend auszublenden, genügt eine einzige Zeile an update-sicherer Stelle – in der functions.php eines Child-Themes oder in einem Must-Use-Plugin:

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

    Das Diagnose-Panel verschwindet damit zuverlässig, unabhängig von jeder Einstellung im Backend. Die console.log-Meldungen, die parallel in den Browser-Entwicklertools auftauchen können, stammen aus einer anderen Quelle – einer Entwickler-Konstante in der wp-config.php – und müssen getrennt entfernt werden. Zur Beruhigung vorweg: Borlabs zeigt die Debug Console laut Hersteller ausschließlich eingeloggten Administratoren an; gewöhnliche Besucher bekommen das Panel nie zu sehen. Aus dem Livebetrieb gehört es trotzdem, weil es interne Konfigurationsdetails preisgibt und zusätzliche Ressourcen lädt. Die folgenden Schritte erklären die saubere Filter-Methode, die Ursache in der wp-config.php und die Grenzfälle, an denen die üblichen Anleitungen scheitern.

    Drei Dinge, die „Debug” heißen – und sauber getrennt gehören

    Rund um „Debug” wirft Borlabs Cookie drei verschiedene Funktionen in einen Topf, die oft verwechselt werden. Wer sie auseinanderhält, sucht nicht am falschen Schalter. Die Debug Console als Frontend-Panel kam mit Version 3.2 (September 2024) neu hinzu – laut Changelog, um Fehlkonfigurationen und typische Probleme mit der Google-Tag-Manager-Einbindung sichtbar zu machen. Die beiden anderen Bausteine gab es davor schon in ähnlicher Form.

    BausteinWo es erscheintWer es siehtWodurch aktivSo abgeschaltet
    Debug Console (Panel)Frontend, als Overlaynur eingeloggte Adminsseit v3.2 bei Neuinstallation standardmäßig anFilter disableDebugConsole
    JavaScript-Logs (console.log)Browser-DevTools, Reiter „Console”jeder, der F12 öffnetKonstante ENABLE_JAVASCRIPT_LOGSKonstante aus wp-config.php entfernen
    System → Debug (Menü)WordPress-BackendAdmins im AdminbereichKonstante ENABLE_DEBUG_INTERFACEKonstante aus wp-config.php entfernen

    Der entscheidende Punkt: Ein einzelnes Häkchen, das alle drei gleichzeitig ausblendet, gibt es nicht. Das Panel steuern Sie am zuverlässigsten per Filter, die Konsolen-Logs und das Backend-Menü hängen dagegen an Konstanten. Genau deshalb bleibt „irgendwo in den Einstellungen klicken” oft wirkungslos.

    Methode 1: Debug Console per Filter-Hook ausblenden

    Der Filter borlabsCookie/frontendResources/disableDebugConsole ist der offizielle, seit Version 3.2.11 (Dezember 2024) dokumentierte Weg, das Laden der Debug Console im Frontend zu unterbinden. Er greift unabhängig von Konstanten und Backend-Einstellungen und überlebt Plugin-Updates – das macht ihn zur ersten Wahl. In der Kurzform reicht der WordPress-Helfer __return_true, der schlicht true zurückgibt:

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

    Wer den Rückgabewert später an eine Bedingung knüpfen möchte (etwa nur auf der Live-Domain abschalten, im Staging aber anlassen), nutzt die ausführliche Closure-Variante:

    add_filter('borlabsCookie/frontendResources/disableDebugConsole', function (bool $status = false) {
    if (defined('WP_ENVIRONMENT_TYPE') && WP_ENVIRONMENT_TYPE !== 'production') {
        return $status; // im Staging Panel sichtbar lassen
    }
    return true;        // auf der Live-Seite ausblenden
});

    Wohin der Code gehört

    Entscheidend ist der Ablageort. Direkt ins Haupt-Theme geschrieben, wäre das Snippet beim nächsten Theme-Update wieder weg. Update-sicher sind:

    1. die functions.php eines Child-Themes – der Klassiker, wenn ohnehin ein Child-Theme existiert;
    2. ein kleines Must-Use-Plugin unter wp-content/mu-plugins/ (eine PHP-Datei mit <?php und dem Filter genügt) – lädt garantiert und lässt sich nicht versehentlich deaktivieren;
    3. ein Snippet-Plugin wie Code Snippets oder WPCode, wenn Sie keinen Dateizugriff per SFTP haben und lieber im Backend arbeiten.

    Der Sonderfall Compatibility Patches

    Ein Detail, das in generischen Anleitungen fehlt und im Support regelmäßig für Verwirrung sorgt: Setzen Sie den Filter innerhalb einer Borlabs Compatibility Patch, funktioniert das gewöhnliche add_filter() nicht. Borlabs verlangt an dieser Stelle die Methode addFilter() der eigenen WpFunction-Klasse. Für die normale Ablage in Child-Theme, mu-Plugin oder Snippet-Plugin gilt das nicht – dort bleibt es bei WordPress-Standard-add_filter().

    Verwandte Filter aus derselben Gruppe

    Der Debug-Filter ist Teil einer kleinen Familie von frontendResources-Hooks. Für das reine Ausblenden der Console brauchen Sie nur den ersten, die anderen sind bei gezielter Ressourcensteuerung nützlich:

    • borlabsCookie/frontendResources/disableCssLoading – unterdrückt das Borlabs-CSS im Frontend;
    • borlabsCookie/frontendResources/disableJavaScriptLoading – unterdrückt das Borlabs-JavaScript;
    • borlabsCookie/frontendResources/disabledOnRestRequest – steuert, ob die Ressourcen bei REST-Requests geladen werden (Standard: nicht geladen).

    Methode 2: Ursache in der wp-config.php beseitigen

    Bleibt in den DevTools eine Flut von console.log-Meldungen mit Borlabs-Präfix übrig, hilft der Frontend-Filter nicht – diese Logs hängen ausschließlich an einer Entwickler-Konstante. Solche define()-Zeilen wandern gern per Copy-and-paste von der Test- auf die Live-Umgebung oder werden von einer Agentur während der Einrichtung gesetzt und nie wieder entfernt. Öffnen Sie die wp-config.php im Stammverzeichnis Ihrer WordPress-Installation per SFTP oder Dateimanager und suchen Sie nach Zeilen, die mit BORLABS_COOKIE_DEV_MODE beginnen.

    Diese Konstanten sind für den Livebetrieb relevant und sollten dort entfernt oder auf false gesetzt werden:

    define('BORLABS_COOKIE_DEV_MODE_ENABLE_JAVASCRIPT_LOGS', true);   // schreibt console.log in die Browser-Konsole
define('BORLABS_COOKIE_DEV_MODE_ENABLE_DEBUG_INTERFACE', true);   // blendet System → Debug im Backend ein
define('BORLABS_COOKIE_DEV_MODE_ENABLE_DEBUG_EXTENDED', true);    // erweiterte Debug-Logs bei aktivem Logging
define('BORLABS_COOKIE_DEV_MODE_DISABLE_CSS_CACHING', true);      // deaktiviert das CSS-Caching
define('BORLABS_COOKIE_DEV_MODE_ENABLE_ASSET_TIMESTAMPS', true);  // hängt Zeitstempel an CSS/JS-Dateien

    Die Schreibweise entspricht exakt der offiziellen Borlabs-Konstanten-Übersicht (Stand: Juli 2026), die insgesamt rund ein Dutzend DEV_MODE-Konstanten führt. Verlassen Sie sich beim Aufräumen auf die Präfix-Regel: Alles, was mit define('BORLABS_COOKIE_DEV_MODE_ beginnt, ist für die Entwicklung gedacht und hat auf einer produktiven Seite nichts verloren. Neben den fünf oben stehen dort weitere Dev-Konstanten wie BORLABS_COOKIE_DEV_MODE_DISABLE_SSL_VERIFY (erlaubt selbstsignierte Zertifikate und .local-Domains) oder BORLABS_COOKIE_DEV_MODE_ENABLE_LOCALIZATION_CHECKER_INTERFACE (blendet den Localization Checker im Backend ein). Eine wichtige Ausnahme, an der schon manche Seite versehentlich zerlegt wurde: BORLABS_COOKIE_ENABLE_SAFE_MODE trägt bewusst kein DEV_MODE im Namen. Das ist ein regulärer Betriebsschalter, der alle Compatibility Patches deaktiviert – er darf keinesfalls mit den Entwickler-Konstanten weggeräumt werden. Löschen Sie die echten Dev-Zeilen vollständig, statt sie nur auszukommentieren – ausgeklammerter Ballast bleibt sonst als Stolperfalle liegen.

    Drei Vorsichtsmaßnahmen sind bei dieser Datei Pflicht: Legen Sie vorher eine Sicherung an, bearbeiten Sie die Datei nur mit einem Editor, der die Kodierung nicht verändert (kein Word, kein Rich-Text), und achten Sie darauf, dass Ihre Zeilen oberhalb von /* That's all, stop editing! */ stehen. Ein fehlendes Semikolon oder Anführungszeichen legt sonst die gesamte Seite lahm. Nach dem Entfernen der Konstante leeren Sie den Cache und laden neu – die Konsolen-Logs sind dann verschwunden.

    Version prüfen: 2.x, 3.x und die aktuelle Ausgabe

    Welche Borlabs-Version bei Ihnen läuft, sehen Sie unter Plugins → Installierte Plugins neben „Borlabs Cookie”. Die aktuelle Ausgabe ist 3.4.2 vom 11. Juni 2026; Version 3.4 (Februar 2026) brachte den Setup-Assistenten und einen Safe Mode, Version 3.3 (März 2025) unter anderem einen Assistenten für die Dialogfarben.

    Für das Ausblenden der Debug Console ist die Versionsfrage nicht bloß Kosmetik:

    • Ab v3.2 existiert die Frontend-Debug-Console überhaupt erst. Bei Neuinstallationen ist sie standardmäßig aktiv (aber nur für Admins sichtbar). Für bestehende Installationen wurde sie mit einem der späteren 3.2.x-Updates standardmäßig wieder deaktiviert – deshalb taucht sie mal auf, mal nicht.
    • Ab v3.2.11 steht der Filter disableDebugConsole bereit. Auf einer älteren 3.2.x-Version greift das Snippet also nicht; hier hilft nur ein Update oder das Aufräumen der Konstanten.
    • In Version 2.x gab es dieses Panel noch gar nicht; die Diagnose war anders aufgebaut und die genannten Hooks existierten so nicht.

    Laufen Sie noch auf 2.x, lohnt sich ohnehin ein geplantes Update auf die 3er-Reihe – Borlabs pflegt Doku und Sicherheitsfixes nur noch dort. Bedenken Sie den Lizenzrahmen: Borlabs Cookie ist kostenpflichtig und wird als Jahreslizenz verkauft. Die Personal-Lizenz kostet 49 Euro pro Jahr für eine Website; die Business-Stufen liegen bei 79 Euro (drei Sites), 109 Euro (fünf) und 179 Euro (zehn), und wer viele Kundenprojekte betreut, greift zu den Agency-Paketen ab 229 Euro (25 Sites). Alle Beträge verstehen sich zzgl. MwSt. (Stand: Juli 2026); Sonderrabatte etwa zum Black Friday gibt es laut Hersteller bewusst nicht. Ein aktives Abo schaltet Updates und Support frei – ohne gültige Lizenz bleiben Sie auf einer alten Version hängen und bekommen den Filter unter Umständen gar nicht erst. Vor dem Update ein Backup ziehen und die Cookie-Gruppen danach kontrollieren.

    Ergebnis testen – Checkliste

    Damit Sie die Änderung nicht an einem gecachten Seitenstand fehlbewerten, arbeiten Sie diese Punkte der Reihe nach ab:

    1. Filter-Snippet gesetzt? Liegt es im Child-Theme, mu-Plugin oder Snippet-Plugin – und ist es aktiv?
    2. Konstanten entfernt? Keine BORLABS_COOKIE_DEV_MODE_-Zeile mehr in der wp-config.php.
    3. Caches geleert: Caching-Plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache), Server-/Objekt-Cache und CDN (etwa Cloudflare „Purge Everything”). Wie Sie die Ebenen sauber trennen, zeigt der Beitrag WordPress-Cache finden und leeren.
    4. Im Inkognito-Fenster prüfen: Seite dort aufrufen oder per Strg+F5 hart neu laden, damit kein lokaler Browser-Cache das Ergebnis verfälscht.
    5. DevTools kontrollieren: F12 öffnen, Reiter „Console” – es dürfen keine Borlabs-Meldungen mehr erscheinen, das Frontend-Panel ist weg.

    Erscheinen jetzt weder Panel noch Logs, ist die Debug Console im Produktivbetrieb sauber ausgeblendet. Bleiben ausschließlich rote Uncaught-Fehler, sind das eigenständige JavaScript-Probleme, die nichts mit dem Debug-Schalter zu tun haben.

    Typische Fehler und Lösungen

    • Panel bleibt sichtbar: Der Filter liegt im Haupt-Theme statt in Child-Theme oder mu-Plugin und wird nicht geladen – oder ein Cache liefert die alte Seite aus. Snippet an eine update-sichere Stelle legen und alle Cache-Ebenen leeren.
    • Filter greift nicht: Prüfen Sie die Version. Vor 3.2.11 existiert disableDebugConsole nicht – dann updaten oder über die Konstanten gehen. Innerhalb einer Compatibility Patch die WpFunction-Methode addFilter() verwenden.
    • Konsolen-Logs bleiben: Der Frontend-Filter erreicht sie nicht. Die Konstante BORLABS_COOKIE_DEV_MODE_ENABLE_JAVASCRIPT_LOGS muss aus der wp-config.php raus.
    • Diagnose-Test „Config is loaded” schlägt fehl: Ein Optimierungs-Plugin (Minify/Combine) verändert die Borlabs-Dateien. Schließen Sie alle URLs mit /borlabs-cookie/ im Pfad von Optimierung und Caching aus. Bleibt die Box ganz aus, hilft der Beitrag Borlabs Cookie Box wird nicht angezeigt.
    • „Cookie Domain is set correctly” ist rot: Domain unter Borlabs Cookie → Settings → Domain korrigieren; ganz unten auf der Einstellungsseite gibt es eine Reset-Option, siehe Borlabs Cookie zurücksetzen.
    • Weißer Bildschirm nach dem Bearbeiten der wp-config.php: Syntaxfehler, meist ein fehlendes Semikolon oder Anführungszeichen. Datei aus dem Backup wiederherstellen und die Änderung erneut, sauber vornehmen.

    FAQ

    Sehen normale Besucher die Debug Console überhaupt? Nein. Borlabs zeigt das Panel ausschließlich eingeloggten Administratoren (Stand: Juli 2026) – ausgeloggte Besucher sehen es nie. Die Konsolen-Logs erscheinen ebenfalls nur, wenn jemand die DevTools öffnet und die Konstante ENABLE_JAVASCRIPT_LOGS aktiv ist. Ein akutes Datenleck ist die Console also nicht; aufräumen sollten Sie sie trotzdem.

    Reicht der Filter allein, oder muss ich auch an die wp-config.php? Für das Frontend-Panel reicht der Filter. Die console.log-Ausgaben in den DevTools erreicht er aber nicht – die hängen an der Konstante BORLABS_COOKIE_DEV_MODE_ENABLE_JAVASCRIPT_LOGS. Sehen Sie nur das Panel, genügt Methode 1; sehen Sie zusätzlich Konsolen-Logs, brauchen Sie beide Schritte.

    Kann ich alles per Klick im Backend erledigen, ganz ohne Code? Das Panel schalten Sie am zuverlässigsten über den Filter ab – ohne Dateizugriff über ein Snippet-Plugin wie WPCode. Die Konsolen-Logs lassen sich nur durch Entfernen der Konstante in der wp-config.php stoppen; das übernimmt bei fehlendem Zugriff Ihr Hoster. Einen reinen Klick-Weg für beides gibt es nicht.

    Warum taucht die Debug Console nach einem Update plötzlich auf? Weil sie ab Version 3.2 bei Neuinstallationen standardmäßig aktiv ist und für bestehende Seiten je nach Update-Historie unterschiedlich vorbelegt wurde. Nach einem Umzug von Staging oder einem Plugin-Update kann außerdem eine Dev-Konstante mitgereist sein. Beide Ursachen decken Methode 1 und 2 ab.

    Bremst die Debug Console meine Ladezeit oder mein Ranking? Ein direkter Ranking-Faktor ist sie nicht, und der Ladezeit-Effekt ist gering. Sie lädt jedoch zusätzliche Ressourcen, gibt Domain- und Pfadangaben preis und wirkt auf aufmerksame Betrachter unfertig. Für einen sauberen Auftritt gehört sie im Livebetrieb aus.

    Was ist der Unterschied zu „Debug-Logging” im Backend? Die Debug Console ist das Frontend-Panel, das Debug-Logging schreibt dagegen Protokolldateien und wird über einen eigenen Schalter im Adminbereich gesteuert. Wollen Sie sämtliche Debug-Funktionen inklusive Logging und WordPress-eigenem WP_DEBUG abschalten, hilft der Überblick unter Borlabs Debug vollständig deaktivieren; den reinen Backend-Weg beschreibt Debug-Konsole deaktivieren.

    → Mehr zum Thema: Alle Artikel unter DSGVO