Was bei wpkookies neu ist.

Kookies Consent steht seit heute im offiziellen Plugin-Verzeichnis von WordPress.org. Nach dem automatischen Scan hat auch die menschliche Prüfung zugestimmt, und damit ist das Plugin dort zu finden, wo WordPress-Websites ihre Erweiterungen ohnehin installieren und aktuell halten. Für Betreiber ändert sich vor allem der Weg dorthin. Suchen, installieren und aktualisieren läuft jetzt direkt aus dem WordPress-Backend, ohne ZIP-Datei und ohne Umweg. Wer sucht, findet es unter dem Namen Kookies Consent. Alle Download-Schaltflächen auf dieser Website führen ab sofort direkt zur Plugin-Seite bei WordPress.org.

WordPress.org hat den Upload von 1.5.69 abgewiesen: „Tested up to: 7.0 < 7.1". Ein Plugin, dessen readme hinter der aktuellen WordPress-Version zurückbleibt, taucht in der Suche nicht auf. Die Angabe steht jetzt auf 7.1 — unabhängig bestätigt, nicht angenommen: das Release-Gate hat api.wordpress.org gefragt und 7.1 bekommen. Das Besondere an diesem Wert: Er veraltet nicht, weil wir etwas ändern, sondern weil WordPress ein Release macht. Kein Gate dieses Projekts hatte ihn je angesehen — in einer Datei, die über Aufnahme oder Ablehnung entscheidet. Ab sofort fragt die Release-Prüfung selbst nach der aktuellen WordPress-Version und verweigert eine Auslieferung, die zurückliegt; ist die Schnittstelle nicht erreichbar, sagt sie das ausdrücklich, statt eine Prüfung zu melden, die nicht stattgefunden hat. Am Verhalten des Plugins ändert sich nichts.

Die Code-Suche aus 1.5.66 fand auf einer echten Website mit 36 Plugins 17 Anbieter — und der Browser-Test traf auf zwölf Seiten keinen einzigen davon an. Als flache Liste gleichrangiger Einträge verlangte der Bildschirm 17 Entscheidungen, die niemand treffen konnte; wer sie getroffen hätte, hätte 17 Dienste in sein Einwilligungsbanner geholt, die seine Website nie lädt. Jetzt entscheidet die Messung: Was der Browser-Test wirklich angetroffen und blockiert hat, steht oben als Arbeitsposten, mit dem Datum der Messung, auf der die Aussage beruht. Alles Übrige klappt zu einer Zeile zusammen, die ihre eigenen Grenzen nennt — der Test besucht nur eine begrenzte Zahl von Seiten, und was allein hinter einem Formular steht, sieht er nicht. Die Zuordnung läuft über den erkannten Dienst, nicht über den Hostnamen: www.google.com gehört gleichzeitig zu Google Maps und zu reCAPTCHA, und nur der Pfad unterscheidet sie. Ohne Messung steht dort kein grüner Haken mehr, und eine abgebrochene oder veraltete Suche gibt keine Entwarnung. Dazu behoben: Der reine Suchknopf verwarf den bestandenen Prüfbericht der Website, ein Cache-Befund verschwand nach jedem Update lautlos statt nur bei geänderter Fragestellung, und ein Dienst, der über den Nachbarabschnitt eingerichtet wurde, blieb als Vorschlag stehen und behauptete danach das Gegenteil des Gemessenen.

Der Browser-Test scheiterte auf jeder Installation mit 1.5.66 und 1.5.67. Er lief bis zum Ende durch und wurde dann abgewiesen: „Der Browser-Test hat nicht alle geforderten Seiten- und Dienstbelege geliefert." Die Ursache war eine Zahl an zwei Stellen: 1.5.66 hob den Durchlauf von fünf internen Seiten auf zwölf, während der Server, der den Bericht prüft, seine eigene Kopie bei fünf beließ — und er weist jeden Bericht ab, dessen Seitenzahl von seiner eigenen abweicht. Die Zahl wohnt jetzt allein auf dem Server: er gibt sie bekannt, der Browser liest sie, und beide können nicht mehr auseinanderlaufen. Ein Test vergleicht sie über beide Sprachen hinweg — denn nichts sonst konnte das sehen: Die Browser-Suite läuft gegen Attrappen, die PHP-Tests bauen ihre Berichte aus der Server-Konstante und sind sich deshalb mit sich selbst einig, und der Ende-zu-Ende-Lauf startet nie einen echten Test.

