O Kookies Consent está agora no diretório oficial de plugins do WordPress.org. Depois da análise automática, a revisão humana também o aprovou, pelo que o plugin está onde os sites WordPress já instalam e atualizam as suas extensões. Para os operadores muda sobretudo o caminho. Procurar, instalar e atualizar passa a fazer-se diretamente a partir do painel do WordPress, sem ficheiro ZIP e sem desvios. Procure-o com o nome Kookies Consent. Todos os botões de transferência deste site conduzem agora diretamente à página do plugin no WordPress.org.
Atualizações
Novidades do wpkookies.
Melhorias publicadas em linguagem clara, sem pormenores técnicos sensíveis.
Histórico de versões
A entrada mais recente aparece primeiro. As versões futuras serão adicionadas com a data.
A primeira ronda de revisão humana do WordPress.org levantou três pontos sobre a 1.5.70. Os três foram medidos antes de se mudar seja o que for. Dois exigiam uma alteração: as ligações do PayPal precisavam de quatro redireccionamentos para chegar — exactamente a objecção — e apontam agora para o próprio espaço jurídico do PayPal, que precisa de um. E o readme descreve agora o teste de ligação na administração: quem o pode iniciar, que anfitriões contacta, que cada pedido deve ser recusado em vez de carregado, e o único tipo de sonda que depende apenas da política de segurança imposta. Outras duas ligações comunicadas foram medidas e estão bem: o servidor da Yumpu respondeu com erro a três de seis pedidos, e a página de privacidade da Mapbox chega em 0,3 segundos mas pesa 489.124 bytes — exactamente o tamanho em que a ferramenta do revisor ficou sem tempo. O terceiro ponto dizia respeito a um segundo prefixo de nomes e revelou um erro real que nada tinha a ver com nomes: uma autorização única já consumida era registada como uma linha transient construída à mão, e o WordPress deixa de limpar essas linhas assim que corre uma cache de objectos persistente. Nesses sites cresciam sem fim até ao tecto de 5000 — a partir daí o carregamento único ficava desligado de forma permanente e silenciosa. Uma marca é agora uma linha de opção própria com uma limpeza própria na tarefa diária existente, o tecto limpa antes de recusar, e uma actualização remove o que ficou para trás. Uma revisão adversarial com vários agentes encontrou mais cinco erros exactamente neste código novo antes da entrega — todos corrigidos, e 17 mutações sem sobreviventes provam-no.
O WordPress.org recusou o carregamento da 1.5.69: «Tested up to: 7.0 < 7.1». Um plugin cujo readme fica atrás da versão atual do WordPress não aparece nas pesquisas. O cabeçalho indica agora 7.1 — confirmado de forma independente em vez de assumido: a verificação de lançamento perguntou ao api.wordpress.org e recebeu 7.1. O particular deste valor é que não envelhece porque mudamos algo, mas porque o WordPress lança uma versão. Nenhuma barreira de qualidade deste projeto alguma vez olhou para ele, num ficheiro que decide a aceitação ou a recusa. A partir de agora a verificação pergunta ela própria pela versão atual do WordPress e recusa um lançamento que fique atrás; se a interface não estiver acessível, di-lo claramente em vez de reportar uma verificação que não aconteceu. O comportamento do plugin não muda.
A pesquisa no código introduzida na 1.5.66 encontrou 17 fornecedores num site de cliente real com 36 plugins ativos — e o teste do navegador não encontrou nenhum deles em doze páginas. Como lista plana de entradas equivalentes, o ecrã exigia dezassete decisões que ninguém conseguia tomar; tomá-las teria colocado dezassete serviços no banner de consentimento que o site nunca carrega. Agora decide a medição: aquilo que o teste realmente encontrou e bloqueou fica em cima como tarefa, com a data da medição em que a afirmação assenta. Tudo o resto recolhe-se numa única linha que nomeia os seus próprios limites — o teste visita um número limitado de páginas e não vê o que está apenas atrás de um formulário. A atribuição passa pelo serviço reconhecido, nunca pelo nome do anfitrião: www.google.com pertence ao mesmo tempo ao Google Maps e ao reCAPTCHA, e só o caminho os distingue. Nenhum emblema verde sem medição, e nenhum para uma pesquisa interrompida ou desatualizada. Reparado a par disso: o botão de pesquisa, puramente de diagnóstico, deitava fora o relatório de verificação aprovado do site; um achado de cache desaparecia após cada atualização em vez de apenas quando a pergunta mudava; e um serviço configurado através da secção vizinha continuava proposto e afirmava depois o contrário do que fora medido.
A verificação do navegador falhava em todas as instalações de 1.5.66 e 1.5.67. Corria até ao fim e era depois recusada com «a verificação não entregou todas as provas de páginas e serviços exigidas» — num site de cliente, logo após a atualização. A causa: um mesmo número guardado em dois sítios. A 1.5.66 elevou o percurso de cinco páginas internas para doze, enquanto o servidor que valida o relatório manteve a sua cópia em cinco e recusa qualquer relatório cuja contagem difira da sua. Esse número vive agora apenas no servidor: é ele que o publica e o navegador que o lê, pelo que os dois não podem voltar a divergir. Um teste compara-os nas duas linguagens, porque mais nada o conseguia ver: a suite de navegador corre sobre fixtures, os testes PHP constroem os seus relatórios a partir da constante do servidor e concordam portanto consigo mesmos, e o teste ponta-a-ponta nunca inicia uma verificação real.
Um cliente atualizou, abriu o ecrã de definições e deparou-se com um aviso vermelho: uma cache fora do WordPress serve páginas armazenadas, peça ao seu alojamento que a desligue. O aviso estava errado. Media se a página inicial está armazenada em algum lado — verdade em quase todos os alojamentos, e é o caso inofensivo: a página armazenada é a anónima, onde tudo está bloqueado de qualquer modo. O que pode mesmo quebrar o consentimento é uma cache que entrega essa mesma página armazenada a um visitante com cookie de consentimento. A verificação aquece agora a cache, confirma que a página está realmente a ser reutilizada e pede-a de novo com um cookie de consentimento. Uma cache que responda a partir do seu armazenamento é reportada; uma que responda de forma fresca não, e nada é mostrado. Quando há algo a reportar, o texto diz o que corre mal e pede o que ajuda de facto — deixar passar para o WordPress as páginas com o cookie de consentimento — em vez de exigir que a cache seja desligada.
Um site de cliente perdeu a sua lista de serviços e não a conseguiu recuperar, porque o plugin de onde tinha sido migrado já não existia. Reconstruí-la a partir da verificação do navegador chegou a dois fornecedores — essa verificação visita algumas páginas e só pode relatar o que essas páginas carregam. O WPKookies percorre agora também o código instalado: os plugins ativos, os plugins obrigatórios, o tema ativo e o seu tema principal, à procura dos 88 domínios de fornecedores que o catálogo conhece. Cada fornecedor encontrado configura-se com um botão. Um achado é descrito pelo que é: prova de que este código pode contactar o fornecedor, não de que todas as páginas o carregam. Ligações e botões de partilha deixam de contar como integrações, as listas de fornecedores de outros plugins de consentimento são ignoradas, e uma pesquisa interrompida diz quanto do site leu realmente em vez de dar tudo por resolvido.
Uma instalação em produção, totalmente migrada, foi apagada com um único clique em «repor instalação». A reposição está agora atrás das definições técnicas em vez de entre os dois blocos com que o operador trabalha, e indica a perda medida desse site antes de poder ser acionada: quantas entradas tem a lista de serviços, se estão em causa uma migração concluída e uma cópia de retorno, e quantas linhas tem realmente o registo de consentimentos — contadas, não presumidas. Tudo o que vá além de uma instalação nova exige uma segunda confirmação explícita, imposta pelo servidor. Fecham-se outras duas formas de perder os mesmos dados: uma lista de serviços vazia é recusada, e o editor mostra o que está guardado em vez de uma vista filtrada que apagaria serviços ocultos. Em multisite, a autorização de desinstalação é lida por site. E, depois de uma verificação aprovada, o ecrã diz finalmente que não há nada a fazer — mas só o servidor pode declarar um site protegido, porque a verificação do navegador prova um de seis controlos.
A verdade da cache substitui a suposição. Antes de cada verificação do navegador, o plugin mede agora se o site serve realmente páginas frescas: o mesmo endereço de pré-visualização é carregado duas vezes e tem de transportar dois tokens únicos diferentes. Uma cache apanhada a servir duas vezes a mesma página armazenada é nomeada e pode ser desativada com um clique — mesmo uma cache sensível a cookies perde o seu passe assim que fica provada como causa. Um aviso a negrito no topo das definições nomeia exatamente os plugins de cache bloqueadores, mais oito caches de páginas são reconhecidas pelo nome e as caches do alojamento ou CDN são identificadas com provas concretas de cabeçalhos que só o alojamento pode tratar. Cada instalação tem de repetir a verificação uma vez.
A verificação do navegador mede finalmente aquilo que certifica. A camada de consentimento antiga continua a bloquear conteúdos de terceiros até à mudança, pelo que “0 ligações desconhecidas” era medido com a ajuda dela. Os seus hooks são agora removidos nas páginas carregadas pela própria verificação, e a mudança recusa um relatório que não tenha sido medido assim — cada instalação tem de repetir a verificação uma vez. Esta versão fecha ainda uma divergência de análise de URL entre o PHP e os navegadores, restringe domínios partilhados como cloudflare.com, mantém o seu registo de consentimentos ao eliminar o plugin salvo indicação em contrário, e limita o cabeçalho da política em toda a resposta.
O proprietário do ficheiro advanced-cache.php é agora lido do próprio ficheiro em vez de deduzido dos plugins ativos. Só um plugin o pode possuir, e não necessariamente um que ainda esteja a funcionar: num site real o ficheiro pertencia a um Cache Enabler desativado enquanto outra cache estava ativa, e a dedução antiga declarava esse site sem cache enquanto o ficheiro de um plugin morto era executado em cada pedido. Tudo o que não puder ser atribuído bloqueia agora a verificação, por não se poder demonstrar que é inofensivo.
Uma cache de páginas que bloqueia a verificação do navegador é agora desativada com um único botão dentro do percurso guiado. Até agora o processo indicava o plugin responsável e remetia o responsável para a lista de plugins — mas as pessoas para quem este plugin foi feito não podem saber qual dos seus plugins é uma cache de páginas. O wpkookies recorda exatamente o que desativou e pode voltar a ativá-lo. As caches que têm em conta os cookies, como a Surge, continuam permitidas e nunca são tocadas.
O requisito de PHP anunciado corresponde agora à realidade. Todas as declarações indicavam PHP 8.1, mas três classes precisam de 8.2 desde sempre: num alojamento com 8.1 o plugin parava com um erro de análise em vez de uma mensagem útil. Uma nova verificação de lançamento mede o requisito face ao código entregue.
A verificação deriva agora o caminho de sondagem do serviço que está realmente a testar, e não do primeiro membro do seu grupo de consentimento. Numa origem partilhada esse primeiro membro é normalmente outro serviço, pelo que a sonda não pertencia a ninguém e voltava como um achado desconhecido inventado pela própria verificação.
A verificação do navegador deixa de sondar o Google Ads num caminho que esse serviço não possui. Num anfitrião nacional da Google possui exatamente os seus dois pontos finais publicitários, pelo que as sondas voltavam como achados desconhecidos que a própria verificação inventara.
A verificação do navegador liga agora a migração do Borlabs aplicada à configuração que está prestes a medir. Qualquer alteração legítima da lista de serviços desde a importação deixava, de outro modo, a execução durar noventa segundos e ser depois recusada, sem forma de concluir a migração.
Completa a reparação automática: esta altera a lista de serviços, o que quebrava a ligação entre uma migração do Borlabs em curso e as suas provas do navegador, pelo que todas as execuções seguintes eram recusadas. A atualização restabelece agora essa ligação.
Corrige a reparação automática distribuída na versão anterior: a reparação estava certa, mas a versão de migração de dados não foi elevada, pelo que nunca corria numa instalação existente. A regra da Google demasiado ampla é agora realmente estreitada na atualização.
Uma versão de reforço após uma revisão adversarial das duas anteriores. Duas conclusões podiam deitar abaixo um site em funcionamento: uma política de segurança demasiado longa fazia os servidores responderem com um erro para toda a página, e a reafirmação tardia recalculava a política em vez de repetir a que fora enviada, pelo que duas políticas próprias diferentes podiam bloquear conteúdos consentidos. A configuração de um ponto final da Google guarda agora o anfitrião medido em vez do domínio inteiro, que ligava publicidade, mapas e reCAPTCHA a uma única decisão. As instalações existentes são corrigidas automaticamente.
Um achado deixa de se perder entre dois critérios de correspondência: o navegador comunicava www.google.com/ccm/collect como desconhecido enquanto a lista o dava como já configurado, pelo que a verificação indicava um número e não oferecia nada. Esse endereço — o modo de consentimento da Google — passa a ser reconhecido como Google Ads, com a habitual configuração num clique. E se a sessão do WordPress expirar durante uma verificação, esta di-lo em vez de o mandar limpar caches.
Um plugin de segurança podia substituir silenciosamente a política de segurança imposta pelo wpkookies — nesses sites o caminho de carregamento import() ficava sem proteção. A política passa a ser reposta depois de todas as outras e coloca-se ao lado da política alheia em vez de a afastar. Uma política apenas de relatório deixa de contar como prova de bloqueio e, quando a política falta por completo, a verificação indica a causa em vez de listar onze erros consequentes.
Um script de analítica ou de gestor de etiquetas bloqueado deixa de produzir uma caixa de consentimento. Não tem lugar na página, pelo que a caixa acabava acima do logótipo e da navegação e empurrava todo o site para baixo. Esses scripts passam a ser bloqueados silenciosamente; a decisão mantém-se no banner. As incorporações visíveis conservam o seu marcador onde está o conteúdo.
O catálogo reconhece agora 36 serviços de fornecedores: junta-se o Microsoft Advertising e o Hotjar, o Pinterest e o TikTok recebem os endereços em falta — também em instalações existentes. Os anfitriões CDN anónimos ficam deliberadamente sem entrada, porque ninguém consegue indicar o seu fornecedor ou finalidade. A lista na página inicial é gerada a partir do catálogo distribuído, pelo que não pode ficar desatualizada.
Reforços da auditoria: o registo de provas já não pode ser bloqueado por uma enxurrada, as autorizações únicas já não podem inundar a base de dados e um filtro de terceiros deixa de se tornar configuração permanente. Os endereços codificados em percentagem sobrevivem à ferramenta de verificação e uma migração parada já não parece estar a decorrer.
Duas correções de segurança: uma reversão feita antes da mudança desligava a proteção pública e as ligações WebSocket nunca eram bloqueadas, embora a documentação o prometesse. O Matomo Cloud deixa de ser configurado como auto-alojado com o fornecedor errado. A área de verificação retira agora o “verificado” verde assim que uma execução falha e indica o passo seguinte imediatamente acima do botão que o executa.
O beacon de audiências “Google Signals” do Google Analytics 4 é agora reconhecido como o serviço padrão “Google Ads e DoubleClick” e configura-se com um clique — incluindo o host Google específico do país. O resultado explica ainda que o beacon é uma definição da propriedade GA4: quem não quiser remarketing desativa simplesmente o Google Signals no Google Analytics.
Os resultados do teste do navegador aparecem agora na página em curso sem recarregar, e os serviços reconhecidos mas nunca configurados — por exemplo um fragmento de Tag Manager — passam também a ser resultados, com a configuração num clique. Cada execução regista o que realmente viu; uma entrega falhada deixa de afirmar que os resultados estão disponíveis.
Os dados residuais na base de dados deixam de contar como instalação: as opções e tabelas do Borlabs sobrevivem a uma desinstalação, mas eram comunicadas como “Borlabs encontrado” — em sites cuja lista de plugins nem sequer contém o Borlabs. Os resíduos passam a ser designados como resíduos e a adesão guiada permanece oculta.
Quando o teste do navegador encontra um endereço externo sem serviço configurado, o resultado é mantido e pode ser configurado de imediato — com um botão nos fornecedores reconhecidos, caso contrário através de um pequeno formulário que indica cada dado obrigatório em falta. A adesão guiada do Borlabs surge agora apenas onde há realmente algo a assumir.
Uma migração parada por um erro deixa de se apresentar como estando a decorrer: em vez do indicador de atividade e de “a operação continua”, indica agora que está parada. Além disso, o interruptor do modo público é lido de forma uniforme — faltando a definição, o frontend e o Guardian descreviam o site de maneira diferente.
A segunda passagem do teste do navegador passa a ser explicada. Quando o plugin configura ele próprio um serviço reconhecido de forma inequívoca, a configuração muda e a medição anterior deixa de valer — por isso o teste mede exatamente mais uma vez. A razão vem agora do servidor, sobrevive ao recarregamento e indica o serviço adicionado. A mecânica do teste mantém-se.
A proteção de compatibilidade eval reconhece agora também o Smart Slider 3 Pro, distribuído como pacote separado. Nesses sites a proteção nunca era carregada, pelo que a chamada eval vazia e inofensiva do Smart Slider fazia o teste de proteção falhar com uma mensagem unsafe-eval. A mensagem indica agora a página e o script afetados; «unsafe-eval» continua proibido.
A proteção de compatibilidade eval estritamente limitada só é carregada quando o Smart Slider está realmente ativo. Outros sites e testes automáticos deixam de ser intercetados; o código eval executável continua bloqueado pela CSP rigorosa.
A proteção de compatibilidade rejeita agora qualquer entrada eval não vazia, nunca a executa e regista a tentativa para o Guardian. Apenas a operação exatamente vazia do Smart Slider permanece aceite.
A proteção para chamadas eval exatamente vazias permanece ativa durante toda a página, porque o Smart Slider executa os callbacks vazios após DOMContentLoaded. O código não vazio continua bloqueado pela CSP.
A proteção limitada para chamadas eval vazias é agora executada antes de todos os scripts do frontend. Assim também abrange bibliotecas que guardam eval no arranque, enquanto a CSP continua a bloquear código não vazio.
As chamadas eval vazias são temporariamente tratadas como a operação sem efeito que representam durante o arranque inicial da página. Os callbacks vazios do Smart Slider deixam de violar a CSP, enquanto a execução de código não vazio continua proibida e detetável.
A correção CSP do Smart Slider abrange agora também inicializações escritas diretamente no cabeçalho do WordPress. O buffer de saída limitado é totalmente fechado durante a mesma ação wp_head.
Os callbacks vazios do Smart Slider são agora compatíveis com CSP sem permitir unsafe-eval. O Guardian também deteta tentativas eval proibidas ainda existentes e para em vez de guardar um relatório verde enganador.
As conclusões da revisão do WordPress.org foram corrigidas: a saída dos shortcodes é sanitizada, o WordPress gere o buffer de saída, os nomes de cookies recebidos são validados rigorosamente e os fornecedores externos opcionais estão documentados.
A validação do relatório Guardian expande agora cada alvo concreto de teste através do grupo técnico de consentimento realmente configurado. Os serviços associados indiretamente por outro domínio partilhado do fornecedor são assim verificados corretamente em conjunto; os grupos incompletos continuam inválidos.
A validação do relatório Guardian utiliza agora os mesmos grupos completos de consentimento da interface pública. Serviços tecnicamente associados com domínios do fornecedor sobrepostos, como Google Maps e reCAPTCHA, já não fazem rejeitar um relatório correto; os grupos incompletos continuam bloqueados.
O Guardian avalia agora a visibilidade do banner apenas na primeira visita real, e não novamente após uma recusa guardada intencionalmente. Todas as verificações rigorosas de bloqueio por serviço e dos caminhos de carregamento do navegador permanecem ativas.
As migrações guiadas mais antigas do Borlabs são agora corrigidas mesmo quando falta o respetivo marcador interno de perfil de importação. A correção exige proveniência Borlabs explícita e uma correspondência inequívoca no catálogo; os serviços personalizados e ambíguos permanecem inalterados.
As correções de dados têm agora uma versão de migração própria, executada uma única vez. As instalações existentes recebem assim correções de serviços relevantes para a segurança mesmo quando o esquema da base de dados já está atualizado, incluindo as origens de execução do Google Maps em falta após uma migração com a versão 1.5.27.
As migrações guiadas do Borlabs adicionam agora origens de execução específicas do fornecedor aos serviços importados reconhecidos sem ambiguidade. Os serviços padrão existentes são corrigidos em segurança, para que o Google Maps receba maps.googleapis.com sem alterar regras personalizadas do operador.
O teste do navegador repete agora automaticamente bloqueios HTTP 429/503 temporários de plugins de segurança, evita rajadas artificiais de pedidos locais e reduz carregamentos de página redundantes.
Os widgets de avaliações Doctify e os respetivos scripts são agora reconhecidos automaticamente como um único serviço de multimédia externa, preparados com dados completos do fornecedor e bloqueados até ao consentimento.
O teste do navegador reconhece agora uma cache de páginas Surge ativa como uma cache suportada baseada em cookies e verifica o site mantendo a cache ativa. Drop-ins de cache desconhecidos e plugins não suportados continuam bloqueados em segurança.
Uma instalação Matomo com alojamento próprio que só aparece quando um tema ou plugin apresenta a pré-visualização protegida passa a ser identificada automaticamente pelo caminho inequívoco do script. O anfitrião detetado é adicionado como serviço estatístico do operador do site e o teste reinicia; todos os outros endereços desconhecidos permanecem bloqueados.
Os serviços padrão Borlabs ativos e inequivocamente reconhecidos passam a ser transferidos automaticamente. Os utilizadores do WordPress já não têm de confirmar tabelas técnicas de fornecedores ou domínios; apenas integrações personalizadas desconhecidas originam uma pergunta clara.
O teste automático do navegador mostra agora cada passo, o serviço verificado, o tempo decorrido e o tempo restante calculado continuamente. Os carregamentos repetidos são explicados e deixam de piscar visivelmente. Após um teste de migração bem-sucedido, o assistente avança de forma fiável para a mudança em vez de reiniciar o teste.
Durante a migração Borlabs, o conteúdo incorporado em domínios partilhados do fornecedor passa a ser identificado pelo caminho do URL. Por exemplo, www.google.com/maps/embed é importado automaticamente como Google Maps com os dados do catálogo local, enquanto URLs Google genéricos ambíguos continuam sujeitos a revisão.
O teste do navegador deixou de considerar a flag WP_CACHE, por si só, como prova de uma cache de página ativa. Um verdadeiro drop-in advanced-cache.php e plugins de cache ativos conhecidos continuam a bloquear, enquanto o teste mede a resposta e a proteção reais do site.
A reposição completa confirmada verifica agora a limpeza, cria uma nova identidade de instalação e limpa as caches disponíveis. Os dados partilhados permanecem protegidos quando os pacotes antigo e de diretório coexistem, enquanto a ativação de rede inicializa os sites Multisite existentes e novos. Os marcadores PageSpeed e no-transform melhoram a compatibilidade do componente de proteção sem garantir todas as configurações de otimização.
A eliminação do plugin remove todos os dados do WPKookies. Os dados antigos mantidos podem ser repostos após confirmação explícita.
O componente de proteção crítico fica excluído das reescritas PageSpeed e do adiamento de scripts, sem enfraquecer a política de segurança com unsafe-eval.
A migração Borlabs reconhece fornecedores conhecidos como o SoundCloud em dados gerais importados, evita consentimentos duplicados e verifica permissões sem chamadas artificiais.
As caches de página baseadas em cookies, como a Surge, são suportadas, para que cada estado de consentimento tenha a sua variante correta.
O botão de teste do navegador aplica agora automaticamente a configuração segura já verificada e inicia depois o teste.
Os avisos sobre código importado indicam agora claramente que não bloqueiam a migração; a limpeza insegura de cookies é recusada antes da execução.
As incorporações Yumpu detetadas diretamente no conteúdo recebem agora as mesmas informações do fornecedor que os serviços configurados.
A migração Yumpu recebe agora o período de retenção mesmo quando o ficheiro de origem deixa esse campo vazio.
O Yumpu é agora reconhecido como serviço durante a migração e preparado com informações do fornecedor e de privacidade.
O teste automático explica agora claramente quando o WordPress devolve uma página HTML em vez da resposta JSON esperada.
O pacote para o diretório WordPress é agora verificado com maior rigor antes da publicação. O restauro da migração também funciona de forma fiável em sites de teste acessíveis por endereço IP.
A configuração inicial é agora mais clara, os serviços relacionados são agrupados de forma consistente e os fornecedores conhecidos são melhor reconhecidos. As verificações automáticas acompanham a configuração até à aprovação.
O WPKookies está agora disponível em oito idiomas europeus. Os visitantes veem consentimentos e definições no idioma do site, e a administração e informações dos serviços podem ser traduzidas.
Conteúdos conhecidos como YouTube podem ser permitidos uma vez ou em todas as páginas. A escolha pode ser revista, revogada e descarregada como ficheiro legível.
A pré-visualização protegida e o teste automático funcionam mais depressa e com maior fiabilidade em sites grandes.
Vídeos e redes sociais conhecidos são reconhecidos melhor e podem ser ativados separadamente. O controlo usa agora o logótipo compacto.
O teste automático do site funciona com maior fiabilidade em mais ambientes WordPress.
Sites apenas com serviços necessários podem concluir a migração. Exportações inadequadas são explicadas com maior clareza.
O pacote foi melhorado para deteção e ativação fiáveis no WordPress.
A validação de entradas é mais rigorosa e as verificações automáticas foram ampliadas.
Foram ampliados o controlo de conteúdos externos, as permissões únicas e a migração guiada.
As alterações de consentimento e respetivas verificações automáticas foram reforçadas.
Após um teste bem-sucedido, a mudança termina sem interrupção. As etapas em falta são indicadas claramente.
Conteúdos adiados podem ser novamente ativados de forma fiável após uma rejeição.
Conteúdos externos rejeitados podem ser permitidos nas definições sem recarregar a página.
Serviços relacionados são agrupados durante a migração e não aparecem duplicados.
Conteúdos externos incorporados nas páginas são detetados e propostos para revisão.
A migração de instalações Borlabs atuais foi ampliada e melhor limitada aos serviços em uso.
A migração concentra-se com maior precisão nos serviços necessários e evita entradas irrelevantes.
As versões instaladas são melhor detetadas. A mudança continua bloqueada se faltarem dados.
Foi introduzido um assistente com revisão, teste automático, mudança e restauro.
Os controlos atualizados são entregues corretamente mesmo com cache ativa.
O controlo de definições funciona melhor com diferentes temas e otimizações do WordPress.
O acesso às definições de privacidade foi novamente estabilizado.
A janela de definições pode restaurar-se após alterações causadas por temas ou cache.
A migração tem nomes mais claros e a remoção funciona em mais ambientes de alojamento.
A administração foi convertida num assistente claro com cinco etapas.
Primeira versão com consentimentos locais, escolha de serviços, bloqueio, revogação e migração.
Descarregar a versão atual
Kookies Consent está disponível gratuitamente no diretório oficial de plugins do WordPress.