CumpleConsent

Historial de cambios

1.0.20

• La interfaz en español ahora usa comillas altas (“ ”) en lugar de las angulares, siguiendo la guía de estilo de español de Chile que usa el equipo de traducción de WordPress. Cambio solo de texto.

1.0.19

• El expediente de cumplimiento ya no contiene una etiqueta <style> escrita a mano. Su CSS se declara con wp_add_inline_style() sobre un identificador registrado y lo imprime el núcleo con wp_print_styles(). El expediente sigue siendo un documento autónomo —se archiva y se imprime, a veces sin conexión—, y por eso los estilos viajan en línea en vez de en un archivo externo.
• El punto público de consentimiento compara el origen completo. Ahora compara esquema, host y puerto en vez de solo el nombre del host, así que http://site, https://site y https://site:8443 son orígenes distintos, como exige la política de mismo origen.

1.0.18

• Limpieza para Plugin Check. Se eliminó un ayudante sin uso que leía el filtro del núcleo wp_mail_from y se documentó por qué las consultas de la migración de una sola vez arman sus nombres de tabla con $wpdb->prefix y sufijos literales. Sin cambios de comportamiento.

1.0.17

• El punto público de consentimiento solo acepta peticiones del mismo origen. Antes aceptaba Sec-Fetch-Site: same-site, que incluye a un subdominio hermano y habría dejado que uno decidiera el consentimiento en nombre del visitante de otro. Ahora solo pasa same-origin y, sin esa cabecera, la comprobación recurre al host del origen o del referente de la petición.
• Los archivos del propio aviso se imprimen con funciones de WordPress (wp_enqueue_style(), wp_enqueue_script(), wp_print_styles(), wp_print_scripts()) en vez de etiquetas escritas a mano, tanto en el camino normal como en el respaldo que se usa cuando un tema no imprime ni cabecera ni pie.
• El diagnóstico ya no levanta un hallazgo crítico en modo equilibrado. \”Los terceros detectados no están bloqueados en el HTML servido\” solo aplica a la estrategia estricta, que es la que deja marcas; en modo equilibrado un sitio puede apoyarse en Google Consent Mode y no tener marcas por diseño.
• El objeto de configuración de JavaScript ahora es cumpleconsentConfig en vez del ccnConfig de tres letras, que podía chocar con otro plugin.

1.0.16

• Los nombres internos y los datos guardados ahora usan el prefijo del propio plugin. Constantes, opciones, tablas, hooks, eventos de cron, transitorios y claves de metadatos pasaron del prefijo corto ccn_ a cumpleconsent_, como exigen las guías del directorio (al menos cuatro caracteres). Una migración de una sola vez traslada las opciones existentes, las tablas, la sal del registro, la clave de metadatos de la política y los eventos programados, así que una instalación existente conserva sus datos, y la cookie de consentimiento anterior se sigue leyendo para no volver a preguntar a los visitantes.
• La entrada controlada por el visitante se valida antes de usarla. La cookie de consentimiento y el cuerpo de la petición se decodifican y luego se reducen a la forma esperada: el identificador anónimo debe cumplir su formato, las finalidades se convierten a booleanos, a la versión del aviso se le quitan caracteres sueltos y el contexto debe ser uno de los valores conocidos. Todo lo demás se descarta en vez de guardarse.
• El texto de la respuesta enviada por correo se sanea, y el búfer de salida que abre el bloqueador de scripts ahora se cierra explícitamente al apagar (solo hasta su propio nivel, sin tocar búferes abiertos por el tema u otros plugins).
• El readme ahora aclara que la lista de dominios de terceros incluida es una lista de bloqueo: el plugin nunca contacta a esos servicios.

1.0.15

• La política se encuentra en más sitios, y solo cuando de verdad es una política. La detección ahora también mira las direcciones alternativas habituales (/privacidad/, /aviso-de-privacidad/, /privacy-policy/) y, como último recurso, las páginas publicadas con “privacidad” en el título (excluyendo la política de cookies). Una página solo se adopta si tiene una política dentro: una página vacía de relleno ya no se enlaza, lo que antes informaba 0 de 12 contenidos.
• Las políticas creadas con un maquetador ahora se leen. Elementor y similares guardan el contenido fuera de post_content, así que una política perfectamente válida puntuaba 0. El texto se lee ahora desde los datos propios del maquetador y, como último recurso, desde la página tal como el sitio la sirve.
• El aviso se entrega aunque el tema no imprima el pie. Plantillas como las páginas \”próximamente\” o los lienzos de maquetador se saltan wp_footer() y el aviso nunca aparecía; ahora se inyecta en el HTML servido cuando los enganches normales no se ejecutaron.