Ein Kunde hat aktualisiert, die Einstellungsseite geöffnet und eine rote Warnung vorgefunden: Ein Cache außerhalb von WordPress liefere gespeicherte Seiten aus, der Hoster solle ihn abschalten. Die Warnung war falsch. Sie maß, ob die Startseite überhaupt irgendwo gespeichert wird — das trifft auf fast jedes Hosting-Paket zu und ist der harmlose Fall, denn gespeichert wird die anonyme Seite, auf der ohnehin alles blockiert ist. Die Einwilligung bricht erst ein Cache, der genau diese gespeicherte Seite auch an einen Besucher mit Einwilligungs-Cookie ausliefert. Die Prüfung wärmt den Cache jetzt an, bestätigt, dass die Seite wirklich wiederverwendet wird, und fragt sie danach ein weiteres Mal mit Einwilligungs-Cookie ab. Antwortet der Cache daraufhin aus seinem Speicher, wird das gemeldet; antwortet er frisch, wird nichts angezeigt. Und gibt es etwas zu melden, sagt der Text, was schiefgeht, und bittet um das, was hilft — Seiten mit dem Einwilligungs-Cookie an WordPress durchreichen —, statt das Abschalten des Caches zu verlangen.

Eine Kundenwebsite verlor ihre Dienstliste und bekam sie nicht zurück, weil das Plugin, von dem übernommen worden war, nicht mehr existierte. Der Wiederaufbau aus der Browser-Prüfung erreichte zwei Anbieter — diese Prüfung besucht eine Handvoll Seiten und kann nur melden, was diese Seiten zufällig laden. wpkookies durchsucht jetzt auch den installierten Code: die aktiven Plugins, die Muss-Plugins, das aktive Theme und dessen Eltern-Theme, nach den 88 Anbieter-Domains seines Katalogs. Jeder gefundene Anbieter lässt sich mit einem Knopf einrichten, samt Anbieter, Zweck und Pflichtangaben. Ein Fund wird benannt als das, was er ist: ein Beleg, dass dieser Code den Anbieter aufrufen kann — nicht, dass jede Seite ihn lädt. Verweise und Teilen-Knöpfe zählen nicht mehr als Einbettung, die Anbieterlisten anderer Einwilligungs-Plugins werden übersprungen, und eine Suche, die abbrechen muss, nennt den wirklich gelesenen Anteil, statt Entwarnung zu geben.

Eine produktive, vollständig migrierte Installation wurde durch einen Klick auf „Installation vollständig zurücksetzen" gelöscht — gedrückt von jemandem, der dieses Plugin kennt. Der Knopf sitzt jetzt hinter den technischen Einstellungen statt zwischen den beiden Kästen, mit denen gearbeitet wird, und er nennt vor der Ausführung die gemessene Einbuße genau dieser Website: wie viele Einträge die Dienstliste hat, ob eine abgeschlossene Übernahme und eine Rückweg-Sicherung betroffen sind, und wie viele Zeilen das Einwilligungsprotokoll wirklich enthält — gezählt, nicht angenommen. Alles, was über eine blanke Neuinstallation hinausgeht, verlangt eine zweite ausdrückliche Bestätigung, die der Server erzwingt. Zwei weitere Wege, dieselben Daten zu verlieren, sind geschlossen: eine leere Dienstliste wird abgewiesen statt gespeichert, und der Editor zeigt den gespeicherten Stand statt einer gefilterten Ansicht, die verborgene Dienste beim Speichern löschen würde. Im Netzwerkbetrieb wird die Löschfreigabe je Website gelesen. Und nach bestandener Prüfung sagt der Bildschirm endlich, dass nichts zu tun ist — aber geschützt darf nur der Server eine Website nennen, denn der Browser-Test belegt eine von sechs Prüfungen.

