Les nouveautés de wpkookies.

Kookies Consent figure désormais dans le répertoire officiel des extensions de WordPress.org. Après l’analyse automatique, la relecture humaine l’a également validé, si bien que l’extension se trouve là où les sites WordPress installent et mettent à jour leurs extensions. Pour les exploitants, c’est surtout le chemin qui change. Rechercher, installer et mettre à jour se fait maintenant directement depuis l’administration WordPress, sans fichier ZIP et sans détour. Cherchez-le sous le nom Kookies Consent. Tous les boutons de téléchargement de ce site mènent désormais directement à la page de l’extension sur WordPress.org.

WordPress.org a refusé le téléversement de la 1.5.69 : « Tested up to: 7.0 < 7.1 ». Une extension dont le readme reste en retard sur la version actuelle de WordPress n’apparaît pas dans les recherches. L’en-tête indique désormais 7.1 — confirmé de façon indépendante plutôt que supposé : la vérification de publication a interrogé api.wordpress.org et obtenu 7.1. La particularité de cette valeur : elle ne vieillit pas parce que nous changeons quelque chose, mais parce que WordPress publie une version. Aucune barrière de qualité de ce projet ne l’avait jamais regardée, dans un fichier qui décide de l’acceptation ou du refus. Désormais la vérification demande elle-même la version actuelle de WordPress et refuse une publication en retard ; si l’interface est injoignable, elle le dit clairement au lieu d’annoncer un contrôle qui n’a pas eu lieu. Le comportement de l’extension ne change pas.

La recherche dans le code livrée en 1.5.66 a trouvé 17 prestataires sur un vrai site client comptant 36 extensions actives — et le test navigateur n’en a rencontré aucun sur douze pages. Sous forme de liste plate d’entrées équivalentes, l’écran exigeait dix-sept décisions que personne ne pouvait prendre ; les prendre aurait ajouté dix-sept services à la bannière de consentement que le site ne charge jamais. C’est désormais la mesure qui décide : ce que le test a réellement rencontré et bloqué figure en haut comme tâche, avec la date de la mesure sur laquelle repose l’affirmation. Tout le reste se replie en une seule ligne qui énonce ses propres limites — le test visite un nombre limité de pages, et ce qui se trouve uniquement derrière un formulaire lui échappe. L’attribution passe par le service reconnu, jamais par le nom d’hôte : www.google.com appartient à la fois à Google Maps et à reCAPTCHA, et seul le chemin les distingue. Pas de pastille verte sans mesure, ni pour une recherche interrompue ou périmée. Corrigé au passage : le bouton de recherche purement diagnostique détruisait le rapport de vérification validé du site, un constat de cache disparaissait après chaque mise à jour au lieu de disparaître seulement quand la question changeait, et un service configuré depuis la section voisine restait proposé et affirmait ensuite le contraire de ce qui avait été mesuré.

La vérification du navigateur échouait sur toutes les installations en 1.5.66 et 1.5.67. Elle allait jusqu’au bout puis était refusée avec « la vérification n’a pas fourni toutes les preuves de pages et de services demandées » — sur un site client, juste après la mise à jour. La cause : un même nombre conservé à deux endroits. La 1.5.66 a porté le parcours de cinq pages internes à douze, tandis que le serveur qui valide le rapport gardait sa propre copie à cinq et refuse tout rapport dont le compte diffère du sien. Ce nombre ne vit désormais que sur le serveur : il le publie et le navigateur le lit, de sorte que les deux ne peuvent plus diverger. Un test les compare dans les deux langages, car rien d’autre ne pouvait le voir : la suite navigateur travaille sur des fixtures, les tests PHP construisent leurs rapports à partir de la constante du serveur et s’accordent donc avec eux-mêmes, et le test de bout en bout ne lance jamais de vérification réelle.

Un client a mis à jour, ouvert l’écran des réglages et vu un avertissement rouge : un cache hors WordPress sert des pages enregistrées, demandez à votre hébergeur de le désactiver. L’avertissement était faux. Il mesurait si la page d’accueil est enregistrée quelque part — ce qui est vrai de presque tous les hébergements, et c’est le cas inoffensif : la page enregistrée est la page anonyme, où tout est bloqué de toute façon. Ce qui casse réellement le consentement, c’est un cache qui sert cette même page enregistrée à un visiteur porteur d’un cookie de consentement. La vérification réchauffe désormais le cache, confirme que la page est bien réutilisée, puis la redemande avec un cookie de consentement. Un cache qui répond depuis son stock est signalé ; un cache qui répond fraîchement ne l’est pas, et rien ne s’affiche. Quand il y a quelque chose à signaler, le texte dit ce qui ne va pas et demande ce qui aide vraiment — laisser passer vers WordPress les pages portant le cookie de consentement — au lieu d’exiger la désactivation du cache.