1.0.14

• Un sitio que ya publica su propia política de privacidad deja de figurar como si no tuviera ninguna. El plugin ahora reconoce la política asignada en sus ajustes, la página habitual /politica-de-privacidad/, o la página que el propio WordPress marca como política de privacidad, así que el aviso del panel y el enlace a la política funcionan en sitios cuya política se escribió y publicó a mano.
• El verificador del art. 14 ter lee la política, no la hoja de estilos de la página. Descarta el contenido de los bloques <style> y <script> incrustados antes de revisar: las páginas armadas como HTML propio (o fragmentos de Elementor) llevan su CSS dentro del contenido, y el verificador estaba puntuando una hoja de estilos.
• No se inventa un porcentaje de cobertura cuando no hay política publicada. Antes caía en puntuar el texto que genera el plugin, mostrando 100% para una página que el sitio no tenía; ahora informa que no hay nada que verificar.

1.0.13

• El formulario de derechos ya no pide domicilio ni medio alternativo de contacto. El correo que entrega el titular ya es un medio para responderle, que es lo que pide el art. 11, así que el campo opcional solo agregaba fricción. Las solicitudes recibidas antes de esta versión conservan su valor guardado.

1.0.12

• Nombre y documento de identidad ahora son dos campos separados en el formulario de derechos. Son datos distintos: el formulario pide el nombre completo en un campo y el RUT (u otro documento de identidad) en otro, el documento es obligatorio para tramitar la solicitud (art. 11: la solicitud debe identificar quién la presenta), se guarda en su propia columna, queda cubierto por el hash de integridad del registro y aparece en la vista del panel, en la exportación a CSV y en el aviso interno.

1.0.11

• Los correos que envía el plugin ahora muestran el nombre del sitio como remitente en lugar de \”WordPress\”, y llevan un Reply-To para que el titular pueda responder al buzón que de verdad tramita los derechos.
• El canal de derechos ya no puede fallar en silencio. El aviso interno ahora va al buzón de derechos (nunca a un respaldo que cumple otra función), su resultado queda guardado en la solicitud, una entrega fallida se marca en la lista de solicitudes y la pantalla de administración dice cuándo el canal no está conectado a su propio buzón. Nuevo botón \”enviar un correo de prueba\” en la pantalla de solicitudes, que informa el motivo del rechazo del servidor cuando la entrega falla.
• La dirección publicada para ejercer derechos es el buzón de derechos —en el formulario, en la política generada y en el registro de actividades—, mientras que la dirección de contacto general aparece por separado.

1.0.10

• El generador de política de privacidad ya no sobrescribe una política que el plugin no escribió. Si la página asignada ya tiene contenido propio —un documento que el sitio escribió, revisó y publicó—, el texto generado va a un borrador aparte y el panel lo explica, en vez de reemplazar el contenido de la página. La página se actualiza en su lugar solo cuando la escribió el plugin (rastreada con un metadato y el id de página guardado).
• El mensaje del panel distingue los tres desenlaces: generada, actualizada o conservada como borrador aparte.

1.0.9

• Documenta el único aviso de Plugin Check que queda: el hook litespeed_purge_all.
  Su nombre es de LiteSpeed Cache, así que no se puede renombrar; el plugin lo llama
  con su nombre exacto y solo cuando LiteSpeed está escuchando. Con esa nota, Plugin
  Check no reporta ningún problema en este plugin.

1.0.8