Cache-Wahrheit statt Cache-Annahme. Vor jeder Browser-Prüfung misst das Plugin jetzt, ob die Website wirklich frische Seiten ausliefert: dieselbe Vorschau-Adresse wird zweimal geladen und muss zwei verschiedene Einmal-Kennungen tragen. Ein Cache, der zweimal dieselbe gespeicherte Seite liefert, wird benannt und lässt sich per Knopf abschalten — auch ein cookie-bewusster Cache verliert seinen Freibrief, sobald er als Verursacher bewiesen ist. Eine fette Warnung ganz oben auf der Einstellungsseite nennt die blockierenden Cache-Plugins beim exakten Namen, acht weitere Seiten-Caches werden namentlich erkannt, und Hoster- oder CDN-Caches werden mit konkretem Kopfzeilen-Befund benannt, den nur der Hoster abschalten kann. Jede Installation muss die Browser-Prüfung einmal erneut ausführen.

Die Browser-Prüfung misst jetzt den Zustand, den sie freigibt. Die alte Einwilligungsebene blockiert bis zur Umschaltung selbst noch Drittinhalte — „0 unbekannte Verbindungen“ wurde also mit ihrer Hilfe gemessen. Ihre Haken werden für die Seitenaufrufe der Prüfung jetzt entfernt, und die Umschaltung verweigert einen Bericht, der nicht so gemessen wurde: jede Installation muss die Prüfung einmal erneut ausführen. Dazu geschlossen: eine Differenz zwischen PHP und Browsern beim Lesen von Adressen, geteilte Anbieter-Domains wie cloudflare.com werden verengt, das Einwilligungsprotokoll bleibt beim Löschen des Plugins erhalten, sofern Sie nichts anderes wünschen, und die Kappung der Richtlinie begrenzt jetzt die ganze Antwort.

Wem die Datei advanced-cache.php gehört, wird jetzt aus der Datei gelesen statt aus den aktiven Plugins geschlossen. Besitzen kann sie nur ein Plugin — und nicht unbedingt eines, das noch läuft: Auf einer echten Website gehörte sie einem deaktivierten Cache Enabler, während ein anderer Cache aktiv war, und der alte Schluss erklärte diese Website für cache-frei, obwohl das Drop-in eines toten Plugins bei jedem Aufruf mitlief. Was sich nicht zuordnen lässt, blockiert die Prüfung jetzt, weil sich seine Harmlosigkeit nicht zeigen lässt.

Ein Seiten-Cache, der die Browser-Prüfung blockiert, lässt sich jetzt mit einem Knopf direkt im geführten Ablauf abschalten. Bisher nannte der Ablauf das verursachende Plugin und schickte den Betreiber in die Plugin-Liste — aber wer dieses Plugin einsetzt, kann nicht wissen, welches seiner Plugins ein Seiten-Cache ist. wpkookies merkt sich genau, was es abgeschaltet hat, und kann es wieder einschalten. Cookie-bewusste Caches wie Surge bleiben erlaubt und werden nie angefasst.

Die angegebene PHP-Anforderung stimmt jetzt. Plugin-Kopf, readme und composer nannten PHP 8.1, drei Klassen brauchen aber seit jeher 8.2 — auf einem 8.1-Server hielt das Plugin mit einem Syntaxfehler an, statt eine verständliche Meldung zu zeigen. Ein neues Release-Gate misst die Anforderung gegen den ausgelieferten Code, damit beides nicht wieder auseinanderläuft. Am Verhalten des Plugins ändert sich nichts.

Die Prüfung leitet den Sondenpfad jetzt aus dem Dienst ab, den sie tatsächlich prüft — nicht aus dem ersten Mitglied seiner Einwilligungsgruppe. Auf einer geteilten Anbieteradresse ist dieses erste Mitglied meist ein anderer Dienst; die Sonde gehörte dann niemandem und kam als unbekannte Fundstelle zurück, die die Prüfung selbst erzeugt hatte.

Die Browser-Prüfung testet Google Ads nicht länger auf einem Pfad, der diesem Dienst nicht gehört. Auf einem Google-Länderhost gehören ihm genau seine zwei Werbe-Endpunkte — die Prüfsonden kamen deshalb als unbekannte Fundstellen zurück, die die Prüfung selbst erzeugt hatte.

Die Browser-Prüfung bindet die angewendete Borlabs-Übernahme jetzt an die Konfiguration, die sie gleich misst. Jede berechtigte Änderung der Dienstliste seit der Übernahme ließ den Lauf sonst neunzig Sekunden laufen und wurde danach abgewiesen — ohne Weg, die Übernahme abzuschließen.

