Le novità di wpkookies.

Kookies Consent è ora nella directory ufficiale dei plugin di WordPress.org. Dopo la scansione automatica, anche la revisione umana lo ha approvato, così il plugin si trova dove i siti WordPress installano e aggiornano le proprie estensioni. Per i gestori cambia soprattutto il percorso. Cercare, installare e aggiornare avviene ora direttamente dalla bacheca di WordPress, senza file ZIP e senza deviazioni. Cercalo con il nome Kookies Consent. Tutti i pulsanti di download di questo sito portano ora direttamente alla pagina del plugin su WordPress.org.

WordPress.org ha rifiutato il caricamento della 1.5.69: «Tested up to: 7.0 < 7.1». Un plugin il cui readme resta indietro rispetto alla versione attuale di WordPress non compare nelle ricerche. L’intestazione dice ora 7.1 — confermato in modo indipendente anziché supposto: la verifica di rilascio ha interrogato api.wordpress.org e ha ottenuto 7.1. La particolarità di questo valore è che non invecchia perché cambiamo qualcosa, ma perché WordPress pubblica una versione. Nessun controllo di questo progetto lo aveva mai guardato, in un file che decide accettazione o rifiuto. Da ora la verifica chiede da sé la versione attuale di WordPress e rifiuta un rilascio rimasto indietro; se l’interfaccia non è raggiungibile lo dice chiaramente invece di segnalare un controllo mai avvenuto. Il comportamento del plugin non cambia.

La ricerca nel codice introdotta con la 1.5.66 ha trovato 17 fornitori su un vero sito cliente con 36 plugin attivi — e il test del browser non ne ha incontrato nessuno su dodici pagine. Come elenco piatto di voci equivalenti, la schermata pretendeva diciassette decisioni che nessuno poteva prendere; prenderle avrebbe messo diciassette servizi nel banner di consenso che il sito non carica mai. Ora decide la misurazione: ciò che il test ha davvero incontrato e bloccato resta in alto come voce di lavoro, insieme alla data della misurazione su cui si fonda. Tutto il resto si ripiega in una sola riga che dichiara i propri limiti — il test visita un numero limitato di pagine, e ciò che sta soltanto dietro un modulo non lo vede. L’attribuzione passa per il servizio riconosciuto, mai per il nome host: www.google.com appartiene contemporaneamente a Google Maps e a reCAPTCHA, e solo il percorso li distingue. Nessuna etichetta verde senza misurazione, e nessuna per una ricerca interrotta o superata. Riparato di conseguenza: il pulsante di ricerca, puramente diagnostico, buttava via il rapporto di verifica superato del sito; un rilevamento della cache spariva dopo ogni aggiornamento invece che solo al cambiare della domanda; e un servizio configurato dalla sezione vicina restava proposto e affermava poi il contrario di quanto misurato.

La verifica del browser falliva su ogni installazione di 1.5.66 e 1.5.67. Arrivava fino in fondo e veniva poi rifiutata con «la verifica non ha fornito tutte le prove di pagine e servizi richieste» — su un sito cliente, subito dopo l’aggiornamento. La causa: un solo numero tenuto in due posti. La 1.5.66 ha portato il percorso da cinque pagine interne a dodici, mentre il server che convalida il rapporto manteneva la propria copia a cinque e rifiuta ogni rapporto il cui conteggio differisca dal suo. Ora quel numero vive solo sul server: lo pubblica e il browser lo legge, così i due non possono più divergere. Un test li confronta in entrambi i linguaggi, perché nient’altro poteva vederlo: la suite del browser lavora su fixture, i test PHP costruiscono i loro rapporti dalla costante del server e quindi concordano con sé stessi, e il test end-to-end non avvia mai una verifica reale.

Un cliente ha aggiornato, ha aperto la schermata delle impostazioni e ha trovato un avviso rosso: una cache esterna a WordPress serve pagine memorizzate, chiedete al vostro hoster di disattivarla. L’avviso era sbagliato. Misurava se la home page è memorizzata da qualche parte — vero per quasi ogni hosting, ed è il caso innocuo: la pagina memorizzata è quella anonima, dove tutto è comunque bloccato. Ciò che può davvero rompere il consenso è una cache che consegna quella stessa pagina memorizzata a un visitatore con cookie di consenso. La verifica ora scalda la cache, conferma che la pagina viene realmente riutilizzata e poi la richiede con un cookie di consenso. Una cache che risponde dal proprio archivio viene segnalata; una che risponde con una pagina fresca no, e non viene mostrato nulla. Quando c’è qualcosa da segnalare, il testo dice cosa non funziona e chiede ciò che serve davvero: lasciar passare a WordPress le pagine con il cookie di consenso, invece di pretendere che la cache venga spenta.