• Listo para el Plugin Check del directorio de WordPress: el readme ahora está en inglés (como exige el directorio), el título del readme coincide con el nombre del plugin y se quitó la cabecera Domain Path porque todavía no se incluye ningún archivo de traducción.
• Espacio de nombres y hooks internos renombrados para seguir el prefijo del plugin (clases CumpleConsent\... y hooks cumpleconsent_...) para que pasen las comprobaciones de prefijos. Nada cambia para los visitantes, para los ajustes guardados ni para la base de datos.
• Se agregaron comentarios para traductores en cada cadena con marcadores, se ordenaron los marcadores en dos mensajes del panel, se desescapó y saneó una entrada del panel, y quedaron documentados como falsos positivos los pocos avisos de Plugin Check que restan: los ayudantes de escape del propio plugin (badge()), wp_dropdown_pages() (que escapa su propia salida), el nombre de tabla armado con $wpdb->prefix, el punto público de consentimiento (un visitante anónimo no puede llevar un nonce) y el hook litespeed_purge_all, que es de LiteSpeed Cache.

1.0.7

• Corrige que el diagnóstico del sitio parecía no ejecutarse. Su resultado se guardaba, pero el saneador de ajustes descartaba las claves internas en cada guardado —el propio diagnóstico, la última fecha de la política y las marcas de instalación—, así que el panel seguía diciendo que nunca se había ejecutado. Esas claves ahora se conservan.
• El panel ahora muestra el resultado de cada acción (diagnóstico ejecutado, registro purgado, política generada o publicada, respuesta guardada, plazo prorrogado). Antes un clic no producía ninguna señal visible aunque la acción se hubiera ejecutado.
• Si el diagnóstico no puede leer la portada del sitio, lo dice con el motivo técnico en vez de informar sin haber mirado.

1.0.6

• Cambios de presentación para el directorio de WordPress: el nombre del plugin ahora es simplemente \”CumpleConsent\” (el título largo pasó a la descripción), \”Tested up to\” es 7.1, las etiquetas quedaron en cinco y la descripción corta cabe en los 150 caracteres que el directorio muestra bajo el nombre.
• Declara expresamente que el plugin no se conecta a ningún servicio externo (sección \”External services\”), como pide el proceso de revisión.
• Sin cambios de comportamiento: aviso, bloqueo, política y canal de derechos funcionan igual que en la 1.0.5.

1.0.5

• El aviso ya no depende de los optimizadores de JavaScript del sitio. Los plugins de caché (LiteSpeed, Autoptimize, WP Rocket y similares) fusionan el JavaScript del sitio en un único paquete que se carga tras la primera interacción del visitante. El aviso caía dentro de ese paquete: en una visita limpia nunca aparecía y, una vez fusionado, ya no se podía excluir por archivo desde los ajustes de caché. El script del aviso ahora va marcado para que no se combine ni se retrase, y la configuración viaja como bloque de datos (type="application/json"), que ningún optimizador retrasa porque no es código que ejecutar. Verificado en Chrome leyendo la configuración solo desde ese bloque.
• Con esto el aviso funciona en un sitio con caché agresiva sin tocar los ajustes del plugin de caché.
• Ocho pruebas nuevas que fijan el comportamiento: las marcas en los scripts, que los scripts de otros plugins quedan intactos y que el bloque de datos es JSON válido y no puede cerrar su propia etiqueta.

1.0.4

• El aviso y su panel ya no heredan el estilo del tema. Toda la apariencia (tipografía del sistema, colores, botones, cajas, botón flotante) está anclada a los contenedores propios del plugin y blindada, porque muchos temas ganan la cascada con reglas como .elementor-kit-12 h2, .elementor-kit-12 button o .elementor-kit-12 label. Medido en un sitio real con Elementor: el título del aviso quedaba en 1,2:1 de contraste (invisible), los cuatro botones en 2,21:1 con el fondo del tema, el enlace a la política en 1:1, y cada etiqueta de finalidad en mayúsculas y con el color del tema. Cada uno lleva ahora su propio estilo y un contraste verificado (mínimo AA 4,5:1).
• El color de acento configurado sí se aplica. Se guardaba en los ajustes y no lo usaba nadie: el aviso mostraba siempre el verde de fábrica.
• El formulario de derechos y el contenido incrustado conservan su propia tipografía y sus botones, pero mantienen el color de texto del sitio donde el autor los coloque, para que no queden ilegibles sobre fondos oscuros.
• Nuevas pruebas: el anclaje de cada selector, las propiedades de identidad blindadas, el contraste calculado sobre los colores reales del CSS y la verificación de que el acento configurado llega al aviso.
• Nuevo banco de pruebas (tests/navegador/generar-banco.py): descarga el CSS del sitio y mide el aviso en Chrome con él, para detectar este tipo de filtraciones sin depender del ojo de nadie.