Vervollständigt die automatische Reparatur: Sie ändert die Dienstliste und löste damit die Bindung zwischen einer laufenden Borlabs-Übernahme und ihrem Browser-Nachweis — jeder weitere Lauf wurde abgewiesen. Das Update bindet die Übernahme jetzt neu.

Behebt die automatische Reparatur aus der Vorversion: Die Reparatur war richtig, aber die Datenmigrations-Version wurde nicht angehoben, deshalb lief sie auf einer bestehenden Installation nie. Die zu breite Google-Regel wird jetzt beim Update wirklich verengt.

Eine Härtungsversion nach einer adversarialen Prüfung der beiden Vorgänger. Zwei Befunde konnten eine laufende Website lahmlegen: Eine zu lange Sicherheitsrichtlinie ließ Server die ganze Seite mit einem Fehler beantworten, und die späte Neusetzung berechnete die Richtlinie neu, statt die gesendete zu wiederholen — zwei verschiedene eigene Richtlinien konnten eingewilligte Inhalte blockieren. Die Einrichtung eines Google-Endpunkts trägt jetzt den gemessenen Host statt der ganzen Domain, die Werbung, Karten und reCAPTCHA zu einer einzigen Entscheidung verband. Bestehende Installationen werden automatisch korrigiert.

Eine Fundstelle geht nicht mehr zwischen zwei Maßstäben verloren: Der Browser meldete www.google.com/ccm/collect als unbekannt, während die Fundstellen-Liste sie für eingerichtet hielt — der Lauf nannte eine Zahl und bot nichts an. Diese Adresse, Googles Einwilligungs-Modus, wird jetzt als Google Ads erkannt und lässt sich wie gewohnt mit einem Klick einrichten. Und läuft die WordPress-Anmeldung während einer Prüfung ab, sagt die Prüfung das, statt zum Leeren von Caches zu schicken.

Ein Sicherheits-Plugin konnte die erzwungene Sicherheitsrichtlinie von wpkookies unbemerkt ersetzen — auf solchen Websites blieb der Ladeweg import() ungeschützt. Die Richtlinie wird jetzt nach allen anderen erneut gesetzt und tritt neben die fremde, statt sie zu verdrängen. Außerdem gilt eine Richtlinie im Nur-Melden-Modus nicht mehr als Blockierbeleg, und fehlt die Richtlinie ganz, nennt die Prüfung die Ursache statt elf Folgefehler.

Ein blockiertes Analyse- oder Tag-Manager-Skript erzeugt keinen Einwilligungskasten mehr. Es hat keine Stelle auf der Seite, deshalb landete der Kasten über Logo und Navigation und schob die ganze Website nach unten. Solche Skripte werden jetzt still blockiert; die Entscheidung bleibt im Banner. Sichtbare Einbettungen behalten ihren Platzhalter dort, wo der Inhalt steht.

Der Katalog erkennt jetzt 36 Anbieterdienste: Microsoft Advertising kommt hinzu, Hotjar, Pinterest und TikTok erhalten fehlende Adressen — auch auf bestehenden Installationen. Anonyme CDN-Hosts bleiben bewusst ohne Eintrag, weil niemand ihren Anbieter oder Zweck benennen kann. Die Liste auf der Startseite wird aus dem ausgelieferten Katalog erzeugt und kann deshalb nicht veralten.

Härtungen aus dem Audit: Der Nachweisspeicher lässt sich nicht mehr durch eine Flut lahmlegen, Einmal-Freigaben können die Datenbank nicht mehr überschwemmen, und ein fremder Filter wird nicht mehr zu dauerhafter Konfiguration. Prozent-kodierte Adressen überstehen das Prüfwerkzeug, und ein gestoppter Migrationslauf sieht nicht mehr aus wie ein laufender.

Zwei Sicherheitskorrekturen: Ein Rückrollen vor der Umschaltung schaltete den öffentlichen Schutz ab, und WebSocket-Verbindungen wurden nie blockiert, obwohl die Dokumentation es zusicherte. Matomo Cloud wird nicht mehr als selbst gehostet mit falschem Anbieter eingerichtet. Der Prüfbereich widerruft das grüne „Geprüft“ jetzt sofort, wenn ein Lauf scheitert, und nennt den nächsten Schritt direkt über dem Knopf.