Un sito cliente ha perso il proprio elenco di servizi senza poterlo recuperare, perché il plugin da cui era stato migrato non c’era più. Ricostruirlo dalla verifica del browser ha raggiunto due fornitori: quella verifica visita poche pagine e può riferire solo ciò che quelle pagine caricano. Ora WPKookies esamina anche il codice installato: i plugin attivi, i plugin obbligatori, il tema attivo e il suo tema genitore, alla ricerca degli 88 domini di fornitori che il catalogo conosce. Ogni fornitore trovato si configura con un pulsante. Un risultato viene descritto per quello che è: la prova che questo codice può contattare il fornitore, non che ogni pagina lo carichi. Link e pulsanti di condivisione non contano più come incorporamenti, gli elenchi di fornitori di altri plugin di consenso vengono saltati, e una ricerca interrotta dichiara quanta parte del sito ha davvero letto invece di dare il via libera.

Un’installazione in produzione, completamente migrata, è stata cancellata con un solo clic su «ripristina installazione». Il ripristino si trova ora dietro le impostazioni tecniche invece che fra i due blocchi con cui lavora il gestore, e dichiara la perdita misurata di quel sito prima di poter essere avviato: quante voci ha l’elenco dei servizi, se sono in gioco una migrazione completata e un backup di ritorno, e quante righe ha davvero il registro dei consensi — contate, non presunte. Tutto ciò che va oltre un’installazione nuova richiede una seconda conferma esplicita, imposta dal server. Vengono chiuse altre due vie per perdere gli stessi dati: un elenco di servizi vuoto viene rifiutato e l’editor mostra ciò che è memorizzato invece di una vista filtrata che cancellerebbe i servizi nascosti. Su multisito il consenso alla disinstallazione viene letto per singolo sito. E dopo una verifica superata la schermata dice finalmente che non c’è nulla da fare — ma solo il server può dichiarare protetto un sito, perché la verifica del browser prova uno di sei controlli.

La verità della cache sostituisce l’ipotesi. Prima di ogni verifica del browser il plugin misura ora se il sito serve davvero pagine fresche: lo stesso indirizzo di anteprima viene caricato due volte e deve portare due gettoni monouso diversi. Una cache sorpresa a servire due volte la stessa pagina memorizzata viene nominata e può essere disattivata con un clic — anche una cache sensibile ai cookie perde il suo lasciapassare una volta provata come causa. Un avviso in grassetto in cima alle impostazioni nomina i plugin di cache bloccanti, altre otto cache di pagina sono riconosciute per nome e le cache dell’hoster o del CDN sono identificate con prove concrete delle intestazioni su cui solo l’hoster può agire. Ogni installazione deve ripetere la verifica una volta.

La verifica del browser misura finalmente ciò che certifica. Il vecchio livello di consenso continua a bloccare contenuti di terzi fino al passaggio, quindi «0 connessioni sconosciute» veniva misurato con il suo aiuto. I suoi hook vengono ora rimossi per le pagine caricate dalla verifica stessa, e il passaggio rifiuta un rapporto non misurato in questo modo: ogni installazione deve ripetere la verifica una volta. Questa versione chiude inoltre una divergenza di analisi degli URL tra PHP e i browser, restringe domini condivisi come cloudflare.com, conserva il registro dei consensi quando il plugin viene eliminato salvo richiesta contraria, e limita l’intestazione della policy sull’intera risposta.

Il proprietario del file advanced-cache.php viene ora letto dal file stesso invece di essere dedotto dai plugin attivi. Solo un plugin può possederlo, e non necessariamente uno ancora in funzione: su un sito reale il file apparteneva a un Cache Enabler disattivato mentre un’altra cache era attiva, e la vecchia deduzione dichiarava quel sito privo di cache mentre il file di un plugin morto veniva eseguito a ogni richiesta. Ogni file non attribuibile blocca ora la verifica, perché non se ne può dimostrare l’innocuità.

Una cache delle pagine che blocca la verifica del browser si disattiva ora con un solo pulsante nel percorso guidato. Finora la procedura indicava il plugin responsabile e rimandava il gestore all’elenco dei plugin, ma le persone per cui questo plugin è pensato non possono sapere quale dei loro plugin sia una cache delle pagine. wpkookies ricorda esattamente che cosa ha disattivato e può riattivarlo. Le cache basate sui cookie come Surge restano consentite e non vengono mai toccate.