Un site client a perdu sa liste de services sans pouvoir la récupérer : l’extension dont il avait été migré n’existait plus. La reconstruire à partir de la vérification du navigateur n’a donné que deux fournisseurs — cette vérification visite quelques pages et ne peut signaler que ce que ces pages chargent. WPKookies parcourt désormais aussi le code installé : les extensions actives, les extensions obligatoires, le thème actif et son thème parent, à la recherche des 88 domaines de fournisseurs que connaît son catalogue. Chaque fournisseur trouvé se configure en un bouton. Un résultat est décrit pour ce qu’il est : la preuve que ce code peut contacter le fournisseur, pas qu’il est chargé sur chaque page. Les liens et les boutons de partage ne comptent plus comme des intégrations, les listes de fournisseurs des autres extensions de consentement sont ignorées, et une recherche interrompue indique la part du site réellement lue au lieu de conclure que tout va bien.

Une installation en production, entièrement migrée, a été effacée par un seul clic sur « réinitialiser l’installation ». La réinitialisation se trouve désormais derrière les réglages techniques et non plus entre les deux blocs que l’exploitant utilise ; elle indique la perte mesurée de ce site précis avant de pouvoir être déclenchée : le nombre d’entrées de la liste des services, la présence d’une reprise achevée et d’une sauvegarde de retour, et le nombre réel de lignes du journal de consentement — compté, pas supposé. Tout ce qui dépasse une installation neuve exige une seconde confirmation explicite, imposée par le serveur. Deux autres façons de perdre les mêmes données sont fermées : une liste de services vide est refusée, et l’éditeur affiche l’état enregistré et non une vue filtrée qui supprimerait les services masqués. Sur un multisite, l’acceptation de suppression est lue par site. Enfin, après une vérification réussie, l’écran dit qu’il n’y a rien à faire — mais seul le serveur peut déclarer un site protégé, car la vérification du navigateur ne prouve qu’un contrôle sur six.

La vérité du cache remplace l’hypothèse. Avant chaque vérification du navigateur, l’extension mesure désormais si le site sert vraiment des pages fraîches : la même adresse d’aperçu est chargée deux fois et doit porter deux jetons uniques différents. Un cache pris à servir deux fois la même page enregistrée est nommé et peut être désactivé en un clic — même un cache sensible aux cookies perd son passe-droit une fois prouvé responsable. Un avertissement en gras en haut de l’écran des réglages nomme les extensions de cache bloquantes, huit caches de pages supplémentaires sont reconnus par leur nom, et les caches d’hébergeur ou de CDN sont identifiés avec des preuves d’en-têtes concrètes que seul l’hébergeur peut traiter. Chaque installation doit relancer la vérification une fois.

La vérification du navigateur mesure enfin ce qu’elle certifie. L’ancienne couche de consentement continue de bloquer des contenus tiers jusqu’à la bascule ; « 0 connexion inconnue » était donc mesuré avec son aide. Ses hooks sont désormais retirés pour les pages chargées par la vérification, et la bascule refuse un rapport qui n’a pas été mesuré ainsi — chaque installation doit relancer la vérification une fois. Cette version corrige aussi une divergence d’analyse des URL entre PHP et les navigateurs, restreint les domaines partagés comme cloudflare.com, conserve votre journal de consentement lors de la suppression de l’extension sauf demande contraire, et limite l’en-tête de politique sur l’ensemble de la réponse.

Le propriétaire du fichier advanced-cache.php est désormais lu dans le fichier lui-même, au lieu d’être déduit des extensions actives. Un seul plugin peut le posséder, et pas nécessairement un plugin encore actif : sur un site réel, le fichier appartenait à un Cache Enabler désactivé alors qu’un autre cache fonctionnait, et l’ancienne déduction déclarait ce site sans cache pendant que le fichier d’une extension morte s’exécutait à chaque requête. Tout fichier non attribuable bloque désormais la vérification, faute de pouvoir être déclaré inoffensif.