Das Google-Signals-Beacon von Google Analytics 4 wird als Standard-Dienst „Google Ads und DoubleClick“ erkannt und lässt sich mit einem Klick einrichten — einschließlich der länderabhängigen Google-Adresse. Die Fundstelle erklärt zusätzlich, dass das Beacon eine GA4-Einstellung ist: Wer kein Remarketing will, schaltet Google-Signale in Google Analytics ab.

Die Fundstellen aus dem Browser-Test erscheinen jetzt ohne Neuladen direkt auf der laufenden Seite. Erkannte, aber nie eingerichtete Dienste — etwa ein Tag-Manager-Skript — werden ebenfalls zu Fundstellen mit Ein-Klick-Einrichtung. Jede Prüfung protokolliert, was sie wirklich gesehen hat; eine fehlgeschlagene Übergabe behauptet nichts mehr.

Datenreste in der Datenbank gelten nicht mehr als Installation: Borlabs-Optionen und -Tabellen überleben eine Deinstallation, wurden aber als „Borlabs gefunden" gemeldet — auf Websites, in deren Plugin-Liste Borlabs gar nicht vorkommt. Reste werden jetzt als Reste benannt, und die geführte Übernahme bleibt dort ausgeblendet.

Findet der Browser-Test eine externe Adresse ohne eingerichteten Dienst, bleibt der Fund erhalten und lässt sich direkt einrichten — bei erkannten Anbietern mit einem Knopf, sonst über ein kleines Formular, das jede fehlende Pflichtangabe benennt. Außerdem erscheint die geführte Borlabs-Übernahme nur noch dort, wo es tatsächlich etwas zu übernehmen gibt.

Ein mit einem Fehler gestoppter Migrationslauf gibt sich nicht länger als laufender aus: statt Fortschrittsanzeiger und „Der Vorgang läuft weiter" steht dort jetzt, dass er gestoppt ist. Außerdem wird der Schalter für den öffentlichen Betrieb einheitlich gelesen — fehlte die Einstellung, hielten Frontend und Guardian die Website für unterschiedlich geschaltet.

Der zweite Durchgang des Browser-Tests wird jetzt erklärt. Richtet das Plugin einen eindeutig erkannten Dienst selbst ein, ändert sich die Konfiguration und die bisherige Messung gilt nicht mehr — der Test misst genau ein zweites Mal. Die Begründung kommt jetzt vom Server, überlebt das Neuladen und nennt den eingerichteten Dienst. An der Prüfmechanik ändert sich nichts.

Der eval-Kompatibilitätsschutz erkennt jetzt auch Smart Slider 3 Pro, das als eigenständiges Paket ausgeliefert wird. Auf solchen Websites wurde der Schutz bisher nie geladen, sodass der wirkungslose leere eval-Aufruf von Smart Slider die Schutzprüfung mit einer unsafe-eval-Meldung scheitern ließ. Die Meldung nennt jetzt Seite und Skript; „unsafe-eval“ bleibt verboten.

Der eng begrenzte eval-Kompatibilitätsschutz wird nur noch bei tatsächlich aktivem Smart Slider geladen. Andere Websites und automatische Browser-Prüfungen werden nicht mehr abgefangen; ausführbarer eval-Code bleibt durch die strenge CSP blockiert.

Nichtleere eval-Aufrufe werden vom Kompatibilitätsschutz selbst abgewiesen, niemals ausgeführt und für Guardian protokolliert. Nur der exakt leere Smart-Slider-Aufruf bleibt als wirkungslose Operation zulässig.

Der Schutz für exakt leere eval-Aufrufe bleibt über den gesamten Seitenlauf aktiv, weil Smart Slider seine leeren Callbacks erst nach DOMContentLoaded ausführt. Nichtleere Codeausführung bleibt durch die CSP gesperrt.

Der eng begrenzte Schutz für leere eval-Aufrufe wird jetzt vor allen Frontend-Skripten ausgegeben. Dadurch erfasst er auch Bibliotheken, die eval beim Laden zwischenspeichern; nichtleere Codeausführung bleibt durch die CSP verboten.