Il requisito PHP dichiarato corrisponde finalmente alla realtà. Tutte le dichiarazioni indicavano PHP 8.1, mentre tre classi richiedono 8.2 da sempre: su un host con 8.1 il plugin si fermava con un errore di analisi invece di un messaggio utile. Un nuovo controllo di rilascio misura il requisito rispetto al codice consegnato.

La verifica ricava ora il percorso di sondaggio dal servizio che sta effettivamente provando, non dal primo membro del suo gruppo di consenso. Su un’origine condivisa quel primo membro è spesso un altro servizio, quindi la sonda non apparteneva a nessuno e tornava come una rilevazione sconosciuta inventata dalla verifica stessa.

La verifica del browser non sonda più Google Ads su un percorso che quel servizio non possiede. Su un host Google nazionale possiede esattamente i suoi due endpoint pubblicitari, quindi le sonde tornavano come rilevazioni sconosciute che la verifica stessa aveva inventato.

La verifica del browser lega ora l’acquisizione Borlabs applicata alla configurazione che sta per misurare. Qualsiasi modifica legittima dell’elenco dei servizi dopo l’importazione lasciava altrimenti proseguire l’esecuzione per novanta secondi per poi rifiutarla, senza alcun modo di concludere l’acquisizione.

Completa la riparazione automatica: essa modifica l’elenco dei servizi, il che interrompeva il legame tra un’acquisizione Borlabs in corso e le sue prove del browser, così ogni esecuzione successiva veniva rifiutata. L’aggiornamento ristabilisce ora quel legame.

Corregge la riparazione automatica distribuita nella versione precedente: la riparazione era corretta, ma la versione di migrazione dei dati non era stata alzata, quindi non veniva mai eseguita su un’installazione esistente. La regola Google troppo ampia viene ora davvero ristretta all’aggiornamento.

Una versione di irrobustimento dopo una revisione avversariale delle due precedenti. Due rilievi potevano mettere fuori uso un sito: una politica di sicurezza troppo lunga faceva rispondere i server con un errore per l’intera pagina, e la riaffermazione tardiva ricalcolava la politica invece di ripetere quella inviata, così due politiche proprie diverse potevano bloccare contenuti acconsentiti. La configurazione di un endpoint Google conserva ora l’host misurato invece dell’intero dominio, che legava pubblicità, mappe e reCAPTCHA a un’unica decisione. Le installazioni esistenti vengono corrette automaticamente.

Una rilevazione non si perde più tra due criteri di confronto: il browser segnalava www.google.com/ccm/collect come sconosciuta mentre l’elenco la considerava già configurata, così la verifica indicava un numero e non offriva nulla. Quell’indirizzo — la modalità di consenso di Google — è ora riconosciuto come Google Ads, con la consueta configurazione in un clic. E se la sessione WordPress scade durante una verifica, questa lo dice invece di mandarla a svuotare cache.

Un plugin di sicurezza poteva sostituire in silenzio la politica di sicurezza applicata da wpkookies: su quei siti la via di caricamento import() restava senza protezione. La politica viene ora riaffermata dopo tutte le altre e si affianca a quella altrui invece di scalzarla. Una politica in sola segnalazione non vale più come prova di blocco e, quando manca del tutto, la verifica indica la causa invece di elencare undici errori conseguenti.

Uno script di analisi o di tag manager bloccato non genera più un riquadro di consenso. Non ha un posto nella pagina, perciò il riquadro finiva sopra logo e navigazione spingendo in basso l’intero sito. Tali script vengono ora bloccati in silenzio; la scelta resta nel banner. Gli incorporamenti visibili mantengono il segnaposto dove si trova il contenuto.

Il catalogo riconosce ora 36 servizi di fornitori: si aggiunge Microsoft Advertising e Hotjar, Pinterest e TikTok ricevono gli indirizzi mancanti, anche nelle installazioni esistenti. Gli host CDN anonimi restano volutamente senza voce, perché nessuno può indicarne fornitore e finalità. L’elenco in home page è generato dal catalogo distribuito e non può quindi diventare obsoleto.

Rafforzamenti dall’audit: l’archivio delle prove non può più essere bloccato da un’ondata, le autorizzazioni una tantum non possono più inondare il database e un filtro di terze parti non diventa più configurazione permanente. Gli indirizzi con codifica percentuale sopravvivono allo strumento di verifica e una migrazione ferma non sembra più in corso.