Un cache de pages qui bloque la vérification par le navigateur se désactive désormais d’un seul bouton dans le parcours guidé. Jusqu’ici, le processus nommait l’extension en cause et renvoyait l’exploitant vers la liste des extensions — or les personnes visées par ce plugin ne savent pas laquelle de leurs extensions est un cache de pages. wpkookies retient exactement ce qu’il a désactivé et peut le réactiver. Les caches tenant compte des cookies, comme Surge, restent autorisés et ne sont jamais touchés.

L’exigence PHP annoncée correspond enfin à la réalité. Toutes les déclarations indiquaient PHP 8.1, alors que trois classes réclament 8.2 depuis toujours : sur un hébergement en 8.1, le plugin s’arrêtait sur une erreur d’analyse au lieu d’un message utile. Un nouveau contrôle de publication mesure l’exigence par rapport au code livré.

La vérification déduit désormais le chemin de sondage du service réellement testé, et non du premier membre de son groupe de consentement. Sur une origine partagée, ce premier membre est souvent un autre service : la sonde n’appartenait alors à personne et revenait comme une découverte inconnue inventée par la vérification elle-même.

La vérification par le navigateur ne sonde plus Google Ads sur un chemin qui n’appartient pas à ce service. Sur un hôte Google national, il ne possède que ses deux points de terminaison publicitaires ; les sondes revenaient donc comme des découvertes inconnues que la vérification avait elle-même inventées.

La vérification par le navigateur lie désormais la reprise Borlabs appliquée à la configuration qu’elle s’apprête à mesurer. Tout changement légitime de la liste des services depuis la reprise laissait sinon l’exécution durer quatre-vingt-dix secondes avant d’être refusée, sans moyen d’achever la migration.

Achève la réparation automatique : celle-ci modifie la liste des services, ce qui rompait le lien entre une reprise Borlabs en cours et ses preuves de navigateur, si bien que chaque exécution suivante était refusée. La mise à jour rétablit désormais ce lien.

Corrige la réparation automatique livrée dans la version précédente : la réparation était correcte, mais la version de migration des données n’avait pas été relevée, si bien qu’elle ne s’exécutait jamais sur une installation existante. La règle Google trop large est désormais réellement resserrée lors de la mise à jour.

Une version de durcissement après une revue adversariale des deux précédentes. Deux constats pouvaient mettre un site hors service : une politique de sécurité trop longue faisait répondre les serveurs par une erreur pour toute la page, et la réaffirmation tardive recalculait la politique au lieu de répéter celle qui avait été envoyée, si bien que deux politiques différentes pouvaient bloquer des contenus consentis. La configuration d’un point de terminaison Google retient désormais l’hôte mesuré plutôt que le domaine entier, qui liait publicité, cartes et reCAPTCHA en une seule décision. Les installations existantes sont corrigées automatiquement.

Une découverte ne se perd plus entre deux méthodes de correspondance : le navigateur signalait www.google.com/ccm/collect comme inconnue tandis que la liste la considérait déjà configurée, si bien que la vérification annonçait un nombre sans rien proposer. Cette adresse — le mode de consentement de Google — est désormais reconnue comme Google Ads, avec la configuration en un clic habituelle. Et si la session WordPress expire pendant une vérification, celle-ci le dit au lieu de vous envoyer vider des caches.

Une extension de sécurité pouvait remplacer sans bruit la politique de sécurité appliquée par wpkookies — sur ces sites, la voie de chargement import() restait sans protection. La politique est désormais réaffirmée après toutes les autres et vient s’ajouter à celle de l’autre extension au lieu de l’évincer. Une politique en mode signalement seul ne vaut plus comme preuve de blocage, et lorsque la politique manque totalement, la vérification nomme la cause au lieu d’énumérer onze erreurs consécutives.

Un script d’analyse ou de gestionnaire de balises bloqué ne produit plus d’encadré de consentement. Il n’a aucune place sur la page, si bien que l’encadré se retrouvait au-dessus du logo et de la navigation et repoussait tout le site vers le bas. Ces scripts sont désormais bloqués silencieusement ; le choix reste dans la bannière. Les intégrations visibles conservent leur espace réservé là où se trouve le contenu.

Le catalogue reconnaît désormais 36 services de fournisseurs : Microsoft Advertising s’y ajoute, et Hotjar, Pinterest et TikTok reçoivent les adresses qui leur manquaient — installations existantes comprises. Les hôtes CDN anonymes restent volontairement sans entrée, car personne ne peut en indiquer le fournisseur ni la finalité. La liste sur la page d’accueil est générée à partir du catalogue livré et ne peut donc pas devenir obsolète.