Leere eval-Aufrufe werden während des frühen Seitenstarts vorübergehend als wirkungslos behandelt. Leere Smart-Slider-Callbacks verletzen die CSP damit nicht mehr; nichtleere Codeausführung bleibt verboten und erkennbar.

Die CSP-sichere Smart-Slider-Korrektur erfasst jetzt auch Initialisierungen, die direkt im WordPress-Kopfbereich ausgegeben werden. Der eng begrenzte Ausgabepuffer wird innerhalb desselben wp_head-Durchlaufs vollständig geschlossen.

Leere Smart-Slider-Callbacks werden jetzt CSP-sicher behandelt, ohne unsafe-eval freizugeben. Der Guardian erkennt außerdem verbleibende verbotene eval-Versuche und stoppt, statt einen irreführend grünen Bericht zu speichern.

Die Beanstandungen der WordPress.org-Prüfung sind behoben: gerenderte Shortcode-Ausgaben werden bereinigt, WordPress verwaltet den Ausgabepuffer, Cookie-Namen aus Anfragen werden streng geprüft und optionale externe Anbieter sind vollständig dokumentiert.

Die Guardian-Berichtsprüfung erweitert jedes konkrete Prüfziel jetzt über die tatsächlich konfigurierte technische Einwilligungsgruppe. Dadurch werden auch Dienste korrekt gemeinsam geprüft, die erst über eine weitere gemeinsame Anbieter-Domain gekoppelt sind; unvollständige Gruppen bleiben ungültig.

Die Guardian-Berichtsprüfung verwendet jetzt dieselben vollständigen Einwilligungsgruppen wie das Frontend. Technisch gekoppelte Dienste mit überlappenden Anbieter-Domains wie Google Maps und reCAPTCHA führen nicht mehr zur Ablehnung eines korrekten Berichts; unvollständige Gruppen bleiben gesperrt.

Der Guardian trennt den echten Erstbesuch jetzt korrekt vom später absichtlich gespeicherten Ablehnungszustand. Ein nach der Ablehnung verborgenes Banner wird nicht mehr fälschlich als unvollständige Erstbesuchs-Blockierung bewertet; sämtliche Dienst- und Ladewegprüfungen bleiben streng aktiv.

Ältere geführte Borlabs-Migrationen werden jetzt auch dann sicher nachgebessert, wenn ihre interne Profilmarkierung fehlt. Die Erweiterung greift nur bei eindeutiger Borlabs-Herkunft und eindeutiger Katalogzuordnung; individuelle und mehrdeutige Dienste bleiben unverändert.

Datenreparaturen besitzen jetzt eine eigene, einmalig ausgeführte Versionsmarke. Dadurch werden sicherheitsrelevante Dienstkorrekturen auch auf bereits aktuellen Datenbankschemata ausgeführt; bestehende 1.5.27-Migrationen erhalten die fehlenden Google-Maps-Laufzeit-Domains automatisch.

Die geführte Borlabs-Migration ergänzt bei eindeutig erkannten importierten Diensten nun die anbieterspezifischen Laufzeit-Domains. Bereits importierte Standarddienste werden sicher nachgebessert; dadurch erhält Google Maps beispielsweise maps.googleapis.com, ohne individuelle Regeln des Betreibers zu verändern.

Der Browser-Test wiederholt vorübergehende HTTP-429/503-Sperren von Sicherheitsplugins automatisch, vermeidet künstliche lokale Anfragebursts und benötigt weniger überflüssige Seitenaufrufe.

Doctify-Bewertungswidgets und ihre Skripte werden jetzt automatisch als ein externer Mediendienst erkannt, mit vollständigen Anbieterangaben vorbereitet und bis zur Einwilligung blockiert.

Der Browser-Test erkennt einen aktiven Surge-Seitencache jetzt als unterstützten, cookie-abhängigen Cache und prüft die Website bei eingeschaltetem Cache. Unbekannte Cache-Drop-ins und nicht unterstützte Cache-Plugins bleiben weiterhin sicher blockiert.

Selbst gehostetes Matomo, das erst beim Aufbau der geschützten Vorschau durch ein Theme oder Plugin sichtbar wird, wird jetzt anhand seines eindeutigen Skriptpfads automatisch erkannt. Der gefundene Host wird als Statistikdienst des Websitebetreibers ergänzt und der Test startet neu; jede andere unbekannte Adresse bleibt gesperrt.