Due correzioni di sicurezza: un ripristino eseguito prima del passaggio disattivava la protezione pubblica e le connessioni WebSocket non venivano mai bloccate, benché la documentazione lo assicurasse. Matomo Cloud non viene più configurato come self-hosted con il fornitore sbagliato. L’area di verifica ritira ora il «verificato» verde non appena un’esecuzione fallisce e indica il passo successivo subito sopra il pulsante che lo esegue.

Il beacon delle audience «Google Signals» di Google Analytics 4 viene ora riconosciuto come servizio standard «Google Ads e DoubleClick» e si configura con un clic — incluso l’host Google specifico del paese. Il risultato spiega inoltre che il beacon è un’impostazione della proprietà GA4: chi non vuole il remarketing disattiva semplicemente Google Signals in Google Analytics.

I risultati del test del browser compaiono ora sulla pagina in corso senza ricaricarla, e anche i servizi riconosciuti ma mai configurati — ad esempio uno snippet di Tag Manager — diventano risultati, con la configurazione a un clic. Ogni esecuzione registra ciò che ha realmente visto; una consegna fallita non afferma più che i risultati siano disponibili.

I dati residui nel database non contano più come installazione: opzioni e tabelle di Borlabs sopravvivono a una disinstallazione, ma venivano segnalate come «Borlabs trovato» su siti il cui elenco plugin non contiene Borlabs. I residui vengono ora chiamati residui e l’acquisizione guidata resta nascosta.

Quando il test del browser trova un indirizzo esterno senza servizio configurato, il risultato viene conservato e può essere configurato subito: con un pulsante per i fornitori riconosciuti, altrimenti tramite un piccolo modulo che indica ogni dato obbligatorio mancante. L’acquisizione guidata da Borlabs compare ora solo dove c’è davvero qualcosa da acquisire.

Una migrazione ferma per un errore non si presenta più come in corso: al posto dell’indicatore di attività e di «l’operazione prosegue» ora indica di essere ferma. Inoltre l’interruttore della modalità pubblica viene letto in modo uniforme: se l’impostazione mancava, frontend e Guardian descrivevano il sito in modo diverso.

Il secondo passaggio del test del browser è ora spiegato. Quando il plugin configura da sé un servizio riconosciuto in modo univoco, la configurazione cambia e la misurazione precedente non vale più: il test misura quindi esattamente una volta in più. La motivazione arriva ora dal server, sopravvive al ricaricamento e indica il servizio aggiunto. La meccanica del test resta invariata.

La protezione di compatibilità eval riconosce ora anche Smart Slider 3 Pro, distribuito come pacchetto separato. Su quei siti la protezione non veniva mai caricata, quindi la chiamata eval vuota e innocua di Smart Slider faceva fallire il test di protezione con un messaggio unsafe-eval. Il messaggio indica ora la pagina e lo script interessati; «unsafe-eval» resta vietato.

La protezione di compatibilità eval strettamente limitata viene caricata solo quando Smart Slider è realmente attivo. Gli altri siti e i test automatici non vengono più intercettati; il codice eval eseguibile resta bloccato dalla CSP rigorosa.

La protezione di compatibilità rifiuta ora qualsiasi input eval non vuoto, non lo esegue mai e registra il tentativo per Guardian. Resta accettata solo l’operazione esattamente vuota di Smart Slider.

La protezione delle chiamate eval esattamente vuote resta attiva per l’intera durata della pagina, perché Smart Slider esegue i callback vuoti dopo DOMContentLoaded. Il codice non vuoto resta bloccato dalla CSP.

La protezione limitata per le chiamate eval vuote viene ora eseguita prima di tutti gli script frontend. Copre quindi anche le librerie che memorizzano eval all’avvio, mentre la CSP continua a bloccare il codice non vuoto.

Le chiamate eval vuote vengono temporaneamente trattate come l’operazione senza effetto che rappresentano durante l’avvio della pagina. I callback vuoti di Smart Slider non violano più la CSP, mentre l’esecuzione di codice non vuoto resta vietata e rilevabile.

La correzione CSP di Smart Slider copre ora anche le inizializzazioni stampate direttamente nell’intestazione di WordPress. Il buffer di output mirato viene chiuso completamente durante la stessa azione wp_head.

I callback vuoti di Smart Slider sono ora compatibili con la CSP senza consentire unsafe-eval. Guardian rileva inoltre i tentativi eval vietati ancora presenti e si arresta invece di salvare un rapporto verde fuorviante.