Renforcements issus de l’audit : le registre de preuves ne peut plus être bloqué par un afflux, les autorisations uniques ne peuvent plus saturer la base, et un filtre tiers ne devient plus une configuration permanente. Les adresses encodées en pourcentage survivent à l’outil de vérification, et une migration arrêtée ne ressemble plus à une migration en cours.

Deux correctifs de sécurité : un retour arrière effectué avant la bascule désactivait la protection publique, et les connexions WebSocket n’étaient jamais bloquées alors que la documentation l’assurait. Matomo Cloud n’est plus configuré comme auto-hébergé avec le mauvais fournisseur. La zone de vérification retire désormais le « vérifié » vert dès qu’une exécution échoue et indique l’étape suivante juste au-dessus du bouton qui l’exécute.

La balise d’audiences « Google Signals » de Google Analytics 4 est désormais reconnue comme le service standard « Google Ads et DoubleClick » et se configure en un clic — y compris l’hôte Google propre au pays. Le résultat explique aussi que la balise est un réglage de la propriété GA4 : qui ne veut pas de remarketing désactive simplement les signaux Google dans Google Analytics.

Les éléments trouvés par le test du navigateur apparaissent désormais sur la page en cours, sans rechargement, et les services reconnus mais jamais configurés — un extrait Tag Manager, par exemple — deviennent eux aussi des résultats, avec la configuration en un clic. Chaque exécution consigne ce qu’elle a réellement vu ; une remise échouée ne prétend plus que les résultats sont disponibles.

Les données résiduelles en base ne comptent plus comme une installation : les options et tables Borlabs survivent à une désinstallation mais étaient signalées comme « Borlabs trouvé », sur des sites dont la liste d’extensions ne contient pas Borlabs. Les résidus sont désormais nommés comme tels et la reprise guidée y reste masquée.

Lorsque le test du navigateur trouve une adresse externe sans service configuré, le résultat est conservé et peut être configuré sur place : d’un bouton pour les fournisseurs reconnus, sinon via un petit formulaire qui nomme chaque mention obligatoire manquante. La reprise guidée de Borlabs n’apparaît plus que là où il y a effectivement quelque chose à reprendre.

Une migration arrêtée sur une erreur ne se présente plus comme une migration en cours : au lieu de l’indicateur d’activité et de « l’opération se poursuit », elle indique désormais qu’elle est arrêtée. Le commutateur du mode public est en outre lu de manière uniforme : si le réglage manquait, le frontend et Guardian décrivaient le site différemment.

Le deuxième passage du test du navigateur est désormais expliqué. Lorsque l’extension configure elle-même un service reconnu sans ambiguïté, la configuration change et la mesure précédente ne s’applique plus : le test mesure donc exactement une fois de plus. La raison provient maintenant du serveur, survit au rechargement et nomme le service ajouté. La mécanique du test reste inchangée.

La protection de compatibilité eval reconnaît désormais aussi Smart Slider 3 Pro, livré comme extension distincte. Sur ces sites, la protection n’était jamais chargée et l’appel eval vide et inoffensif de Smart Slider faisait échouer le test de protection avec un message unsafe-eval. Le message indique maintenant la page et le script concernés ; « unsafe-eval » reste interdit.

La protection de compatibilité eval strictement limitée ne se charge désormais que lorsque Smart Slider est réellement actif. Les autres sites et les tests automatisés ne sont plus interceptés ; le code eval exécutable reste bloqué par la CSP stricte.

La protection de compatibilité rejette désormais elle-même toute entrée eval non vide, ne l’exécute jamais et consigne la tentative pour Guardian. Seule l’opération exactement vide de Smart Slider reste acceptée.

La protection des appels eval exactement vides reste désormais active pendant toute la durée de la page, car Smart Slider exécute ses callbacks vides après DOMContentLoaded. Le code non vide reste bloqué par la CSP.

La protection limitée des appels eval vides s’exécute désormais avant tous les scripts frontaux. Elle couvre ainsi les bibliothèques qui mémorisent eval au démarrage, tandis que l’exécution de code non vide reste bloquée par la CSP.

Les appels eval vides sont temporairement traités comme l’opération sans effet qu’ils représentent au démarrage de la page. Les callbacks Smart Slider vides ne violent plus la CSP, tandis que l’exécution de code non vide reste interdite et détectable.

La correction CSP de Smart Slider couvre désormais aussi les initialisations écrites directement dans l’en-tête WordPress. Son tampon de sortie ciblé est entièrement fermé pendant la même action wp_head.