Bereits aktive und eindeutig bekannte Borlabs-Standarddienste werden jetzt automatisch übernommen. Normale WordPress-Nutzer müssen keine technischen Anbieter- oder Domainlisten mehr bestätigen; nur unbekannte Eigenlösungen führen zu einer verständlichen Rückfrage.

Der automatische Browser-Test zeigt jetzt jeden Schritt, den geprüften Dienst, die verstrichene Zeit und eine laufend berechnete Restzeit. Mehrfache Seitenaufrufe werden erklärt und flackern nicht mehr sichtbar. Nach einem erfolgreichen Migrationstest wechselt der Assistent zuverlässig zur Umschaltung, statt den Test erneut zu starten.

Eingebettete Inhalte auf gemeinsam genutzten Anbieter-Domains werden während der Borlabs-Migration anhand ihres URL-Pfads erkannt. So wird www.google.com/maps/embed automatisch als Google Maps mit den lokalen Katalogdaten übernommen, während mehrdeutige allgemeine Google-Adressen weiterhin zur Prüfung angehalten werden.

Der Browser-Test wertet den bloßen WordPress-Schalter WP_CACHE nicht mehr als Beweis für einen aktiven Seiten-Cache. Ein echtes advanced-cache.php-Drop-in und bekannte aktive Cache-Plugins bleiben blockierend; geprüft wird weiterhin das tatsächliche Antwort- und Schutzverhalten der Website.

Der bestätigte vollständige Reset prüft die Bereinigung, vergibt eine neue Installationsidentität und leert erreichbare Caches. Gemeinsame Daten bleiben bei parallelem Legacy- und Directory-Paket geschützt; eine Netzwerkaktivierung initialisiert bestehende und neue Multisite-Websites. PageSpeed-Schutzmarker und no-transform verbessern die Gatekeeper-Kompatibilität, ohne jede Optimiererkonfiguration zu garantieren.

Beim Löschen des Plugins entfernt WordPress jetzt sämtliche WPKookies-Daten einschließlich Dienstliste, Migrationszustand, Snapshots, Aufgaben, Berechtigungen und Nachweistabelle. Bereits übernommene Altdaten lassen sich nach ausdrücklicher Bestätigung direkt auf den Zustand einer neuen Installation zurücksetzen.

Der Gatekeeper wird von PageSpeed-Umschreibungen und Skriptverzögerungen ausgenommen, ohne die strenge Sicherheitsrichtlinie mit unsafe-eval aufzuweichen.

Die Borlabs-Migration erkennt bekannte Anbieter wie SoundCloud auch aus allgemeinen Importdaten, vermeidet doppelte Einwilligungen und prüft Freigaben ohne künstliche Drittanbieter-Aufrufe.

Cookie-basierte Seiten-Caches wie Surge werden jetzt unterstützt: Jede Einwilligungsstufe erhält ihre eigene, korrekte Cache-Variante – das Seiten-Caching bleibt aktiv und die Website schnell.

Der Browser-Test wendet eine bereits geprüfte sichere Konfiguration automatisch an und startet danach ohne versteckten Zwischenschritt.

Die Meldung zu zurückgehaltenen Code-, CSS- und Regex-Angaben ist jetzt klar als nicht blockierender Sicherheitshinweis formuliert.

Auch direkt in Seiteninhalten erkannte Yumpu-Einbettungen werden jetzt vollständig mit Anbieterangaben vorbereitet.

Die Yumpu-Übernahme erhält jetzt auch dann eine Speicherdauer, wenn der Borlabs-Export dieses Feld leer lässt.

Yumpu wird bei der Migration jetzt als eigener Dienst erkannt und mit Anbieter- und Datenschutzangaben vorbereitet.

Der automatische Test erklärt jetzt verständlich, wenn WordPress statt der erwarteten JSON-Antwort eine HTML-Fehlerseite zurückgibt.

Versionsnummern, Download-Links und öffentliche strukturierte Daten bleiben jetzt überall auf der Website und in den Release-Paketen synchron.

Der Migrationsassistent erklärt erkannte Seiten-Caches jetzt verständlich und nennt klar die nächsten Schritte für WordPress, Hosting und CDN.