1.0.3

• Corrección importante: una escritura parcial por la API REST ya no apaga los interruptores que no van en la petición. El formulario del panel envía el estado completo —donde una casilla sin marcar no viaja, así que su ausencia significa \”apagado\”—, pero la API puede escribir solo lo que cambia. El saneador ahora distingue los dos casos: por la API se conserva lo ausente; desde el panel se mantiene el comportamiento anterior. Sin esto, configurar el plugin con una contraseña de aplicación apagaba en silencio el botón flotante de preferencias, el bloqueo del contenido incrustado y el respeto del consentimiento en el servidor.
• Seis pruebas nuevas que fijan esa diferencia entre panel y API, incluida la de que un booleano enviado como falso por la API sí se aplique.

1.0.2

• Los ajustes ahora se pueden leer y escribir por API (/wp/v2/settings), con la misma credencial que usa cualquier cliente de WordPress: una contraseña de aplicación. Requiere manage_options, la misma capacidad que ya pedía el panel, y la opción no guarda credenciales. Útil para dejar el cumplimiento listo en sitios de clientes desde un script, sin pedir claves del panel.
• Rutas dedicadas de aprovisionamiento y verificación (cumpleconsent/v1/status, /policy y /rights-page): estado del sitio con los pendientes concretos, generación de la política y creación o reutilización de la página del canal de derechos, también sin entrar al panel.
• Generar la política ya no duplica la página. Si no hay ninguna asignada y el sitio ya tiene una con el slug politica-de-privacidad, se actualiza esa en vez de crear una segunda (antes dejaba una copia con el sufijo -2).
• La purga de caché al guardar los ajustes también ocurre cuando el cambio llega por la API, no solo desde el formulario del panel.
• La opción se registra en init en vez de admin_init: las peticiones REST no pasan por admin_init, así que exponerla ahí nunca habría aparecido en la API.
• Nuevas pruebas para las rutas de aprovisionamiento, la capacidad requerida, el estado y la reutilización de páginas.

1.0.1

• Corrección importante del panel de preferencias. El panel declara position: fixed, pero solo la posición \”centrada\” tenía coordenadas: con la posición por defecto (barra inferior) quedaba sin ninguna y se dibujaba fuera de la pantalla, así que pulsar \”Configurar\” parecía hacer desaparecer el aviso. Las coordenadas ahora están en la regla base del panel y ninguna posición puede quedar sin anclar.
• Cerrar sin decidir ya no deja al visitante sin aviso. Pulsar \”Cerrar\” (o Escape) devuelve el aviso de primera capa mientras no haya una decisión registrada.
• Aceptar ya no recarga la página. La recarga se mantiene solo para retirar una finalidad ya otorgada, el único caso en que hace falta (los scripts de terceros ya cargados no se pueden descargar de otra forma).
• Se añadieron 12 pruebas de geometría CSS y una prueba en navegador real (Chrome por CDP) que recorre el ciclo completo: sin decisión → configurar → cerrar → aceptar → retirar.

1.0.0

• Primera versión pública.
• Aviso sin patrones oscuros, con elección por finalidad y retiro permanente (art. 12).
• Bloqueo previo al consentimiento en cuatro capas, compatible con caché de página completa y con wp_consent_api; contenido incrustado bajo consentimiento (art. 14 quáter).
• Google Consent Mode v2 con estrategia estricta o equilibrada.
• Registro auditable con huella del aviso, hash de IP opcional, HMAC de integridad, exportación a CSV y purga programada (art. 12 y art. 14 ter i).
• Generador y verificador de la política de privacidad contra los doce contenidos del art. 14 ter.
• Formulario de derechos con plazos legales, acuse de recibo, respuesta íntegra guardada como prueba y alertas (art. 11).
• Registro de transferencias internacionales con su garantía (art. 14 ter h y art. 27).
• Registro de actividades de tratamiento, matriz de riesgo y protocolos con expediente imprimible (art. 3 del reglamento D.S. 662).
• Diagnóstico del sitio: terceros detectados, bloqueo efectivo, conflictos con otros gestores de consentimiento y cobertura de la política.
• Consentimiento en formularios con integración para Contact Form 7, WPForms y Gravity Forms.
• Seudónimos, minimización y sin telemetría: nada sale de tu instalación.