Les callbacks Smart Slider vides sont désormais compatibles avec la CSP sans autoriser unsafe-eval. Le Guardian détecte aussi les tentatives eval interdites restantes et s’arrête au lieu d’enregistrer un rapport vert trompeur.

Les remarques de la revue WordPress.org ont été corrigées : la sortie des shortcodes est nettoyée, la mise en mémoire tampon est gérée par WordPress, les noms de cookies reçus sont strictement validés et les fournisseurs externes facultatifs sont documentés.

La validation du rapport Guardian étend désormais chaque cible de test concrète au groupe de consentement technique réellement configuré. Les services liés indirectement par un autre domaine fournisseur partagé sont ainsi contrôlés ensemble correctement ; les groupes incomplets restent invalides.

La validation du rapport Guardian utilise désormais les mêmes groupes de consentement complets que l’interface publique. Les services techniquement liés avec des domaines fournisseur qui se chevauchent, comme Google Maps et reCAPTCHA, ne font plus rejeter un rapport correct ; les groupes incomplets restent bloqués.

Le Guardian évalue désormais la visibilité de la bannière uniquement lors de la véritable première visite, et non après un refus volontairement enregistré. Tous les contrôles stricts de blocage des services et des chemins de chargement du navigateur restent actifs.

Les anciennes migrations guidées depuis Borlabs sont désormais corrigées même si leur marqueur interne de profil d’importation est absent. La correction exige une provenance Borlabs explicite et une correspondance de catalogue sans ambiguïté ; les services personnalisés et ambigus restent inchangés.

Les corrections de données disposent désormais de leur propre version de migration exécutée une seule fois. Les installations existantes reçoivent ainsi les corrections de service liées à la sécurité même lorsque leur schéma de base de données est déjà à jour, notamment les origines d’exécution Google Maps manquantes après une migration 1.5.27.

Les migrations guidées depuis Borlabs ajoutent désormais les origines d’exécution propres au fournisseur aux services importés reconnus sans ambiguïté. Les services standard existants sont corrigés en toute sécurité : Google Maps reçoit ainsi maps.googleapis.com sans modifier les règles personnalisées de l’exploitant.

Le test du navigateur réessaie désormais automatiquement les blocages HTTP 429/503 temporaires des extensions de sécurité, évite les rafales artificielles de requêtes locales et réduit les chargements de page redondants.

Les widgets d’avis Doctify et leurs scripts sont désormais reconnus automatiquement comme un seul service de média externe, préparés avec les informations complètes du fournisseur et bloqués jusqu’au consentement.

Le test du navigateur reconnaît désormais un cache de pages Surge actif comme un cache compatible tenant compte des cookies et contrôle le site pendant que le cache reste activé. Les modules de cache inconnus et les extensions non prises en charge restent bloqués en toute sécurité.

Une instance Matomo auto-hébergée qui n’apparaît que lorsqu’un thème ou une extension affiche l’aperçu protégé est désormais identifiée automatiquement grâce à son chemin de script sans ambiguïté. L’hôte détecté est ajouté comme service statistique de l’exploitant du site et le test redémarre ; toute autre adresse inconnue reste bloquée.

Les services standard Borlabs actifs et reconnus sans ambiguïté sont désormais transférés automatiquement. Les utilisateurs WordPress n’ont plus à confirmer des tableaux techniques de fournisseurs ou de domaines ; seules les intégrations personnalisées inconnues déclenchent une question claire.

Le test automatique du navigateur affiche désormais chaque étape, le service contrôlé, le temps écoulé et le temps restant recalculé en continu. Les chargements répétés sont expliqués et ne clignotent plus visiblement. Après un test de migration réussi, l’assistant passe de manière fiable à la bascule au lieu de relancer le test.

Pendant la migration Borlabs, les contenus intégrés sur des domaines fournisseur partagés sont désormais identifiés par leur chemin URL. Par exemple, www.google.com/maps/embed est importé automatiquement comme Google Maps avec les données du catalogue local, tandis que les URL Google génériques ambiguës restent à vérifier.

Le test du navigateur ne considère plus le seul indicateur WP_CACHE comme la preuve d’un cache de page actif. Un véritable drop-in advanced-cache.php et les extensions de cache actives connues restent bloquants, tandis que le test mesure la réponse et la protection réelles du site.