I rilievi della revisione WordPress.org sono stati risolti: l’output degli shortcode viene sanificato, il buffering è gestito da WordPress, i nomi dei cookie ricevuti sono convalidati rigorosamente e i fornitori esterni opzionali sono documentati.

La convalida del rapporto Guardian estende ora ogni obiettivo di prova concreto attraverso il gruppo di consenso tecnico effettivamente configurato. I servizi collegati indirettamente tramite un altro dominio condiviso del fornitore vengono quindi verificati insieme correttamente; i gruppi incompleti restano non validi.

La convalida del rapporto Guardian usa ora gli stessi gruppi di consenso completi dell’interfaccia pubblica. I servizi tecnicamente collegati con domini del fornitore sovrapposti, come Google Maps e reCAPTCHA, non causano più il rifiuto di un rapporto corretto; i gruppi incompleti restano bloccati.

Il Guardian valuta ora la visibilità del banner solo durante la reale prima visita, non di nuovo dopo un rifiuto salvato intenzionalmente. Tutti i controlli rigorosi del blocco dei servizi e dei percorsi di caricamento del browser restano attivi.

Le migrazioni guidate precedenti da Borlabs vengono ora corrette anche quando manca il relativo marcatore interno del profilo di importazione. La correzione richiede una provenienza Borlabs esplicita e una corrispondenza di catalogo univoca; i servizi personalizzati e ambigui restano invariati.

Le correzioni dei dati hanno ora una propria versione di migrazione eseguita una sola volta. Le installazioni esistenti ricevono quindi le correzioni dei servizi rilevanti per la sicurezza anche se lo schema del database è già aggiornato, comprese le origini di runtime di Google Maps mancanti dopo una migrazione con 1.5.27.

Le migrazioni guidate da Borlabs aggiungono ora le origini di runtime specifiche del fornitore ai servizi importati riconosciuti senza ambiguità. I servizi standard esistenti vengono corretti in modo sicuro, così Google Maps riceve maps.googleapis.com senza modificare le regole personalizzate del gestore.

Il test del browser riprova ora automaticamente i blocchi HTTP 429/503 temporanei dei plugin di sicurezza, evita raffiche artificiali di richieste locali e riduce i caricamenti di pagina ridondanti.

I widget di recensioni Doctify e i relativi script vengono ora riconosciuti automaticamente come un unico servizio multimediale esterno, preparati con informazioni complete sul fornitore e bloccati fino al consenso.

Il test del browser riconosce ora una cache di pagina Surge attiva come cache supportata basata sui cookie e verifica il sito mentre la cache resta abilitata. I drop-in di cache sconosciuti e i plugin non supportati restano bloccati in modo sicuro.

Un’installazione Matomo self-hosted che appare solo quando un tema o plugin genera l’anteprima protetta viene ora identificata automaticamente dal percorso univoco dello script. L’host rilevato viene aggiunto come servizio statistico del gestore del sito e il test viene riavviato; ogni altro indirizzo sconosciuto resta bloccato.

I servizi standard Borlabs attivi e riconosciuti senza ambiguità vengono ora trasferiti automaticamente. Gli utenti WordPress non devono più confermare tabelle tecniche di fornitori o domini; solo le integrazioni personalizzate sconosciute generano una domanda chiara.

Il test automatico del browser mostra ora ogni passaggio, il servizio verificato, il tempo trascorso e il tempo rimanente calcolato continuamente. I caricamenti ripetuti vengono spiegati e non lampeggiano più visibilmente. Dopo un test di migrazione riuscito, l’assistente passa in modo affidabile alla commutazione invece di riavviare il test.

Durante la migrazione Borlabs, i contenuti incorporati su domini condivisi del fornitore vengono ora identificati tramite il percorso URL. Ad esempio, www.google.com/maps/embed viene importato automaticamente come Google Maps con i dati del catalogo locale, mentre gli URL Google generici ambigui restano da verificare.

Il test del browser non considera più il solo flag WP_CACHE come prova di una cache di pagina attiva. Un vero drop-in advanced-cache.php e i plugin di cache attivi noti restano bloccanti, mentre il test misura la risposta e la protezione effettive del sito.

Il ripristino completo confermato verifica ora la pulizia, crea una nuova identità di installazione e svuota le cache disponibili. I dati condivisi restano protetti quando coesistono i pacchetti legacy e directory, mentre l’attivazione di rete inizializza i siti Multisite esistenti e nuovi. I marcatori PageSpeed e no-transform migliorano la compatibilità del componente di protezione senza garantire ogni configurazione dell’ottimizzatore.

