RRVamso a deurar un error muy raro que tengo en lso widgets de editor de texto de elemetor. No carga la pestaña visual, pero si la de codigoDiagnosticó problema de Elementor e identificó posibles causas de conflicto.Ricardo me está mostrando un problema con Elementor. En las capturas de pantalla veo: Primera imagen: El editor de texto de Elementor con la pestaña "Visual" activa, mostrando texto Lorem ipsum y los botones de formato (b, i, link, del, img, cerrar las etiquetas) Segunda imagen: El mismo editor de texto pero con el área de contenido completamente vacía - no aparece el editor visual ni los botones de formato El problema que describe es que la pestaña Visual no carga correctamente, pero la de Código sí funciona. Este es un problema conocido de Elementor que puede tener varias causas: Conflicto con plugins de caché o minificación de JavaScript Conflicto con otros plugins que también usan TinyMCE o editores similares Problemas de JavaScript por conflictos con otros scripts Problemas con WPML o plugins de traducción Problemas de memoria PHP Conflicto con el tema Debo preguntarle más detalles para diagnosticar: ¿Es en un sitio específico o en todos? ¿Empezó después de alguna actualización? ¿Hay errores en la consola del navegador? Veo el problema, Ricardo. En la primera captura aparece el editor visual con el texto Lorem ipsum y los botones de formato, pero en la segunda la pestaña Visual está completamente vacía, sin el área de edición ni los botones. Este es un problema típico de conflicto de JavaScript que impide que TinyMCE (el editor visual que usa Elementor) se inicialice correctamente. Las causas más comunes son: Diagnóstico rápido que necesito: ¿Ocurre en un sitio específico o en varios de tu cartera? ¿Empezó después de alguna actualización reciente (Elementor, WordPress, algún plugin)? ¿Puedes abrir la consola del navegador (F12 → pestaña Console) y decirme si hay errores en rojo cuando cargas el editor? Mientras tanto, las causas más probables son: Plugin de caché/optimización (LiteSpeed Cache, WP Rocket, Autoptimize) que está minificando o combinando JavaScript de forma agresiva Conflicto con WPML si el sitio tiene traducción activa Conflicto con JetEngine o JetPlugins - a veces hay incompatibilidades con ciertas versiones Plugin de seguridad bloqueando scripts inline ¿Tienes algún plugin de caché activo en ese sitio? Si es así, prueba a purgar la caché y desactivar temporalmente la minificación de JS para ver si se resuelve.ReintentarRR1.- ocurre en uno que acabo de migrar. En el servidor de desarrollo va bien, pero en su alojamiento definitivo pasa esto2.- Aun no hay plugins de seguridad ni de cache.3.- No hay WPML4.- Lo de incompatibildiades con jet Engine o crokoblok nme extraña, proque en desarrollo tiene los mismos plugins, pero voy a probarloIdentificó error 404 de TinyMCE como problema principal de migración.Perfecto, ahora tengo información muy valiosa. Veo en la consola: Un error 404 crítico: https://www.repacar.org/wp-includes/js/tinymce/skins/lightgray/skin.min.cs... - Este es el problema principal. TinyMCE no puede cargar su archivo de skin/CSS, por eso el editor visual no se muestra. El TypeError de Cannot read properties of null (reading 'parentElement') en checklist.min.js es secundario, relacionado con el checklist de Elementor. El warning de @elementor/editor-site-navigation - Settings object not found también es secundario. El problema principal es ese 404 en el skin de TinyMCE. Esto significa que el archivo /wp-includes/js/tinymce/skins/lightgray/skin.min.css no existe o no es accesible en el servidor de producción. Causas posibles: Migración incompleta - no se copiaron todos los archivos de wp-includes Permisos de archivos incorrectos en el servidor de destino Configuración de .htaccess bloqueando acceso a ciertos archivos La carpeta lightgray puede no existir - en versiones más recientes de WordPress/TinyMCE el skin se llama diferente (oxide en lugar de lightgray) Esto es claramente un problema de migración. El sitio es repacar.org. Voy a sugerirle que verifique: Si el archivo existe en el servidor Si hay un problema de permisos Si hay algo en .htaccess bloqueando También podría ser que WordPress en producción sea una versión diferente que en desarrollo.¡Ahí está el culpable! Mira el último error: GET https://www.repacar.org/wp-includes/js/tinymce/skins/lightgray/skin.min.css net::ERR_ABORTED 404 (Not Found) TinyMCE no puede cargar su archivo de estilos, por eso el editor visual aparece vacío. Es un problema de la migración: ese archivo no existe o no es accesible en el servidor de producción. Comprobaciones rápidas: ¿Versiones de WordPress coinciden? El skin "lightgray" es de TinyMCE antiguo. En WordPress recientes el skin se llama "oxide". Si en desarrollo tienes una versión de WP diferente que en producción, ahí está el lío. Conecta por FTP/SFTP y verifica si existe la ruta: /wp-includes/js/tinymce/skins/lightgray/ Si no existe, lo más probable es que la migración no copió todo wp-includes correctamente, o hay una mezcla de versiones. Solución más limpia: Reinstala los archivos core de WordPress en producción sin tocar wp-content: Descarga el ZIP de WordPress (misma versión que tengas) Sube solo las carpetas wp-includes y wp-admin al servidor de producción sobrescribiendo ¿Qué versión de WordPress tiene el sitio en desarrollo y cuál en producción? Puedes verlo en el dashboard o en wp-includes/version.php.ReintentarRRExiste el directorio, pero no el archivoEs que es el mismo wordpress exactaente, porque lo he migrado con all in one migrationInvestigó inconsistencias de migración y propuso soluciones diagnósticas.Interesante. El directorio existe pero el archivo skin.min.css no está. Si usó All-in-One Migration, debería haber copiado todo exactamente igual. Esto es muy extraño. Posibles causas: All-in-One Migration tiene límites de tamaño y a veces no copia todo El archivo puede tener permisos incorrectos Puede haber algún problema con el .htaccess bloqueando acceso a ciertos archivos El hosting puede tener alguna restricción Debería pedirle que: Verifique qué archivos hay en ese directorio en desarrollo vs producción Compruebe si el archivo existe pero tiene permisos incorrectos O simplemente copie ese archivo/directorio manualmente desde desarrollo Muy raro. All-in-One Migration debería haber copiado todo. Puede ser que el archivo se corrompiera durante la migración o que el hosting tenga alguna restricción. Solución rápida: Copia manualmente el contenido de esa carpeta desde desarrollo. Conéctate por SFTP a ambos servidores y copia todo lo que haya en: /wp-includes/js/tinymce/skins/lightgray/ desde desarrollo a producción. Alternativa si no quieres andar con SFTP: ¿Qué versión exacta de WordPress es? Dime y te busco el archivo para que lo descargues directamente del repositorio oficial. Para descartar que sea el hosting bloqueando: Prueba a acceder directamente a esa URL en el navegador: https://www.repacar.org/wp-includes/js/tinymce/skins/lightgray/skin.min.css Si da 404 es que realmente no existe. Si da 403 (Forbidden) es el hosting o el .htaccess bloqueando.ReintentarRRHe subido el archivo y ya funciona el editor, pero ahor ano me fio de este wp. ¿estos otros errores que son?Diagnosticó errores de Elementor y recomendó reinstalar WordPress.Ricardo ha solucionado el problema del editor subiendo el archivo que faltaba. Ahora pregunta por los otros errores que quedan en la consola. Veo en la captura: Warning amarillo: @elementor/editor-site-navigation – Settings object not found en env.min.js?ver=3.33.2:1 Este es un warning de Elementor, no un error crítico. Parece que Elementor está buscando un objeto de configuración que no encuentra. Es común cuando hay alguna característica de Elementor Pro que no está completamente configurada o cuando hay un desajuste entre versiones. Error rojo: TypeError: Cannot read properties of null (reading 'parentElement') en web-cli.min.js?ver=3.33.2:2 Este viene de checklist.min.js - es el checklist de Elementor (la lista de tareas de configuración inicial) El error está en ToggleIcon.apply intentando leer parentElement de algo que es null Esto suele pasar cuando Elementor intenta manipular un elemento del DOM que no existe todavía Estos errores son de Elementor y no deberían afectar al funcionamiento normal del editor ahora que TinyMCE funciona. Sin embargo, el hecho de que falte un archivo de WordPress core es preocupante. Le voy a recomendar que haga una reinstalación limpia del core de WordPress para asegurarse de que no faltan más archivos. Esto se puede hacer desde el dashboard de WordPress en Escritorio → Actualizaciones → "Reinstalar versión X.X".Bien, el editor ya funciona. Los errores que quedan son de Elementor, no de WordPress: El warning amarillo (Settings object not found) es un aviso menor de Elementor sobre su navegación de sitio. No es crítico. El error rojo (Cannot read properties of null - parentElement) viene del checklist de Elementor - esa lista de tareas de configuración inicial que aparece en el editor. Elementor intenta manipular un icono que no encuentra en el DOM. Molesto pero no rompe nada funcional. Sobre tu desconfianza del WordPress: Tienes razón en desconfiar. Si falta un archivo de wp-includes, podrían faltar más. La solución más segura: Ve a Escritorio → Actualizaciones Aunque estés en la última versión, debería aparecer un botón "Reinstalar versión 6.x.x" Esto sobrescribe wp-includes y wp-admin con archivos limpios sin tocar wp-content Así te aseguras de que el core está completo. Es rápido y no afecta a tu contenido, plugins ni tema. ¿Quieres que investigue por qué All-in-One Migration no copió ese archivo? Podría ser un límite de tamaño del paquete o un timeout durante la extracción.ReintentarRRya he reinstalado. Ahora quiero ver si tengo errore de php. Dame el codigo para logearlos que debo poner en el config, el condicional, por favortIdentificó solicitud de código PHP para habilitar logging de errores.Ricardo quiere el código para habilitar el log de errores PHP en wp-config.php. Quiere el condicional completo para activar el debug logging.Aquí lo tienes: phpdefine( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 ); Ponlo antes de la línea que dice /* That's all, stop editing! */. Los errores se guardarán en /wp-content/debug.log. Navega un poco por el editor de Elementor y el admin para generar registros, y luego revisa ese archivo. Cuando termines de depurar, cambia WP_DEBUG a false para no dejar el log activo en producción.ReintentarRRpues he estado un rato navegando por la web, pro el elementor y todo, y aparte de que va a toda velocidad, no tengo logs de errores. Tengo que montar la politica de cookies e instalar el rank math eo asi que veremos que pasaValidó progreso positivo y sugirió desactivar debug posteriormente.Ricardo dice que ha estado navegando por la web, por el editor de Elementor, y que todo va muy rápido y no tiene errores de PHP en el log. Ahora va a instalar la política de cookies y Rank Math SEO. Esto es buena noticia - significa que la reinstalación del core de WordPress ha dejado el sitio limpio y funcionando bien. El único problema era ese archivo de TinyMCE que faltaba. Debería darle una respuesta breve y positiva, quizás recordarle que desactive el debug cuando termine de probar todo.Perfecto, eso es buena señal. El sitio está limpio y el único problema era ese archivo de TinyMCE que faltó en la migración. Cuando termines de instalar Rank Math y el plugin de cookies, dale otra vuelta al debug.log por si alguno genera warnings. Y recuerda desactivar WP_DEBUG antes de entregar el sitio. Si surge algo raro con la instalación, aquí estamos.ReintentarRRNecesito buscar un buen plugin de cookies que sea gratuito. Tengo la duda de cookieyes, que lo uso en wenbs pequeñas. pero tiene un limite en la opcion gratuita de 100 paginas para escanear las cookies. Tengo un blog de 800 entradas, pero en relaidad son la misma plantilla, es decir, si una tiene tal cokie, lo bvan a tener todas. ¿deberian contar como una sola pagina o como 800?Investigó cómo CookieYes cuenta páginas versus patrones de cookies.Ricardo is asking about CookieYes and its 100-page scan limit. He has a blog with 800 posts but they're all the same template, so he's wondering if they would count as 1 page or 800 pages for the cookie scanning. This is a good question. Let me think about how cookie scanning plugins typically work: Cookie scanning plugins usually crawl pages to detect what cookies are being set If all 800 blog posts use the same template and load the same scripts, they would theoretically set the same cookies However, the way CookieYes counts "pages" is likely based on unique URLs scanned, not unique cookie patterns I should search for more specific information about how CookieYes counts pages in their free plan to give Ricardo accurate advice.Buena pregunta. Voy a buscar cómo cuenta CookieYes las páginas exactamente.CookieYes free plan 100 pages limit how counted10 resultadosPageview Pricing - CookieYescookieyes.comCookieYes Pricing & Plans (November 2025) | Compare Costs & Features - SaaSworthysaasworthy.comPricing & Plans - CookieYescookieyes.comHow does CookieYes work regarding pages per scan? What happens if my website exceeds the page limit of my plan? - CookieYescookieyes.comWhat do pages per scan mean? - CookieYes FAQcookieyes.comCookieyescookieyes.comWhat happens if we exceed the monthly page views quota? - CookieYescookieyes.comFAQ - CookieYescookieyes.comCookieYes Review: The Right Cookie and GDPR Plugin for You?wpbeginner.comHow does the free trial work? - CookieYescookieyes.comLocalizó documentación técnica y evaluó implicaciones prácticas del límite.Good, I found the answer. The key information is in document 4: "CookieYes scans your website to detect and categorize cookies used across your pages. The number of pages scanned is determined by the plan you select, with each plan having a specific page limit. If your website has more pages than your plan allows, CookieYes will scan only the first set of identified URLs (based on your plan's limit). For example, if your plan covers 500 pages but your site has 1000 pages, CookieYes will scan only the first 500 identified URLs." So the scan is URL-based, not template-based. Each blog post URL counts as a separate page. With 800 posts and a 100 page limit, CookieYes would only scan the first 100 URLs it finds. However, Ricardo makes a good point - if all 800 posts use the same template and load the same scripts, they would have the same cookies. The problem is that CookieYes won't automatically know this - it scans individual URLs. The practical implication: if the cookies on the blog posts are the same as cookies on other pages that get scanned within the 100 page limit, he should be fine. But there's a risk that some cookies specific to blog posts might not get detected if those pages aren't among the first 100 scanned. I should explain this to Ricardo and maybe suggest alternatives or workarounds.Malas noticias: CookieYes escanea URLs individuales. Si tu plan cubre 100 páginas pero tu sitio tiene 1000, solo escaneará las primeras 100 URLs identificadas. Las cookies en páginas fuera de ese límite no se detectarán automáticamente ni se bl CookieYesoquearán antes del consentimiento. Así que tus 800 entradas contarían como 800 páginas, no como 1. La realidad práctica: Si todas las entradas usan la misma plantilla con los mismos scripts (Analytics, etc.), las cookies serán idénticas. El escaneo de 100 páginas probablemente detectará todas las cookies que existen en el sitio, porque las importantes suelen estar en home, páginas principales y algunas entradas. Opciones: Usar CookieYes gratis igualmente - escanea las 100 páginas, y luego añade manualmente cualquier cookie que sepas que falta (si la hay). En la práctica, para un blog con plantilla única, debería cubrir todo. Complianz (gratis) - alternativa popular que no tiene límite de páginas en el escaneo. Es un plugin de WordPress puro, sin dependencia de servicio externo. Real Cookie Banner - otra opción gratuita muy completa. ¿El blog tiene algo especial que cargue scripts solo en entradas (publicidad, embeds de terceros)? Si no, con el escaneo de 100 páginas deberías pillar todas las cookies.ReintentarRRComplianz lo he usado en muchisimos sitios, y ultimamente me esta dando problemas en algunas webs, pero es el mejor.he metido el codigo de analytics a traves de rankmath seo... ¿tengo que anular eso y configurarlo en Complianz para que detecte la cookie?Evaluó integración entre plugins y recomendó reconfigurar Analytics.Ricardo está preguntando sobre la integración entre Rank Math SEO (que ha usado para insertar el código de Google Analytics) y Complianz (que usará para gestionar el consentimiento de cookies). El tema es que para que Complianz pueda bloquear las cookies de Analytics hasta que el usuario dé su consentimiento (como requiere el GDPR), necesita controlar cuándo se carga el script de Analytics. Si el código de Analytics está metido a través de Rank Math, Complianz puede detectar la cookie en el escaneo, pero no podrá bloquearla correctamente antes del consentimiento a menos que: Complianz tenga capacidad de bloquear scripts de terceros automáticamente (que sí la tiene) O se configure Analytics directamente desde Complianz La mejor práctica sería: Quitar el código de Analytics de Rank Math Configurarlo directamente en Complianz, que tiene integración nativa con Google Analytics Así Complianz puede: Cargar Analytics solo cuando el usuario acepte cookies de estadísticas Manejar el modo de consentimiento de Google (Consent Mode v2) Anonimizar IPs si es necesario Voy a explicarle esto de forma clara.Exacto, esa es la clave. Complianz detectará la cookie de Analytics en el escaneo, pero para bloquearla hasta que el usuario acepte, necesita controlar cuándo se carga el script. Lo recomendable: Quita el código de Analytics de Rank Math Configúralo directamente en Complianz → Integraciones → Google Analytics Complianz tiene integración nativa con Analytics y así puede: Cargar el script solo cuando el usuario acepte cookies de estadísticas Gestionar el Consent Mode v2 de Google (que ahora es obligatorio para no perder datos) Anonimizar IPs automáticamente si lo necesitas Si prefieres dejarlo en Rank Math: Complianz puede intentar bloquear scripts de terceros automáticamente, pero es menos fiable. Tendrías que verificar en el escaneo que detecta y bloquea correctamente el script de Analytics, y a veces falla con scripts insertados por otros plugins. Mi consejo: usa Complianz para Analytics. Es más limpio y te aseguras de que el bloqueo funciona bien. Rank Math para SEO, Complianz para cookies y tracking.ReintentarRRASOCIACIÓN ESPAÑOLA DE RECICLADORES RECUPERADORES DE PAPEL Y CARTÓNponme esto en minusuclasPensando en convertir texto a minúsculas.El usuario simplemente quiere que convierta el texto a minúsculas. Es una petición directa y sencilla.asociación española de recicladores recuperadores de papel y cartónReintentarRRpero las primeras letras de cada palabra en mayuscula. Es el nombre de una asociacionPensando en capitalizar las primeras letras de palabras para un nombre de asociación.El usuario quiere el nombre de la asociación con la primera letra de cada palabra en mayúscula, es decir, en formato "Title Case". En español, para nombres de organizaciones se suele capitalizar las palabras principales.Asociación Española de Recicladores Recuperadores de Papel y CartónReintentarRRPor que complianz encuentra cookies tan raras en una practicamente nueva?__mpq_150605b3b9f979922f2ac5a52e2dcfe9_ev mp_150605b3b9f979922f2ac5a52e2dcfe9_mixpanel __mpq_150605b3b9f979922f2ac5a52e2dcfe9_pp mp_gen_new_tab_id_mixpanel_150605b3b9f979922f2ac5a52e2dcfe9 wpEmojiSettingsSupports mp_tab_id_mixpanel_150605b3b9f979922f2ac5a52e2dcfe9 wp-settings-1 wp-settings-time-1 wordpress_test_cookie wordpress_logged_in_13ae3e607b446195d448a44cc7eaeaacMostrar másIdentificó cookies de Mixpanel sospechosas en sitio nuevo.10sEl usuario está preguntando por qué Complianz encuentra cookies extrañas en un sitio nuevo. Veo varias cookies en la lista: Las que empiezan con mp o __mpq son de Mixpanel - un servicio de analítica. Esto es raro en un sitio nuevo. wpEmojiSettingsSupports - es de WordPress, relacionada con emojis wp-settings-1 y wp-settings-time-1 - cookies de WordPress para preferencias del admin wordpress_test_cookie - cookie de prueba de WordPress wordpress_logged_in_... - cookie de sesión de WordPress Las cookies de WordPress (wp-settings, wordpress_test_cookie, wordpress_logged_in) son normales y técnicas, no necesitan consentimiento. Lo raro son las de Mixpanel (mp_*). Estas no deberían estar ahí a menos que algún plugin o tema las esté cargando. Mixpanel es una herramienta de analítica de producto. Voy a explicarle esto al usuario.Esas cookies tienen dos orígenes distintos: Las normales de WordPress (no necesitan consentimiento): wp-settings-1 / wp-settings-time-1 → preferencias del admin wordpress_test_cookie → prueba de funcionamiento wordpress_logged_in_... → sesión de usuario logueado wpEmojiSettingsSupports → soporte de emojis Estas son técnicas/funcionales, no rastrean nada. Las raras (Mixpanel): mp_* y __mpq_* → son de Mixpanel, una herramienta de analítica Mixpanel no se instala solo. Algún plugin o el tema lo está cargando. Los sospechosos habituales: Elementor Pro - algunas versiones incluyen tracking de Mixpanel JetPlugins (JetEngine, JetFormBuilder, etc.) - Crocoblock usa Mixpanel para telemetría Rank Math - en algunas configuraciones ¿Tienes JetPlugins en este sitio? Si es así, ve a cualquiera de ellos (JetEngine, JetFormBuilder...) → Dashboard/Settings y busca una opción de "Usage tracking" o "Collect usage data" y desactívala. Eso debería eliminar las cookies de Mixpanel.ReintentarRREstas son las que realmente me muestra el navegadorr cuando estoy logeado, porque sin logear no tengo cookie saunAnalizó cookies del navegador y distinguió entre sesión de Google y WordPress.Ricardo me muestra las cookies reales que ve en el navegador cuando está logueado en el sitio. Veo: Muchas cookies de .google.com - estas son cookies de Google que se cargan por estar logueado en su cuenta de Google en el navegador, no son del sitio web en sí. Incluyen cosas como HSID, SID, SSID, APISID, SAPISID, NID, etc. Las cookies del sitio www.repacar...: wordpress_logged_in_13ae3e607... - sesión de WordPress wordpress_sec_13ae3e607b4461... - seguridad de WordPress wordpress_test_cookie - prueba de cookies de WordPress wp-settings-1 - preferencias del admin wp-settings-time-1 - timestamp de preferencias Entonces las cookies de Mixpanel que vio antes en Complianz no aparecen aquí. Eso significa que: O fueron cookies temporales que ya se eliminaron O Complianz las detectó de un script que se carga pero no las está viendo ahora Las cookies de google.com son del navegador/sesión de Google del usuario, no del sitio web. El sitio repacar.org en sí solo tiene las cookies de WordPress que son funcionales/técnicas. Debería explicarle que: Las cookies de .google.com son de su sesión de Google, no del sitio Las únicas cookies del sitio (www.repacar...) son las de WordPress, que son funcionales Si no hay Analytics instalado todavía o está bloqueado, no verá cookies de _ga, _gid, etc. Las de Mixpanel que detectó Complianz podrían venir del escaneo automático que hace Complianz (a veces detecta cookies de scripts que solo cargan en ciertas condiciones) Perfecto, eso aclara mucho. Lo que ves ahí: Cookies de tu sitio (www.repacar...): wordpress_logged_in_* → sesión de admin wordpress_sec_* → seguridad de sesión wordpress_test_cookie → prueba funcional wp-settings-1 / wp-settings-time-1 → preferencias del panel Todas son funcionales/técnicas de WordPress. No necesitan consentimiento. Cookies de .google.com: Esas no son de tu web. Son cookies de tu propia sesión de Google en el navegador (porque estás logueado en tu cuenta de Google). No las pone tu sitio, las pone Google para ti como usuario de sus servicios. Conclusión: El sitio está limpio. Sin loguearse, no hay cookies, y logueado solo hay las técnicas de WordPress. Las de Mixpanel que detectó Complianz probablemente vinieron de: Tu propia navegación como admin con JetPlugins cargados O un falso positivo del escáner Cuando configures Analytics a través de Complianz y vuelvas a escanear, deberías ver solo las cookies de GA (_ga, _gid) categorizadas como estadísticas. Por ahora el sitio está muy limpio.ReintentarRRUso recaptcha v3, que supongo que es un servicio de terceros. Lo declaro en la parte correspondiente de la configuracion, pero tengo obligacion de bloquearlo antes del consentimiento?Ponderó la ambigüedad legal de reCAPTCHA v3 bajo GDPR.The user is asking about reCAPTCHA v3 and whether it needs to be blocked before consent. This is a nuanced GDPR question. reCAPTCHA v3 is a bit of a gray area: It's technically a security/functional service (protects forms from spam) But it does send data to Google and can set cookies Google uses this data potentially for other purposes The legal interpretation varies: Some argue it's "strictly necessary" for security → no consent needed Others argue that since Google may use the data for other purposes, consent is required The GDPR says only "strictly necessary" cookies can be exempt In practice: If you block reCAPTCHA before consent, your forms won't be protected until the user accepts Many sites don't block it, arguing it's functional/security But the stricter interpretation would require consent since it's Google processing data The user has selected "No" for blocking reCAPTCHA before consent, which is the more practical approach but slightly less strict from a GDPR purist perspective. I should explain both sides and let him decide based on his risk tolerance. For most Spanish business sites, not blocking reCAPTCHA is the common practice.Buena pregunta. Es zona gris legalmente: Argumento para NO bloquearlo (lo que has marcado): reCAPTCHA v3 es un servicio de seguridad para proteger formularios Se puede considerar "estrictamente necesario" para el funcionamiento del sitio Si lo bloqueas, los formularios quedan desprotegidos hasta que el usuario acepte cookies Argumento para SÍ bloquearlo: Google recibe datos del usuario (IP, comportamiento de navegación) Google puede usar esos datos para otros fines (no solo proteger tu formulario) Interpretación estricta del GDPR: si no es imprescindible para que la web funcione, necesita consentimiento En la práctica en España: La mayoría de webs corporativas no lo bloquean, argumentando que es funcional/seguridad. La AEPD no se ha pronunciado específicamente sobre reCAPTCHA, y las sanciones suelen ir dirigidas a casos más flagrantes (Analytics sin consentimiento, píxeles de Facebook, etc.). Mi recomendación: Para una web de asociación como Repacar, déjalo como lo tienes (sin bloquear). El riesgo es mínimo y la funcionalidad se mantiene. Si fuera una web de salud o con datos sensibles, sería más estricto. Eso sí, menciónalo en la política de cookies como servicio de terceros que se usa para seguridad.ReintentarRR¿Y google fonts?Evaluó implicaciones de privacidad y soluciones de alojamiento.El usuario pregunta sobre Google Fonts y si debe declararlo como servicio de terceros y/o bloquearlo. Google Fonts tiene implicaciones de privacidad porque cuando se cargan desde los servidores de Google (fonts.googleapis.com), Google recibe la IP del visitante y otros datos. De hecho, en Alemania hubo una sentencia que multó a una web por cargar Google Fonts desde servidores de Google sin consentimiento. Las opciones son: Cargar Google Fonts desde los servidores de Google (problema de privacidad) Alojar las fuentes localmente (sin problema de privacidad) Si está usando Elementor, probablemente esté cargando Google Fonts desde los servidores de Google por defecto. Elementor tiene una opción para alojarlas localmente. Debería recomendarle que las aloje localmente para evitar el problema completamente.Google Fonts es más problemático que reCAPTCHA. En Alemania hubo una sentencia en 2022 que multó a una web con 100€ por cargar Google Fonts desde servidores de Google sin consentimiento, porque transmite la IP del visitante a Google sin justificación técnica. La solución más limpia: alojarlas localmente Con Elementor es fácil. Ve a Elementor → Ajustes → Avanzado y activa "Cargar Google Fonts localmente" (o "Google Fonts Load" → Local). Esto descarga las fuentes a tu servidor y las sirve desde ahí. Google nunca recibe datos del visitante, y no tienes que declarar nada ni pedir consentimiento. Si prefieres seguir cargándolas desde Google: Entonces sí, deberías marcarla en Complianz y técnicamente bloquearla hasta consentimiento. Pero es un lío porque afecta al aspecto visual de la web antes de aceptar cookies. Mi recomendación: Activa la carga local en Elementor y olvídate del tema. Es la opción que usan casi todos los que se preocupan por GDPR. Sin complicaciones legales, sin impacto visual, y además mejora un poco el rendimiento.ReintentarRRhay tres lugares sobre la carga de google fonts, no se como configurarlosDesglozó tres configuraciones de Google Fonts en Elementor.Ricardo is showing me three different Google Fonts settings in Elementor and asking how to configure them. Let me look at what I see: Image 1 (Avanzado section): "Google Fonts" - set to "Activar" - This enables/disables Google Fonts entirely "Carga de Google Fonts" - set to "Swap" - This is the font-display property Image 2 (another section, likely Performance/Rendimiento): 3. "Cargar localmente las fuentes de Google" - set to "Activar" - This is the local loading option So the configuration should be: "Google Fonts" → Activar (to use Google Fonts) "Cargar localmente las fuentes de Google" → Activar (to load them locally for GDPR) "Carga de Google Fonts" → Swap (for performance, font-display property) This combination will use Google Fonts but serve them from the local server, not from Google's servers. That's the GDPR-compliant setup.Perfecto, ya lo tienes casi bien. La configuración correcta es: En la primera pantalla (Avanzado): Google Fonts → Activar (para poder usar las fuentes de Google) Carga de Google Fonts → Swap (correcto, para rendimiento) En la segunda pantalla (Rendimiento): Cargar localmente las fuentes de Google → Activar ✓ Con "Cargar localmente" activado, Elementor descarga las fuentes a tu servidor y las sirve desde ahí. El ajuste de "Google Fonts: Activar" de la primera pantalla simplemente permite usarlas en el editor, pero gracias a la carga local no se conectan a los servidores de Google. Así que como lo tienes en la segunda captura está bien. Guarda cambios y listo. No hace falta declarar Google Fonts en Complianz porque ya no hay conexión con servidores externos.ReintentarRREn la web hay botones pra compartir contenidos. y para enlazar con el perfil del dueño de la web... ¿debo marcarlso aqui?Distinguió entre botones simples y widgets que requieren declaración.El usuario pregunta si debe marcar las redes sociales en Complianz porque tiene botones de compartir y enlaces a perfiles. Hay que distinguir entre: Botones de compartir simples (enlaces que abren una URL de compartir) - No cargan scripts externos, no ponen cookies. Son solo enlaces. Widgets/embeds oficiales (el botón de "Me gusta" de Facebook, el widget de Twitter embebido, etc.) - Estos SÍ cargan scripts de la red social y pueden poner cookies de tracking. Enlaces a perfiles - Son simplemente enlaces , no cargan nada. La pregunta clave es: ¿qué tipo de botones tiene? Si son botones de Elementor o de un plugin que simplemente generan enlaces para compartir (como los iconos de redes sociales de Elementor), no cargan scripts externos y no necesitan declararse. Si tiene embebidos reales (como un feed de Instagram, un timeline de Twitter, un botón de like de Facebook que carga el SDK), entonces sí necesita marcarlos. Debería preguntarle o explicarle la diferencia.Depende del tipo de botones: NO hace falta marcar si: Son botones/iconos de Elementor que enlazan a los perfiles (simples enlaces ) Son botones de compartir que solo abren una URL (tipo "compartir en Twitter" que abre una ventana) Estos no cargan scripts externos ni ponen cookies. Son enlaces normales. SÍ hace falta marcar si: Tienes embebido un feed de Instagram o Twitter Usas el botón oficial de "Me gusta" de Facebook (el que carga el SDK) Tienes un widget de LinkedIn o similar embebido Usas un plugin de compartir que carga scripts de las redes sociales ¿Los botones que tienes son los iconos normales de Elementor (los de redes sociales que pones en el footer o header)? Si es así, no marques nada, son solo enlaces y no afectan a cookies.ReintentarRRuso los de elementor, tanto para compartir contenidos como para enlazar con lso perfiles.Determinó que los iconos de Elementor no requieren declaración de cumplimiento.The user is using Elementor's social icons and share buttons. These are just simple links/anchors that open URLs. They don't load any external scripts or set cookies. So they don't need to be declared in Complianz.Entonces no marques ninguna. Los de Elementor son iconos con enlaces simples, no cargan SDKs ni ponen cookies. Déjalo todo desmarcado y sigue adelante.ReintentarRRNunca se lo que es el centro legal, por lo tanto nunca lo creo, y no se por que ACF genera cookis criticas.Desmenuzó dos funcionalidades de Elementor y aclaró malentendidos sobre cookies.Ricardo está preguntando dos cosas: Qué es el "centro legal" de Elementor Pro Por qué ACF (Advanced Custom Fields) aparece como que genera cookies Sobre el centro legal: Es una funcionalidad de Elementor Pro que crea automáticamente páginas legales (política de privacidad, aviso legal, política de cookies) con plantillas predefinidas. No es necesario usarlo si ya tienes esas páginas o las creas con Complianz. Sobre ACF: ACF en sí mismo no genera cookies para visitantes. Complianz lo detecta porque es un plugin que está activo y tiene integración con él, pero ACF solo funciona en el backend para gestionar campos personalizados. No pone cookies a los visitantes del frontend. Voy a explicarle esto de forma concisa.Centro legal de Elementor Pro: Es una función que crea páginas legales automáticas (privacidad, cookies, aviso legal) con plantillas. No lo necesitas porque Complianz ya genera esas páginas con contenido dinámico y mejor adaptado a la normativa. Déjalo en "No". ACF y cookies: ACF no pone cookies a los visitantes. Complianz lo lista porque detecta el plugin activo y tiene integración con él, pero es para gestión interna (campos personalizados en el admin). No afecta al frontend ni requiere consentimiento. Simplemente ignóralo, está bien que aparezca ahí. Dale a "Save and Continue".ReintentarRRCon el bloqueador de cookies y scripts siempre tengo dudas. No se si lo tengo que activar o no.Evaluó la necesidad del bloqueador según configuración futura de Analytics.El usuario pregunta sobre el bloqueador de cookies y scripts de Complianz. Esta es una función importante que bloquea scripts de terceros (como Analytics, Facebook Pixel, etc.) antes de que el usuario dé su consentimiento. En su caso: No tiene Analytics configurado todavía en Complianz (dijo que lo tenía en Rank Math) Tiene reCAPTCHA pero decidió no bloquearlo Google Fonts las carga localmente No tiene embeds de redes sociales Entonces, ¿necesita el bloqueador? Si va a configurar Analytics a través de Complianz (como le recomendé), entonces SÍ debería activar el bloqueador para que Analytics no cargue hasta que el usuario acepte. Si no tiene ningún script que necesite bloquear, podría no activarlo, pero es mejor tenerlo activado para: Cuando configure Analytics Por si en el futuro añade algo que necesite bloquearse Es la práctica recomendada para GDPR Le recomendaré que lo active, especialmente porque va a configurar Analytics a través de Complianz.Actívalo en Sí. El bloqueador es lo que hace que Complianz realmente cumpla el GDPR. Sin él, el banner es solo decorativo: avisa pero no bloquea nada. En tu caso concreto: Cuando configures Analytics a través de Complianz, el bloqueador impide que cargue hasta que el usuario acepte cookies de estadísticas Si en el futuro añades algo (un vídeo de YouTube embebido, un mapa, un pixel...), lo bloqueará automáticamente Si lo dejas en "No", Analytics cargaría desde el primer momento aunque el usuario no haya aceptado, y eso es justo lo que el GDPR prohíbe. Así que: Sí en ambas opciones y dale a "Concluir".ReintentarRRPara ofrecer las mejores experiencias, utilizamos tecnologías como las cookies para almacenar y/o acceder a la información del dispositivo. El consentimiento de estas tecnologías nos permitirá procesar datos como el comportamiento de navegación o las identificaciones únicas en este sitio. No consentir o retirar el consentimiento, puede afectar negativamente a ciertas características y funciones.HAzme una redacción mucho mas corta y clara de este texto para el banner, que la gente lo entienda.Pensando en simplificar y aclarar un texto sobre cookies y consentimiento para un banner web.Ricardo me pide que redacte un texto más corto y claro para el banner de cookies. El texto original es bastante largo y técnico. Necesito hacerlo más directo y comprensible para el usuario medio.Usamos cookies para mejorar tu experiencia y analizar el uso del sitio. Puedes aceptarlas, rechazarlas o configurar tus preferencias.ReintentarRRDescripcion de las cookies funionales. Redacta mejor y mas claro el texto. El almacenamiento o acceso técnico es estrictamente necesario para el propósito legítimo de permitir el uso de un servicio específico explícitamente solicitado por el abonado o usuario, o con el único propósito de llevar a cabo la transmisión de una comunicación a través de una red de comunicaciones electrónicas.Estrategizó clarificación de lenguaje legal sobre cookies funcionales.El usuario quiere que simplifique el texto legal sobre cookies funcionales. Debo hacerlo más claro y directo, manteniendo el sentido legal pero en lenguaje comprensible.Cookies necesarias para que la web funcione correctamente. Sin ellas no podrías navegar ni usar funciones básicas como formularios o tu sesión de usuario.