La réinitialisation complète confirmée vérifie désormais le nettoyage, crée une nouvelle identité d’installation et purge les caches disponibles. Les données partagées restent protégées lorsque les paquets historique et annuaire coexistent, tandis que l’activation réseau initialise les sites Multisite existants et nouveaux. Les marqueurs PageSpeed et no-transform améliorent la compatibilité du composant de protection sans garantir toutes les configurations d’optimiseur.

La suppression du plugin efface toutes les données WPKookies. Les anciennes données conservées peuvent être réinitialisées après confirmation explicite.

Le composant de protection critique est exclu des réécritures PageSpeed et du report des scripts, sans affaiblir la politique de sécurité avec unsafe-eval.

La migration Borlabs reconnaît les fournisseurs connus comme SoundCloud dans les données importées, évite les consentements en double et vérifie les autorisations sans appels artificiels.

Les caches tenant compte des cookies, comme Surge, sont pris en charge afin que chaque état de consentement reçoive sa propre variante.

Le bouton de test du navigateur applique désormais automatiquement la configuration sûre déjà contrôlée, puis lance le test.

Les avertissements concernant le code importé indiquent désormais clairement qu’ils ne bloquent pas la migration ; le nettoyage de cookies dangereux est refusé avant exécution.

Les intégrations Yumpu détectées dans le contenu reçoivent désormais les mêmes informations fournisseur que les services configurés.

La migration Yumpu reçoit désormais la durée de conservation même si le fichier source laisse ce champ vide.

Yumpu est désormais reconnu comme service lors de la migration et préparé avec les informations du fournisseur et de confidentialité.

Le test automatique explique désormais clairement lorsque WordPress renvoie une page HTML au lieu de la réponse JSON attendue.

Le paquet destiné au répertoire WordPress est désormais contrôlé plus strictement avant publication. La restauration d’une migration fonctionne aussi de façon fiable sur les sites de test accessibles par adresse IP.

La configuration initiale est plus claire, les services associés sont regroupés de façon cohérente et les fournisseurs connus sont mieux reconnus. Des contrôles automatiques accompagnent la configuration jusqu’à sa validation.

WPKookies est maintenant disponible dans huit langues européennes. Les visiteurs voient le consentement et les réglages dans la langue du site, tandis que l’administration et les services peuvent être traduits.

Les contenus connus comme YouTube peuvent être autorisés une fois ou sur toutes les pages. Le choix peut être consulté, retiré et téléchargé dans un fichier lisible.

L’aperçu protégé et le test automatique sont plus rapides et fiables sur les grands sites WordPress.

Les vidéos et réseaux sociaux connus sont mieux reconnus et peuvent être autorisés séparément. Le bouton des réglages utilise le logo compact.

Le test automatique du site fonctionne avec davantage d’environnements WordPress.

Les sites utilisant seulement des services nécessaires peuvent terminer la migration. Les exports inadaptés sont mieux expliqués.

Le paquet d’installation a été amélioré pour une détection et une activation fiables.

Les saisies sont contrôlées plus strictement et les tests automatisés ont été étendus.

Le contrôle des contenus externes, les autorisations uniques et la migration guidée ont été largement développés.

Les changements de consentement et leurs contrôles automatiques ont été renforcés.

Après un test réussi, la bascule peut se terminer sans interruption. Les étapes manquantes sont clairement nommées.

Les contenus chargés avec retard peuvent être autorisés de nouveau après un refus.

Les contenus externes refusés peuvent être autorisés dans les réglages sans recharger la page.

Les services liés sont regroupés proprement pendant la migration et ne sont pas affichés deux fois.

Les contenus externes intégrés aux pages sont détectés pendant la migration et proposés au contrôle.

La reprise des installations Borlabs actuelles a été étendue et mieux limitée aux services réellement utilisés.

La migration cible plus précisément les services requis et évite les entrées inutiles.

Les versions Borlabs installées sont mieux reconnues. La bascule reste bloquée si les données sont incomplètes.

Un assistant guidé a introduit contrôle, test automatique, bascule et retour arrière.

Les commandes actualisées sont livrées correctement même avec un cache actif.

Le bouton des réglages fonctionne mieux avec différents thèmes et optimisations WordPress.

L’accès aux réglages de confidentialité a encore été stabilisé.

La fenêtre des réglages peut se restaurer après des modifications dues aux thèmes ou caches.

La migration guidée est mieux nommée. La suppression du plugin fonctionne sur davantage d’hébergements.

L’administration est devenue un assistant de migration clair en cinq étapes.

Première version avec consentements locaux, choix des services, blocage, retrait et fonctions de migration.