Das Paket für das offizielle WordPress-Verzeichnis wird vor der Veröffentlichung strenger geprüft. Die Wiederherstellung nach einer Migration funktioniert nun auch auf Test- und Staging-Websites, die über eine IP-Adresse erreichbar sind.

Die Ersteinrichtung ist jetzt übersichtlicher, zusammengehörige Dienste werden verständlich gebündelt und bekannte Anbieter zuverlässiger erkannt. Automatische Datenschutzprüfungen begleiten die Konfiguration bis zur Freigabe.

WPKookies ist jetzt in acht europäischen Sprachen verfügbar. Besucher sehen Einwilligungen und Datenschutzeinstellungen in der Sprache der Website, während Betreiber auch die Verwaltung und Dienstangaben passend übersetzen können.

Freigaben für bekannte Inhalte wie YouTube können nun wahlweise einmalig oder für alle Unterseiten erteilt werden. Die aktuelle Auswahl lässt sich in den Datenschutzeinstellungen prüfen, widerrufen und als verständliche Datei herunterladen.

Die geschützte Vorschau und der automatische Website-Test arbeiten auf umfangreichen WordPress-Websites jetzt deutlich schneller und zuverlässiger.

Bekannte Video- und Social-Media-Inhalte werden verständlicher erkannt und lassen sich gezielt freigeben. Der Einstellungen-Schalter erscheint jetzt kompakt als WPKookies-Logo.

Der automatische Website-Test im Migrationsassistenten arbeitet in weiteren WordPress-Umgebungen zuverlässiger.

Auch Websites mit ausschließlich notwendigen Diensten können die geführte Migration vollständig abschließen. Ungeeignete Exportdateien werden verständlicher erklärt.

Das Installationspaket wurde für eine zuverlässige Erkennung und Aktivierung auf WordPress-Servern verbessert.

Eingaben werden strenger geprüft. Die automatisierten Qualitätsprüfungen wurden deutlich erweitert.

Die Kontrolle externer Inhalte, einmalige Freigaben und der geführte Migrationsablauf wurden umfassend erweitert.

Einwilligungsänderungen und ihre automatischen Prüfungen wurden weiter abgesichert.

Nach einem erfolgreichen Website-Test kann die Umschaltung nun ohne Unterbrechung abgeschlossen werden. Fehlende Schritte werden klar benannt.

Verzögert geladene Inhalte können nach einer Ablehnung wieder zuverlässig freigegeben werden.

Abgelehnte externe Inhalte lassen sich direkt über die Einstellungen erneut erlauben, ohne die Seite neu zu laden.

Zusammengehörige Dienste werden bei der Migration sauber gebündelt und nicht doppelt angezeigt.

Externe Einbettungen in Seiteninhalten werden während der Migration zusätzlich erkannt und zur Prüfung vorgeschlagen.

Die Übernahme aus aktuellen Borlabs-Installationen wurde erweitert und übersichtlicher auf die wirklich verwendeten Dienste begrenzt.

Die Migration konzentriert sich genauer auf tatsächlich benötigte Dienste und vermeidet irrelevante Einträge.

Installierte Borlabs-Versionen werden zuverlässiger erkannt. Die Umschaltung bleibt bei unvollständigen Daten sicher gesperrt.

Ein geführter Migrationsassistent mit verständlicher Prüfung, automatischem Website-Test, Umschaltung und Rückweg wurde eingeführt.

Aktualisierte Bedienfunktionen werden auch bei aktiven Website-Caches zuverlässig ausgeliefert.

Der Einstellungen-Schalter funktioniert robuster mit unterschiedlichen WordPress-Themes und Optimierungen.

Der Zugriff auf die Datenschutzeinstellungen wurde nochmals stabilisiert.

Der Einstellungen-Dialog kann sich bei Änderungen durch Themes oder Caches selbstständig wiederherstellen.

Die geführte Migration ist klarer benannt. Die Entfernung des Plugins wurde auf weiteren Hosting-Umgebungen verbessert.

Die Administration wurde zu einem verständlichen Migrationsassistenten mit fünf klaren Schritten umgestaltet.

Erste Veröffentlichung mit lokaler Einwilligungsverwaltung, Auswahl einzelner Dienste, Inhaltsblockierung, Widerruf und Migrationsfunktionen.