Kookies Consent ya está en el directorio oficial de plugins de WordPress.org. Tras el análisis automático, la revisión humana también lo aprobó, así que el plugin está donde los sitios de WordPress instalan y actualizan sus extensiones. Para los operadores cambia sobre todo el camino. Buscar, instalar y actualizar se hace ahora directamente desde el escritorio de WordPress, sin archivo ZIP y sin rodeos. Búscalo con el nombre Kookies Consent. Todos los botones de descarga de este sitio llevan ahora directamente a la página del plugin en WordPress.org.
Actualizaciones
Novedades de wpkookies.
Mejoras publicadas en lenguaje claro y sin detalles técnicos sensibles.
Historial de versiones
La entrada más reciente aparece primero. Las futuras versiones se añadirán con su fecha.
La primera ronda de revisión humana de WordPress.org planteó tres puntos sobre la 1.5.70. Los tres se midieron antes de cambiar nada. Dos exigían un cambio: los enlaces de PayPal necesitaban cuatro redirecciones para llegar —exactamente la objeción— y ahora apuntan al propio centro legal de PayPal, que necesita una. Y el readme describe ahora la prueba de conexión del área de administración: quién puede iniciarla, a qué hosts se dirige, que cada solicitud debe ser rechazada en lugar de cargada, y el único tipo de sonda que depende solo de la política de seguridad impuesta. Otros dos enlaces señalados se midieron y están bien: el servidor de Yumpu respondió con error a tres de seis solicitudes, y la página de privacidad de Mapbox llega en 0,3 segundos pero pesa 489.124 bytes —exactamente el tamaño en el que la herramienta del revisor se quedó sin tiempo. El tercer punto se refería a un segundo prefijo de nombre y sacó a la luz un fallo real que nada tenía que ver con los nombres: un permiso de una sola vez ya consumido se anotaba como una fila transient construida a mano, y WordPress deja de limpiar esas filas en cuanto hay una caché de objetos persistente. En esos sitios crecían sin límite hasta alcanzar el techo de 5000 —a partir de ahí la carga única quedaba desactivada de forma permanente y silenciosa. Ahora la marca es una fila de opción propia con su propia limpieza en la tarea diaria existente, el techo limpia antes de denegar, y una actualización elimina lo que quedó atrás. Una revisión adversarial con varios agentes encontró cinco fallos más en ese código nuevo antes de la entrega —todos corregidos, y 17 mutaciones sin supervivientes lo demuestran.
WordPress.org rechazó la subida de la 1.5.69: «Tested up to: 7.0 < 7.1». Un plugin cuyo readme se queda por detrás de la versión actual de WordPress no aparece en las búsquedas. La cabecera indica ahora 7.1, confirmado de forma independiente en lugar de supuesto: la comprobación de publicación preguntó a api.wordpress.org y obtuvo 7.1. Lo particular de este valor es que no envejece porque cambiemos algo, sino porque WordPress publica una versión. Ninguna barrera de calidad de este proyecto lo había mirado nunca, en un archivo que decide la aceptación o el rechazo. A partir de ahora la comprobación pregunta ella misma por la versión actual de WordPress y rechaza una publicación que se haya quedado atrás; si no puede alcanzar la interfaz, lo dice con claridad en lugar de informar de una comprobación que no ocurrió. El comportamiento del plugin no cambia.
La búsqueda en el código incluida en la 1.5.66 encontró 17 proveedores en un sitio de cliente real con 36 plugins activos, y la prueba del navegador no encontró ninguno de ellos en doce páginas. Como lista plana de entradas equivalentes, la pantalla exigía diecisiete decisiones que nadie podía tomar; tomarlas habría metido diecisiete servicios en el banner de consentimiento que el sitio nunca carga. Ahora decide la medición: lo que la prueba encontró y bloqueó realmente queda arriba como tarea, junto con la fecha de la medición en la que se apoya. Todo lo demás se pliega en una sola línea que nombra sus propios límites: la prueba visita un número limitado de páginas, y lo que solo está detrás de un formulario no lo ve. La atribución pasa por el servicio reconocido, nunca por el nombre de host: www.google.com pertenece a la vez a Google Maps y a reCAPTCHA, y solo la ruta los distingue. Ninguna insignia verde sin medición, y ninguna para una búsqueda interrumpida o desactualizada. Reparado de paso: el botón de búsqueda, puramente diagnóstico, tiraba el informe de comprobación superado del sitio; un hallazgo de caché desaparecía tras cada actualización en lugar de solo cuando cambiaba la pregunta; y un servicio configurado desde la sección vecina seguía propuesto y afirmaba después lo contrario de lo medido.
La comprobación del navegador fallaba en todas las instalaciones de 1.5.66 y 1.5.67. Llegaba hasta el final y luego se rechazaba con «la comprobación no entregó todas las pruebas de páginas y servicios exigidas», en un sitio de cliente, justo después de actualizar. La causa: un mismo número guardado en dos sitios. La 1.5.66 subió el recorrido de cinco páginas internas a doce, mientras que el servidor que valida el informe mantenía su copia en cinco y rechaza cualquier informe cuyo recuento difiera del suyo. Ese número vive ahora solo en el servidor: él lo publica y el navegador lo lee, de modo que ya no pueden separarse. Una prueba los compara en ambos lenguajes, porque nada más podía verlo: la suite de navegador trabaja con fixtures, las pruebas PHP construyen sus informes a partir de la constante del servidor y por tanto coinciden consigo mismas, y la prueba de extremo a extremo nunca inicia una comprobación real.
Un cliente actualizó, abrió la pantalla de ajustes y se encontró un aviso rojo: una caché fuera de WordPress sirve páginas almacenadas, pida a su alojamiento que la desactive. El aviso era falso. Medía si la portada está almacenada en algún sitio, lo cual es cierto en casi todos los alojamientos y es el caso inofensivo: la página almacenada es la anónima, donde todo está bloqueado igualmente. Lo que sí puede romper el consentimiento es una caché que entrega esa misma página almacenada a un visitante con cookie de consentimiento. La comprobación calienta ahora la caché, confirma que la página se reutiliza de verdad y luego la pide otra vez con una cookie de consentimiento. Una caché que responde desde su almacén se informa; una que responde con una página fresca no, y no se muestra nada. Cuando hay algo que informar, el texto dice qué falla y pide lo que de verdad ayuda: dejar pasar a WordPress las páginas con la cookie de consentimiento, en lugar de exigir que se apague la caché.
Un sitio de cliente perdió su lista de servicios y no pudo recuperarla, porque el plugin del que se había migrado ya no estaba. Reconstruirla a partir de la comprobación del navegador alcanzó dos proveedores: esa comprobación visita unas pocas páginas y solo puede informar de lo que esas páginas cargan. Ahora WPKookies examina también el código instalado: los plugins activos, los plugins obligatorios, el tema activo y su tema padre, en busca de los 88 dominios de proveedores que conoce su catálogo. Cada proveedor encontrado se configura con un botón. Un hallazgo se describe por lo que es: prueba de que ese código puede contactar al proveedor, no de que cada página lo cargue. Los enlaces y los botones de compartir ya no cuentan como incrustaciones, se omiten las listas de proveedores de otros plugins de consentimiento, y una búsqueda interrumpida dice cuánto del sitio leyó realmente en lugar de dar el visto bueno.
Una instalación en producción, totalmente migrada, se borró con un solo clic en «restablecer instalación». El restablecimiento está ahora detrás de los ajustes técnicos en lugar de entre los dos bloques con los que trabaja el operador, e indica la pérdida medida de ese sitio concreto antes de poder ejecutarse: cuántas entradas tiene la lista de servicios, si están en juego una migración completada y una copia de retorno, y cuántas filas tiene realmente el registro de consentimiento, contadas y no supuestas. Todo lo que vaya más allá de una instalación nueva exige una segunda confirmación explícita, impuesta por el servidor. Se cierran otras dos vías para perder los mismos datos: una lista de servicios vacía se rechaza, y el editor muestra lo almacenado y no una vista filtrada que borraría servicios ocultos. En multisitio, la autorización de desinstalación se lee por sitio. Y tras una comprobación superada la pantalla dice por fin que no hay nada que hacer, pero solo el servidor puede declarar protegido un sitio: la comprobación del navegador prueba uno de seis controles.
La verdad de la caché sustituye a la suposición. Antes de cada comprobación del navegador, el plugin mide ahora si el sitio sirve realmente páginas frescas: la misma dirección de vista previa se carga dos veces y debe llevar dos testigos únicos distintos. Una caché sorprendida sirviendo dos veces la misma página almacenada se nombra y puede desactivarse con un clic; incluso una caché sensible a cookies pierde su pase una vez probada como causante. Un aviso en negrita en la parte superior de los ajustes nombra los plugins de caché bloqueantes, se reconocen ocho cachés de páginas más por su nombre y las cachés del alojamiento o CDN se identifican con pruebas de cabeceras concretas que solo el proveedor puede atender. Cada instalación debe repetir la comprobación una vez.
La comprobación del navegador mide por fin lo que certifica. La capa de consentimiento anterior sigue bloqueando contenido de terceros hasta el cambio, así que «0 conexiones desconocidas» se medía con su ayuda. Sus hooks se retiran ahora en las páginas que carga la propia comprobación, y el cambio rechaza un informe que no se haya medido así: cada instalación debe repetir la comprobación una vez. Esta versión cierra además una diferencia de análisis de URL entre PHP y los navegadores, acota dominios compartidos como cloudflare.com, conserva su registro de consentimiento al borrar el plugin salvo que pida lo contrario, y limita la cabecera de política en toda la respuesta.
El propietario del archivo advanced-cache.php se lee ahora del propio archivo en lugar de deducirse de los plugins activos. Solo un plugin puede poseerlo, y no necesariamente uno que siga funcionando: en un sitio real el archivo pertenecía a un Cache Enabler desactivado mientras otra caché estaba activa, y la deducción anterior declaraba ese sitio sin caché mientras el archivo de un plugin muerto se ejecutaba en cada petición. Todo archivo no atribuible bloquea ahora la comprobación, porque no se puede demostrar que sea inofensivo.
Una caché de páginas que bloquea la comprobación del navegador se desactiva ahora con un solo botón dentro del proceso guiado. Hasta ahora el proceso nombraba el plugin causante y remitía al responsable a la lista de plugins, pero las personas para las que se ha creado este plugin no pueden saber cuál de sus plugins es una caché de páginas. wpkookies recuerda exactamente lo que ha desactivado y puede volver a activarlo. Las cachés basadas en cookies, como Surge, siguen permitidas y nunca se tocan.
El requisito de PHP anunciado ya se corresponde con la realidad. Todas las declaraciones indicaban PHP 8.1, pero tres clases necesitan 8.2 desde el principio: en un alojamiento con 8.1 el plugin se detenía con un error de análisis en lugar de un mensaje útil. Una nueva comprobación de publicación mide el requisito frente al código entregado.
La comprobación deriva ahora la ruta de sondeo del servicio que realmente prueba, no del primer miembro de su grupo de consentimiento. En un origen compartido ese primer miembro suele ser otro servicio, así que la sonda no pertenecía a nadie y volvía como un hallazgo desconocido inventado por la propia comprobación.
La comprobación del navegador ya no sondea Google Ads en una ruta que ese servicio no posee. En un host de Google nacional posee exactamente sus dos extremos publicitarios, así que las sondas volvían como hallazgos desconocidos que la propia comprobación había inventado.
La comprobación del navegador vincula ahora la migración de Borlabs aplicada con la configuración que va a medir. Cualquier cambio legítimo en la lista de servicios desde la importación dejaba, si no, que la ejecución durara noventa segundos y luego fuera rechazada, sin manera de terminar la migración.
Completa la reparación automática: esta cambia la lista de servicios, lo que rompía el vínculo entre una migración de Borlabs en curso y sus pruebas del navegador, de modo que toda ejecución posterior era rechazada. La actualización vuelve a establecer ese vínculo.
Corrige la reparación automática entregada en la versión anterior: la reparación era correcta, pero no se elevó la versión de migración de datos, así que nunca se ejecutaba en una instalación existente. La regla de Google demasiado amplia se estrecha ahora realmente al actualizar.
Una versión de refuerzo tras una revisión adversarial de las dos anteriores. Dos hallazgos podían tumbar un sitio en funcionamiento: una política de seguridad demasiado larga hacía que los servidores respondieran con un error a toda la página, y la reafirmación tardía recalculaba la política en vez de repetir la enviada, de modo que dos políticas propias distintas podían bloquear contenido consentido. La configuración de un extremo de Google guarda ahora el host medido en lugar del dominio completo, que ataba publicidad, mapas y reCAPTCHA a una sola decisión. Las instalaciones existentes se corrigen automáticamente.
Un hallazgo ya no se pierde entre dos formas de comparar: el navegador informaba de www.google.com/ccm/collect como desconocida mientras la lista la daba por configurada, así que la comprobación indicaba una cifra y no ofrecía nada. Esa dirección —el modo de consentimiento de Google— se reconoce ahora como Google Ads, con la configuración de un clic habitual. Y si la sesión de WordPress caduca durante una comprobación, esta lo dice en vez de mandarle a vaciar cachés.
Un plugin de seguridad podía sustituir en silencio la política de seguridad aplicada por wpkookies: en esos sitios la vía de carga import() quedaba sin protección. La política se vuelve a establecer ahora después de todas las demás y se suma a la ajena en lugar de desplazarla. Una política en modo de solo informe ya no cuenta como prueba de bloqueo y, cuando falta por completo, la comprobación nombra la causa en vez de enumerar once errores derivados.
Un script de analítica o de gestor de etiquetas bloqueado ya no genera un cuadro de consentimiento. No tiene lugar en la página, así que el cuadro acababa encima del logotipo y la navegación y empujaba todo el sitio hacia abajo. Esos scripts se bloquean ahora en silencio; la decisión sigue en el banner. Las incrustaciones visibles conservan su marcador donde está el contenido.
El catálogo reconoce ahora 36 servicios de proveedores: se incorpora Microsoft Advertising y Hotjar, Pinterest y TikTok reciben las direcciones que les faltaban, también en instalaciones existentes. Los hosts CDN anónimos siguen deliberadamente sin entrada, porque nadie puede indicar su proveedor ni su finalidad. La lista de la página de inicio se genera a partir del catálogo entregado, así que no puede quedar desactualizada.
Refuerzos del análisis: el registro de pruebas ya no puede bloquearse con una avalancha, las autorizaciones únicas ya no pueden inundar la base de datos y un filtro de terceros ya no se convierte en configuración permanente. Las direcciones codificadas en porcentaje sobreviven a la herramienta de comprobación, y una migración detenida ya no parece estar en curso.
Dos correcciones de seguridad: una reversión realizada antes del cambio desactivaba la protección pública, y las conexiones WebSocket nunca se bloqueaban aunque la documentación lo prometía. Matomo Cloud ya no se configura como autoalojado con el proveedor equivocado. El área de comprobación retira ahora el «verificado» verde en cuanto una ejecución falla e indica el siguiente paso justo encima del botón que lo realiza.
La baliza de audiencias «Google Signals» de Google Analytics 4 se reconoce ahora como el servicio estándar «Google Ads y DoubleClick» y se configura con un clic, incluido el host de Google específico del país. El hallazgo explica además que la baliza es un ajuste de la propiedad GA4: quien no quiera remarketing simplemente desactiva las señales de Google en Google Analytics.
Los hallazgos de la prueba del navegador aparecen ahora en la página en curso sin recargarla, y los servicios reconocidos pero nunca configurados — por ejemplo un fragmento de Tag Manager — también se convierten en hallazgos, con la configuración de un clic. Cada ejecución registra lo que realmente vio; una entrega fallida ya no afirma que los hallazgos estén disponibles.
Los datos residuales en la base de datos ya no cuentan como instalación: las opciones y tablas de Borlabs sobreviven a una desinstalación, pero se comunicaban como «Borlabs encontrado» en sitios cuya lista de plugins no contiene Borlabs. Los restos se nombran ahora como restos y la adopción guiada permanece oculta allí.
Cuando la prueba del navegador encuentra una dirección externa sin servicio configurado, el hallazgo se conserva y puede configurarse en el momento: con un botón para los proveedores reconocidos y, si no, mediante un pequeño formulario que nombra cada dato obligatorio que falta. La adopción guiada de Borlabs solo aparece donde realmente hay algo que adoptar.
Una migración detenida por un error ya no se presenta como si estuviera en curso: en lugar del indicador de actividad y de «el proceso continúa», ahora indica que se ha detenido. Además, el interruptor del modo público se lee de forma uniforme: si faltaba el ajuste, el frontend y Guardian describían el sitio de forma distinta.
La segunda pasada de la prueba del navegador ahora se explica. Cuando el plugin configura por sí mismo un servicio reconocido sin ambigüedad, la configuración cambia y la medición anterior deja de aplicarse, por lo que la prueba mide exactamente una vez más. El motivo procede ahora del servidor, sobrevive a la recarga y nombra el servicio añadido. La mecánica de la prueba no cambia.
La protección de compatibilidad eval reconoce ahora también Smart Slider 3 Pro, que se distribuye como paquete independiente. En esos sitios la protección nunca se cargaba, por lo que la llamada eval vacía e inofensiva de Smart Slider hacía fallar la prueba de protección con un mensaje unsafe-eval. El mensaje indica ahora la página y el script afectados; «unsafe-eval» sigue prohibido.
La protección de compatibilidad eval estrictamente limitada solo se carga cuando Smart Slider está realmente activo. Los demás sitios y las pruebas automatizadas ya no se interceptan; el código eval ejecutable sigue bloqueado por la CSP estricta.
La protección de compatibilidad rechaza ahora cualquier entrada eval no vacía, nunca la ejecuta y registra el intento para Guardian. Solo se acepta la operación exactamente vacía de Smart Slider.
La protección de llamadas eval exactamente vacías permanece activa durante toda la página, porque Smart Slider ejecuta sus callbacks vacíos después de DOMContentLoaded. El código no vacío sigue bloqueado por CSP.
La protección limitada para llamadas eval vacías se ejecuta ahora antes que todos los scripts del frontend. Así cubre también bibliotecas que guardan eval durante el inicio, mientras CSP sigue bloqueando el código no vacío.
Las llamadas eval vacías se tratan temporalmente como la operación sin efecto que representan durante el inicio de la página. Los callbacks vacíos de Smart Slider ya no infringen CSP, mientras que la ejecución de código no vacío sigue prohibida y detectable.
La corrección CSP de Smart Slider ahora también cubre las inicializaciones impresas directamente en la cabecera de WordPress. Su búfer de salida limitado se cierra por completo durante la misma acción wp_head.
Las devoluciones de llamada vacías de Smart Slider ahora son compatibles con CSP sin permitir unsafe-eval. Guardian también detecta los intentos eval prohibidos restantes y se detiene en lugar de guardar un informe verde engañoso.
Se han corregido los hallazgos de la revisión de WordPress.org: se sanea la salida de los shortcodes, WordPress gestiona el búfer de salida, se validan estrictamente los nombres de cookies recibidos y se documentan los proveedores externos opcionales.
La validación del informe Guardian amplía ahora cada objetivo concreto de prueba mediante el grupo técnico de consentimiento realmente configurado. Así, los servicios vinculados indirectamente por otro dominio compartido del proveedor se comprueban juntos correctamente; los grupos incompletos siguen siendo inválidos.
La validación del informe Guardian utiliza ahora los mismos grupos completos de consentimiento que la interfaz pública. Los servicios vinculados técnicamente con dominios de proveedor superpuestos, como Google Maps y reCAPTCHA, ya no provocan el rechazo de un informe correcto; los grupos incompletos siguen bloqueados.
El Guardian evalúa ahora la visibilidad del banner solo durante la primera visita real, y no de nuevo después de guardar intencionadamente un rechazo. Todas las comprobaciones estrictas de bloqueo por servicio y de rutas de carga del navegador permanecen activas.
Las migraciones guiadas antiguas desde Borlabs se reparan ahora incluso cuando falta su marcador interno de perfil de importación. La reparación exige una procedencia Borlabs explícita y una coincidencia inequívoca con el catálogo; los servicios personalizados y ambiguos permanecen sin cambios.
Las reparaciones de datos tienen ahora su propia versión de migración de una sola ejecución. Así, las instalaciones existentes reciben correcciones de servicios relevantes para la seguridad aunque el esquema de la base de datos ya esté actualizado, incluidos los orígenes de ejecución de Google Maps que faltaban tras una migración con 1.5.27.
Las migraciones guiadas desde Borlabs añaden ahora los orígenes de ejecución específicos del proveedor a los servicios importados reconocidos inequívocamente. Los servicios estándar existentes se reparan de forma segura, de modo que Google Maps recibe maps.googleapis.com sin modificar las reglas personalizadas del operador.
La prueba del navegador reintenta ahora automáticamente los bloqueos temporales HTTP 429/503 de los plugins de seguridad, evita ráfagas artificiales de solicitudes locales y reduce las cargas de página redundantes.
Los widgets de reseñas de Doctify y sus scripts se reconocen ahora automáticamente como un único servicio de medios externos, se preparan con la información completa del proveedor y se bloquean hasta el consentimiento.
La prueba del navegador reconoce ahora una caché de páginas Surge activa como una caché compatible basada en cookies y comprueba el sitio mientras la caché permanece activada. Los módulos de caché desconocidos y los plugins no compatibles siguen bloqueados de forma segura.
Una instancia de Matomo con alojamiento propio que solo aparece cuando un tema o plugin genera la vista previa protegida se identifica ahora automáticamente mediante su ruta de script inequívoca. El host detectado se añade como servicio estadístico del operador del sitio web y la prueba se reinicia; cualquier otra dirección desconocida permanece bloqueada.
Los servicios estándar de Borlabs activos y reconocidos inequívocamente se transfieren ahora de forma automática. Los usuarios de WordPress ya no tienen que confirmar tablas técnicas de proveedores o dominios; solo las integraciones personalizadas desconocidas generan una pregunta clara.
La prueba automática del navegador muestra ahora cada paso, el servicio comprobado, el tiempo transcurrido y el tiempo restante calculado continuamente. Las cargas repetidas se explican y ya no parpadean de forma visible. Tras una prueba de migración correcta, el asistente avanza de forma fiable al cambio en lugar de reiniciar la prueba.
Durante la migración de Borlabs, el contenido incrustado en dominios compartidos del proveedor se identifica ahora mediante la ruta de la URL. Por ejemplo, www.google.com/maps/embed se importa automáticamente como Google Maps con los datos del catálogo local, mientras las URL genéricas ambiguas de Google quedan pendientes de revisión.
La prueba del navegador ya no considera el indicador WP_CACHE por sí solo como prueba de una caché de página activa. Un drop-in advanced-cache.php real y los plugins de caché activos conocidos siguen bloqueando, mientras la prueba mide la respuesta y la protección reales del sitio.
El restablecimiento completo confirmado verifica ahora la limpieza, crea una nueva identidad de instalación y vacía las cachés disponibles. Los datos compartidos permanecen protegidos cuando coexisten los paquetes heredado y de directorio, mientras que la activación de red inicializa los sitios Multisite existentes y nuevos. Los marcadores de PageSpeed y no-transform mejoran la compatibilidad del componente de protección sin garantizar cualquier configuración del optimizador.
Al eliminar el plugin se borran todos los datos de WPKookies. Los datos antiguos conservados pueden restablecerse tras una confirmación explícita.
El componente de protección crítico queda excluido de las reescrituras de PageSpeed y del aplazamiento de scripts, sin debilitar la política de seguridad con unsafe-eval.
La migración de Borlabs reconoce proveedores conocidos como SoundCloud en datos importados generales, evita consentimientos duplicados y verifica permisos sin llamadas artificiales.
Se admiten cachés de página basadas en cookies como Surge, de modo que cada estado de consentimiento recibe su variante correcta.
El botón de prueba del navegador aplica ahora automáticamente la configuración segura ya revisada y después inicia la prueba.
Las advertencias sobre código importado indican ahora claramente que no bloquean la migración; la limpieza insegura de cookies se rechaza antes de ejecutarse.
Las inserciones de Yumpu detectadas directamente en el contenido reciben ahora la misma información del proveedor que los servicios configurados.
La migración de Yumpu recibe ahora la duración de conservación aunque el archivo de origen deje ese campo vacío.
Yumpu ahora se reconoce como servicio durante la migración y se prepara con información del proveedor y de privacidad.
La prueba automática explica ahora claramente cuando WordPress devuelve una página HTML en lugar de la respuesta JSON esperada.
El paquete para el directorio de WordPress se comprueba ahora con mayor rigor antes de publicarse. La restauración de una migración también funciona de forma fiable en sitios de prueba accesibles por IP.
La configuración inicial es más clara, los servicios relacionados se agrupan de forma coherente y los proveedores conocidos se reconocen mejor. Las comprobaciones automáticas acompañan la configuración hasta su aprobación.
WPKookies ya está disponible en ocho idiomas europeos. Las visitas ven el consentimiento y los ajustes en el idioma del sitio, y la administración y los servicios también se pueden traducir.
Los contenidos conocidos como YouTube se pueden permitir una vez o en todas las páginas. La elección se puede revisar, revocar y descargar como archivo legible.
La vista previa protegida y la prueba automática funcionan más rápido y de forma más fiable en sitios grandes.
Los vídeos y redes sociales conocidos se reconocen mejor y se pueden habilitar por separado. El control usa ahora el logotipo compacto.
La prueba automática del sitio funciona de forma más fiable en más entornos de WordPress.
Los sitios con servicios únicamente necesarios pueden completar la migración. Los archivos no adecuados se explican mejor.
Se mejoró el paquete para que WordPress lo detecte y active de forma fiable.
La validación de entradas es más estricta y se ampliaron los controles automáticos.
Se ampliaron el control de contenido externo, los permisos de una sola vez y la migración guiada.
Se reforzaron los cambios de consentimiento y sus comprobaciones automáticas.
Tras una prueba correcta, el cambio se completa sin interrupciones. Las fases pendientes se indican claramente.
El contenido diferido puede volver a habilitarse de forma fiable después de un rechazo.
El contenido externo rechazado se puede permitir desde los ajustes sin recargar la página.
Los servicios relacionados se agrupan durante la migración y no aparecen duplicados.
Las inserciones externas en el contenido se detectan durante la migración y se proponen para revisión.
Se amplió la migración desde instalaciones Borlabs actuales y se limitó mejor a los servicios en uso.
La migración se centra con mayor precisión en los servicios necesarios y evita entradas irrelevantes.
Las versiones instaladas se reconocen mejor. El cambio permanece bloqueado si faltan datos.
Se incorporó un asistente con revisión, prueba automática, cambio y restauración.
Los controles actualizados se entregan correctamente incluso con caché activa.
El control de ajustes funciona mejor con distintos temas y optimizaciones de WordPress.
Se estabilizó aún más el acceso a los ajustes de privacidad.
El diálogo de ajustes puede restaurarse tras cambios provocados por temas o cachés.
La migración guiada tiene nombres más claros y la eliminación funciona en más alojamientos.
La administración se rediseñó como un asistente claro de cinco fases.
Primera versión con consentimientos locales, elección por servicio, bloqueo, revocación y migración.
Descargar la versión actual
Kookies Consent está disponible gratis en el directorio oficial de plugins de WordPress.