La rimozione del plugin cancella tutti i dati WPKookies. I vecchi dati conservati possono essere ripristinati dopo una conferma esplicita.

Il componente di protezione critico è escluso dalle riscritture PageSpeed e dal rinvio degli script, senza indebolire la politica di sicurezza con unsafe-eval.

La migrazione Borlabs riconosce fornitori noti come SoundCloud nei dati importati generici, evita consensi duplicati e verifica le autorizzazioni senza chiamate artificiali.

Le cache di pagina basate sui cookie come Surge sono supportate, così ogni stato di consenso riceve la propria variante corretta.

Il pulsante del test del browser applica ora automaticamente la configurazione sicura già verificata e avvia quindi il test.

Gli avvisi sul codice importato indicano ora chiaramente che non bloccano la migrazione; la pulizia di cookie non sicuri viene rifiutata prima dell’esecuzione.

Gli incorporamenti Yumpu rilevati direttamente nel contenuto ricevono ora le stesse informazioni del fornitore dei servizi configurati.

La migrazione Yumpu riceve ora la durata di conservazione anche quando il file sorgente lascia vuoto questo campo.

Yumpu viene ora riconosciuto come servizio durante la migrazione e preparato con informazioni sul fornitore e sulla privacy.

Il test automatico spiega ora chiaramente quando WordPress restituisce una pagina HTML invece della risposta JSON prevista.

Il pacchetto per la directory di WordPress viene ora verificato in modo più rigoroso prima della pubblicazione. Il ripristino della migrazione funziona in modo affidabile anche sui siti di test raggiunti tramite indirizzo IP.

La configurazione iniziale è più chiara, i servizi correlati vengono raggruppati in modo coerente e i fornitori noti sono riconosciuti meglio. I controlli automatici accompagnano la configurazione fino all’approvazione.

WPKookies è ora disponibile in otto lingue europee. I visitatori vedono consenso e impostazioni nella lingua del sito, mentre amministrazione e servizi possono essere tradotti.

I contenuti noti come YouTube possono essere autorizzati una volta o in tutte le pagine. La scelta si può verificare, revocare e scaricare come file leggibile.

L’anteprima protetta e il test automatico sono più rapidi e affidabili sui siti WordPress estesi.

Video e social noti vengono riconosciuti meglio e abilitati singolarmente. Il comando usa ora il logo compatto.

Il test automatico del sito funziona in modo più affidabile in altri ambienti WordPress.

I siti con soli servizi necessari possono completare la migrazione. I file inadatti sono spiegati meglio.

Il pacchetto è stato migliorato per un riconoscimento e un’attivazione affidabili.

La convalida degli inserimenti è più rigorosa e i controlli automatici sono stati ampliati.

Sono stati ampliati controllo dei contenuti esterni, permessi singoli e migrazione guidata.

Le modifiche del consenso e i relativi controlli automatici sono stati rafforzati.

Dopo un test riuscito il passaggio termina senza interruzioni. Le fasi mancanti sono indicate chiaramente.

I contenuti differiti possono essere riattivati in modo affidabile dopo un rifiuto.

I contenuti esterni rifiutati possono essere autorizzati dalle impostazioni senza ricaricare.

I servizi correlati sono raggruppati durante la migrazione e non appaiono due volte.

Gli incorporamenti esterni nelle pagine vengono rilevati e proposti per la verifica.

La migrazione da installazioni Borlabs attuali è stata estesa e limitata meglio ai servizi in uso.

La migrazione individua con più precisione i servizi necessari ed evita voci irrilevanti.

Le versioni installate sono riconosciute meglio. Il passaggio resta bloccato se mancano dati.

È stato introdotto un assistente con verifica, test automatico, passaggio e ripristino.

I comandi aggiornati vengono forniti correttamente anche con cache attiva.

Il comando delle impostazioni funziona meglio con temi e ottimizzazioni diversi.

L’accesso alle impostazioni della privacy è stato ulteriormente stabilizzato.

La finestra delle impostazioni può ripristinarsi dopo modifiche di temi o cache.

La migrazione guidata è più chiara e la rimozione funziona su più ambienti di hosting.

L’amministrazione è stata ridisegnata come un assistente chiaro in cinque fasi.

Prima versione con consensi locali, scelta dei servizi, blocco, revoca e migrazione.