Un ataque de fuerza bruta no necesita que tu web tenga una vulnerabilidad en un plugin o un tema desactualizado, le basta con tu página de acceso.

Un script prueba combinaciones de usuario y contraseña, una tras otra, miles de veces por hora, hasta que da con la correcta o el servidor se cae por la carga. Y muchas veces el objetivo ni siquiera es entrar, sino tumbar tu web a base de peticiones.

La buena noticia es que este tipo de ataque es de los más fáciles de parar. Pero hay una diferencia enorme entre «instalar un plugin de seguridad y olvidarte» y montar una defensa seria, y esa diferencia está en dónde frenas el ataque.

En esta guía te explicaré cómo montar una protección por capas usando solo herramientas gratuitas.

Vamos a ir de fuera hacia dentro, primero la CDN como filtro perimetral, luego el hosting a nivel de servidor, y finalmente WordPress con plugins y buenas prácticas.

Cada capa tiene su función, todas son importantes, y cuando trabajan juntas los ataques de fuerza bruta dejan de ser un problema y pasan a ser ruido de fondo que ni notas.

Yo te voy a poner los ejemplos con las herramientas que uso y recomiendo, que ya sabrás que Cloudflare como CDN, SiteGround como hosting, y Vigilante como plugin de seguridad dentro de WordPress.

Los conceptos y las estrategias de cada capa son aplicables con cualquier combinación de herramientas, si usas otro CDN, otro hosting u otro plugin de seguridad, adapta los pasos a tu caso.

Dónde frenes el ataque lo cambia todo

Antes de entrar en materia necesitas entender algo que cambia la forma de pensar sobre seguridad en WordPress, y es que no es lo mismo frenar un ataque en la puerta de tu casa que frenarlo a tres calles de distancia.

Cada vez que alguien (o un bot) intenta acceder a tu WordPress, el servidor tiene que hacer bastante trabajo:

1. Cargar el núcleo de WordPress
2. Conectarse a la base de datos
3. Buscar el usuario
4. Calcular el hash de la contraseña
5. Ejecutar todos los hooks de seguridad

Multiplica eso por cientos o miles de intentos por hora y tu servidor se queda sin recursos para servir a los visitantes reales.

Si frenas el ataque solo con un plugin dentro de WordPress el daño ya está hecho a nivel de recursos, porque en este momento PHP ya se ha ejecutado y la base de datos ya ha recibido consultas.

Un plugin de seguridad puede bloquear al atacante después de X intentos, pero el servidor ya ha tragado toda esa carga. Si frenas el ataque en el CDN, esas peticiones ni siquiera llegan a tu servidor, el consumo de recursos es cero y tu web sigue funcionando como si no pasara nada.

La arquitectura por capas funciona como una defensa militar donde primero está el perímetro exterior, donde se frena al grueso del ejército atacante, luego están las murallas del castillo, donde se bloquea lo que ha conseguido pasar, y finalmente la guarnición interior, que se encarga de lo que ha logrado colarse por las grietas. Si una capa falla las otras siguen en pie.

• Capa 1 – CDN (perímetro): Filtra el tráfico masivo antes de que llegue a tu servidor. Aquí paras el 95% de los ataques.
• Capa 2 – Hosting (servidor): Bloquea IPs concretas y tráfico por países a nivel de infraestructura. Lo que pasa el CDN se encuentra con este filtro.
• Capa 3 – WordPress (aplicación): Analiza el comportamiento dentro de WordPress, limita intentos, exige segundo factor de autenticación, registra actividad y responde a ataques dirigidos.

Cada capa atrapa lo que se le escapa a la anterior, esa es la gracia del asunto. ¿Lo tienes claro?, pues ¡a defender la ciudad!

Capa 1: la CDN como primera línea de defensa

Una CDN (red de entrega de contenidos) como Cloudflare o KeyCDN actúa como proxy inverso, de manera que todo el tráfico de tu web pasa primero por él antes de llegar a tu servidor. Eso te da un control enorme sobre qué peticiones pasan y cuáles se quedan en la puerta.

En los ejemplos uso Cloudflare porque es el que yo utilizo y recomiendo, tiene un plan gratuito muy completo y es el más extendido, pero la estrategia es la misma con cualquier CDN que ofrezca reglas de firewall, gestión de bots y bloqueo geográfico.

Las estrategias van de menor a mayor impacto en la experiencia de usuario. Empieza por las primeras, que son invisibles para los visitantes legítimos, y usa las últimas solo cuando sea necesario.

Filtrar bots automatizados

• Qué consigues: eliminar el tráfico de bots maliciosos antes de que hagan una sola petición a tu servidor. Esta medida es completamente invisible para los visitantes humanos y no tiene ningún efecto negativo en la experiencia de usuario ni en el SEO.
• Cómo funciona: las CDN modernas utilizan aprendizaje automático para distinguir bots de humanos basándose en patrones de comportamiento, reputación de IP, huellas digitales del navegador y otros factores. A los bots maliciosos se les bloquea automáticamente.
• Cómo se hace en Cloudflare: ve a Seguridad → Configuración → Tráfico de bots y activa el Modo bot fight. Un clic y listo.
• Contras: si usas servicios que acceden a tu web de forma automatizada (herramientas de monitorización de uptime, servicios de backup externos, APIs de terceros, pasarelas de pago), comprueba que siguen funcionando. En la gran mayoría de casos no hay problema, pero vale la pena verificarlo.

Proteger la página de acceso con reglas de firewall

• Qué consigues: que cualquier bot que intente acceder a tu wp-login.php tenga que pasar un desafío que no puede superar. Los visitantes humanos lo resuelven automáticamente en un par de segundos sin molestias.
• Cómo funciona: configuras una regla en el firewall del CDN para que toda petición a tu página de login pase por un desafío JavaScript (lo que se conoce como Managed Challenge). Los navegadores reales lo resuelven solos. Los scripts automatizados no pueden.
• Cómo se hace en Cloudflare: ve a Seguridad → Reglas de seguridad y crea una regla:
  • Nombre: Proteger login WordPress
  • Campo: Ruta de URI
  • Operador: contiene
  • Valor: /wp-login.php
  • Acción: Desafío administrado
• Pros: filtra prácticamente todos los bots de fuerza bruta que van contra el login, con un impacto mínimo en usuarios reales (un par de segundos de espera la primera vez).
• Contras: si tienes un formulario de login personalizado en otra URL (algunos temas o plugins lo hacen), necesitas añadir esa ruta también a la regla. Y si tienes muchos usuarios que acceden frecuentemente (una tienda WooCommerce con miles de clientes, por ejemplo), ese par de segundos extra se multiplica.

Bloquear vectores de ataque innecesarios

• Qué consigues: cerrar puertas de entrada que probablemente no necesitas y que los atacantes usan como alternativa al login.
• Cómo funciona: xmlrpc.php es un archivo de WordPress que permite la comunicación remota con tu web. Lo usan algunas apps para publicar desde el móvil y ciertos plugins, pero también es un vector de ataque muy popular porque permite probar credenciales en masa con una sola petición (el método system.multicall). La mayoría de webs WordPress modernas no lo necesitan.
• Cómo se hace en Cloudflare: crea otra regla personalizada:
  • Nombre: Bloquear XML-RPC
  • Campo: Ruta de URI
  • Operador: contiene
  • Valor: /xmlrpc.php
  • Acción: Bloquear
• Pros: eliminas un vector de ataque importante sin afectar al funcionamiento normal de la web en la gran mayoría de casos.
• Contras: si usas Jetpack, la app oficial de WordPress para móvil, o algún servicio que dependa de XML-RPC, dejarán de funcionar. En ese caso, usa Desafío administrado como acción en vez de Block, así los servicios legítimos podrán pasar el desafío.

Restringir el acceso geográfico

Qué consigues: reducir drásticamente el volumen de ataques bloqueando el acceso desde países que no forman parte de tu audiencia. La mayoría de botnets operan desde redes distribuidas por todo el mundo, así que limitar geográficamente es muy efectivo.

• Cómo funciona: el CDN identifica el país de origen de cada petición por su IP y aplica la acción que tú elijas: bloquear, presentar un desafío o dejar pasar.
• Cómo se hace en Cloudflare: ve a Seguridad → Reglas de seguridad y crea una regla usando el campo País. Puedes seleccionar los países que quieras restringir y elegir la acción.
  Aquí hay dos estrategias según lo agresivo que quieras ser:
  • Restringir solo el login por país: combina las condiciones Ruta de URI + contains + /wp-login.php Y País + es igual a [país]. De este modo solo bloqueas el acceso al login desde esos países, pero pueden visitar tu web con normalidad.
  • Restringir toda la web por país: bloquea o aplica el desafío a todo el tráfico de ciertos países. Más agresivo, pero más efectivo si tu web tiene una audiencia geográfica muy clara.
    Mi consejo: empieza por los países desde los que recibes más ataques (puedes verlo en los registros de eventos de seguridad del CDN) y usa Desafío administrado en vez de Bloqueo. Así, si hay un visitante legítimo de ese país puede pasar la verificación y acceder.
• Pros: reduce el volumen de ataques de forma drástica si tienes geográficamente localizada a tu audiencia.
• Contras: te puedes cargar tráfico legítimo si no piensas bien qué países bloqueas. Servicios como pasarelas de pago, APIs de terceros o herramientas de monitorización pueden operar desde países que no esperas. Y si usas el bloquo en vez del desafío no hay vuelta atrás para esas visitas.

Ajustes generales de seguridad

• Qué consigues: un nivel base de protección que complementa las reglas específicas.
  Estos ajustes son el equivalente a cerrar bien todas las ventanas antes de salir de casa. Ninguno por sí solo para un ataque, pero todos juntos complican la vida al atacante:

• • SSL/TLS en modo Completo (estricto): si tu hosting incluye certificado SSL (SiteGround y la mayoría de hostings de calidad lo ofrecen gratis), activa este modo para que la conexión entre el CDN y tu servidor esté cifrada de extremo a extremo. Evita ataques de tipo man-in-the-middle.
  • Siempre usar HTTPS: redirige todo el tráfico HTTP a HTTPS automáticamente.
  • Nivel de seguridad en medio o alto: determina el umbral a partir del cual el CDN presenta desafíos a visitantes sospechosos.
  • Tiempo del desafío a 30 minutos: el tiempo durante el cual un visitante que ha pasado un desafío no tendrá que repetirlo.

Último recurso: modo Under Attack

Este es el botón de pánico. No es una medida preventiva, es una medida de emergencia.

• Qué consigues: frenar de golpe todo el tráfico malicioso cuando tu web está siendo atacada activamente y lo notas en el rendimiento (la web va lenta, se cae, el servidor no responde).
• Cómo funciona: al activarlo todos los visitantes (humanos y bots) tienen que pasar un desafío JavaScript antes de acceder a cualquier página de tu web. Los bots quedan completamente fuera.
• Cómo se hace en Cloudflare: en la página principal de tu dominio, busca Modo Under Attack Mode en el panel lateral derecho y actívalo. Si tienes la app de Cloudflare en el móvil puedes hacerlo desde cualquier sitio.
• Pros: efectividad inmediata. En cuestión de segundos el volumen de tráfico malicioso que llega a tu servidor cae a prácticamente cero. Es la respuesta más rápida que existe.
• Contras: afecta a todos los visitantes, incluidos los legítimos. Añade un par de segundos de espera a cada visita nueva (la pantalla de verificación automática de Cloudflare). Perjudica al SEO si se mantiene activado mucho tiempo porque los bots de búsqueda también tienen que pasar el desafío. Las APIs y webhooks que recibe tu web pueden dejar de funcionar. No es algo para tener puesto permanentemente.
• Cuándo usarlo: solo cuando estás bajo un ataque activo que afecta al rendimiento de tu web y las reglas WAF no son suficientes para contenerlo. Actívalo, espera a que la situación se estabilice, analiza el patrón del ataque, crea reglas de seguridad específicas para ese patrón, y desactívalo.

Capa 2: el hosting como segunda muralla

Tu hosting es la infraestructura donde vive tu web. Los hosting de calidad incluyen herramientas de seguridad que actúan a nivel de servidor, antes de que WordPress se cargue, eso los convierte en un segundo filtro muy eficiente para lo que ha conseguido pasar el CDN.

Al igual que como te comenté con las CDN y Cloudflare, en los ejemplos uso SiteGround porque es el hosting que recomiendo y conozco en detalle, pero la mayoría de hosting serios ofrecen funcionalidades equivalentes. Busca en tu panel de control las opciones de bloqueo de IPs, bloqueo de tráfico y logs de acceso.

Aquí las estrategias van de lo más básico (observar) a lo más agresivo (bloquear países enteros).

Vigilar los registros de acceso

• Qué consigues: visibilidad sobre lo que llega a tu servidor. Sin esta información estás tomando decisiones a ciegas.
• Cómo funciona: el hosting registra todas las peticiones que recibe tu servidor, como la IP de origen, la URL solicitada, el código de respuesta HTTP, el user-agent y la marca de tiempo. Revisando estos logs puedes detectar patrones de ataque, o sea, muchas peticiones a wp-login.php desde una misma IP, picos de tráfico inusuales, accesos desde países que no esperas.
• Cómo se hace en SiteGround: ve a Site Tools → Estadísticas → Registro de acceso.

No necesitas revisar los registros cada día pero sí cuando notes algo raro (web lenta, consumo de recursos alto, avisos del hosting) o como rutina semanal/mensual.

Lo que encuentres ahí te ayuda a tomar mejores decisiones en las otras capas, a la hora de crear reglas de seguridad más específicas en la CDN o bloquear IPs y rangos concretos.

Bloquear IPs desde el servidor

• Qué consigues: que las IPs que has identificado como atacantes no lleguen ni a cargar PHP. El bloqueo se ejecuta en el servidor así que el impacto en rendimiento de tu WordPress es cero.
• Cómo funciona: añades la IP o el rango de IPs a una lista de bloqueo en el panel de tu hosting. El servidor rechaza esas conexiones antes de que WordPress se entere de que existen.
• Cómo se hace en SiteGround: ve a Site Tools → Seguridad → Tráfico bloqueado. Puedes bloquear IPs individuales (por ejemplo, 185.234.218.45) o rangos con comodines (por ejemplo, 185.234.218.*).
• Pros: muy eficiente a nivel de recursos, el bloqueo se produce antes de que intervenga PHP o WordPress.
• Contras: los ataques de fuerza bruta suelen venir de miles de IPs rotativas así que bloquear IPs una a una es jugar al ratón y al gato. Es efectivo para IPs persistentes que detectas repetidamente en los logs, para ataques masivos distribuidos el bloqueo geográfico o las reglas del CDN son mejores opciones.

Bloquear tráfico por países desde el servidor

• Qué consigues: cortar de raíz todo el tráfico de países que no tienen relación con tu web, sin pasar por ningún desafío ni verificación. Bloqueo total para bien o para mal.
• Cómo funciona: el hosting identifica el país de origen de la IP y, si está en la lista de bloqueados, muestra una página de bloqueo. No hay opción de pasar una verificación como en el CDN. Bloqueo y punto.
• Cómo se hace en SiteGround: ve a Site Tools → Seguridad → Tráfico bloqueado > Bloquear país. Selecciona el dominio, elige el país y confirma.
• Pros: muy efectivo para reducir carga de servidor. Se ejecuta antes de que WordPress se cargue.
• Contras: es un bloqueo sin matices. Puedes bloquear visitantes legítimos, clientes, pasarelas de pago o servicios que operen desde esos países. Piénsalo bien antes de activarlo y revísalo periódicamente.

Hay una diferencia importante con el bloqueo geográfico del CDN pues aquí el bloqueo es absoluto, no hay desafío administrado. Si bloqueas un país nadie de ese país accede a nada de tu web. Por eso recomiendo esta estrategia:

• Bloqueo suave por países (con posibilidad de que humanos pasen): hazlo en el CDN con el desafío administrado.
• Bloqueo duro por países (nadie accede): hazlo en el hosting, pero solo si estás seguro de que no tienes visitantes, clientes o servicios en esos países.

El plugin de seguridad del hosting

Hay algunos hosting que ofrecen su propio plugin de seguridad para WordPress, y como me habrás oído decir más de una vez ante la duda siempre usa primero lo que te ofrezca el hosting, son los mayores interesados en que no tengas problemas.

Siguiendo con el ejemplo, SiteGround tiene Security Optimizer, que incluye 2FA, límite de intentos de login, URL de login personalizada y registro de actividad.

Si ya usas un plugin de seguridad, tipo Vigilante o Wordfence, no lo necesitas, pero ojo, que tener dos plugins de seguridad activos a la vez suele causar conflictos. Pero si no usas ninguno y tu hosting ofrece uno es una forma rápida de tener lo básico cubierto.

Capa 3: WordPress, tu último bastión de defensa

Las dos capas anteriores filtran la gran mayoría del tráfico malicioso, pero siempre hay peticiones que pasan, como ataques más sofisticados, IPs sin historial malicioso, o intentos dirigidos desde pocas IPs que no disparan los umbrales de la CDN.

Esta capa tiene una ventaja que las otras no tienen, el contexto.

Dentro de WordPress sabes quién está intentando entrar, qué usuario están probando, cuántos intentos llevan, qué están haciendo exactamente, y puedes tomar decisiones basándote en información muy concreta.

Voy a organizar esta sección por estrategias de defensa, de menor a mayor impacto, y en cada una te doy las herramientas gratuitas con las que puedes aplicarla.

Igual que en las capas anteriores, de lo preventivo a lo reactivo, del perímetro al último recurso.

Limitar los intentos de login

• Qué consigues: que un bot no pueda probar miles de combinaciones de usuario y contraseña sin consecuencias. Después de X intentos fallidos la IP se bloquea temporalmente.
• Cómo funciona: tu plugin de seguridad cuenta los intentos de acceso fallidos desde cada IP. Cuando se supera el umbral que hayas configurado (por ejemplo 5 intentos), esa IP se bloquea durante un tiempo. Si vuelve a intentarlo después del bloqueo y falla otra vez, el siguiente bloqueo es más largo (bloqueo progresivo). Así se desanima a los bots que insisten.
• Configuración recomendada: entre 3 y 5 intentos permitidos, con un primer bloqueo de 15 a 30 minutos y bloqueos progresivos activados.
• Con qué puedes hacerlo:
  • Vigilante: puedes configurar el límite de intentos, los bloqueos progresivos y recibes avisos por email de los bloqueos. También oculta los mensajes de error de la pantalla de acceso, para no revelar si un usuario existe o no (dato que los atacantes aprovechan para afinar sus ataques).
  • Limit Login Attempts Reloaded: plugin ligero y centrado solo en esto. Si no quieres un plugin de seguridad completo y solo buscas limitar los intentos este es el más popular y funciona bien.
• Pros: medida fundamental que frena a la mayoría de bots simples y fácil de configurar.
• Contras: si el ataque viene de miles de IPs rotativas (una botnet) cada IP solo necesita un par de intentos y nunca llega al umbral de bloqueo. Para ataques distribuidos esta medida por sí sola no es suficiente, necesitas las capas anteriores.

Proteger el acceso a wp-login

• Qué consigues: que los bots no encuentren la página de acceso estándar de WordPress. Si no la encuentran no la atacan, y buscan otras.
• Cómo funciona: cambias la URL de login de WordPress por una personalizada que solo tú conozcas. En vez de tudominio.com/wp-login.php tu acceso estará en tudominio.com/lo-que-tu-quieras. Los bots que buscan wp-login.php automáticamente se encuentran con un error 404 y se van.
• Con qué puedes hacerlo:
  • Vigilante: activa la URL de acceso personalizada y elige una dirección que puedas recordar. Tienes la opción de informar por email a todos los usuarios a los que les afecte el cambio.
  • WPS Hide Login: plugin muy ligero que hace solo esto. Buena opción si no necesitas un plugin de seguridad más completo.
• Pros: reduce el ruido de ataques automatizados de forma considerable. Los bots buscan wp-login.php por defecto y si no lo encuentran, no insisten.
• Contras: esto es seguridad por oscuridad, no seguridad real. Un atacante determinado puede encontrar tu URL de login de otras formas (redireccionando a wp-admin, por ejemplo). No sustituye a las demás medidas, pero complementa.

Identificación en dos pasos (2FA)

Qué consigues: que aunque un atacante adivine tu contraseña no pueda entrar. Es la medida individual con más impacto contra ataques de fuerza bruta. El 2FA convierte la fuerza bruta en un ataque completamente inútil contra tu cuenta.

• Cómo funciona: después de introducir usuario y contraseña correctos, necesitas un segundo factor de verificación: un código temporal que se envía a tu email, una app de autenticación en tu móvil o una llave de seguridad física. Sin ese segundo factor el acceso no se completa.
• Configuración recomendada: actívalo como mínimo para todos los administradores. Si tienes editores o autores actívalo también para ellos. Puedes activar la opción de dispositivos de confianza para no tener que verificar cada vez que entras desde tu equipo habitual.
• Con qué puedes hacerlo:
  • Vigilante: incluye 2FA por correo electrónico. Cuando inicias sesión, recibes un código de un solo uso. Puedes configurar dispositivos de confianza para 30 días y forzar el 2FA por roles.
  • Two-Factor: plugin de referencia para 2FA en WordPress, desarrollado por colaboradores del núcleo de WordPress. Admite apps TOTP (Google Authenticator, Authy), códigos por email, llaves de seguridad U2F y códigos de respaldo. Si prefieres 2FA con app de verificación en vez de por email esta es la opción gratuita más completa.

Puedes usar Two-Factor junto con Vigilante sin problemas desactivando el 2FA de Vigilante y usar Two-Factor para gestionarlo.

• Pros: efectividad prácticamente absoluta. El 2FA hace que la fuerza bruta sea irrelevante como método para robar credenciales.
• Contras: añade un paso más al login lo que puede resultar incómodo. Si usas 2FA por email y tu servidor de correo falla puedes quedarte fuera de tu propia web (por eso los códigos de respaldo son importantes). Para webs con muchos usuarios (tiendas, membresías) forzar 2FA a todos puede generar quejas. Inicialmente actívalo solo para perfiles con permisos altos y, sobre todo, que puedan acceder a wp-admin, no a clientes por ejemplo.

Política de contraseñas y gestión de usuarios

• Qué consigues: eliminar el eslabón más débil de la cadena, que suele ser una contraseña mala o una cuenta con un nombre predecible. El 80 % de los ataques con éxito a WordPress se basan en contraseñas débiles o robadas.
• Qué hacer:
  • Bloquear nombres de usuario predecibles: impide que existan usuarios con nombres como «admin«, «test«, «root» o «administrator«, son los primeros que prueban los bots.
  • Forzar contraseñas seguras: un mínimo de 12 a 16 caracteres, con mezcla de tipos. Usa un gestor de contraseñas (Bitwarden es gratuito y funciona muy bien).
  • No reutilizar contraseñas: si tu contraseña de WordPress es la misma que la de tu email, un atacante que consiga una tiene las dos.
  • Caducidad de contraseñas: obliga a cambiarlas periódicamente, sobre todo en entornos con varios usuarios.
  • Gestión de sesiones: controla cuántas sesiones simultáneas puede tener un usuario y cierra las que no reconozcas.
• Con qué puedes hacerlo:
  • Vigilante: puedes bloquear nombres de usuario inseguros, forzar contraseñas con longitud mínima, configurar caducidad de contraseñas con intervalos personalizados, activar historial de contraseñas para evitar reutilización, y gestionar sesiones activas.
  • Manualmente: si no usas un plugin de seguridad al menos crea un nuevo usuario administrador con un nombre no predecible, asígnale todo el contenido del usuario «admin«, y elimina ese usuario «admin«. Es un cambio de dos minutos que reduce los intentos exitosos de forma considerable.

Cortafuegos a nivel de aplicación

• Qué consigues: una capa de protección dentro de WordPress que analiza cada petición y bloquea las que tengan patrones maliciosos, antes de que WordPress las procese completamente.
• Cómo funciona: el cortafuegos del plugin examina cada petición HTTP en busca de inyecciones SQL, ataques XSS, intentos de inclusión de archivos, exploración de directorios y otros patrones de ataque conocidos. También permite crear listas de IPs y User-Agent permitidos o bloqueados.
• Con qué puedes hacerlo:
  • Vigilante: incluye cortafuegos con protección contra SQL injection, XSS, LFI/RFI, limitación de tráfico, y listas blancas/negras de IPs y User-Agents. Puedes añadir IPs a la lista negra directamente desde el registro de actividad con un clic.
  • Wordfence (versión gratuita): cortafuegos bastante completo con escáner de malware. El pero es que su versión gratuita retrasa las reglas de cortafuegos 30 días respecto a la versión de pago, pero como cortafuegos gratuito funciona.
• Importante: no instales más de un plugin con cortafuegos a la vez. Elige uno.
• Pros: añade protección contra tipos de ataque que van más allá de la fuerza bruta (inyecciones, XSS, exploración de archivos).
• Contras: un cortafuegos dentro de WordPress consume recursos de PHP en cada petición. Si el grueso del tráfico malicioso ya está filtrado por el CDN y el hosting, este cortafuegos solo procesa las peticiones que se han colado, lo que minimiza el impacto. Pero si es tu única capa de defensa la carga puede ser importante bajo un ataque fuerte.

Registro de actividad y monitorización

• Qué consigues: visibilidad total sobre lo que pasa dentro de tu WordPress. Sin un registro de actividad muchos ataques pasan desapercibidos hasta que ya han causado daño.
• Cómo funciona: el plugin registra todos los eventos relevantes. Puedes vigilar intentos de acceso (correctos y fallidos), cambios en usuarios, modificaciones de contenido, activaciones de plugins, amenazas bloqueadas, y además podrás filtrar, buscar patrones y exportar los datos.
• Qué es relevante para fuerza bruta:
  • Qué usuarios están siendo atacados (si prueban «admin» y no tienes ese usuario bien, si prueban tu usuario real es que hay un problema mayor).
  • Desde qué IPs vienen los intentos (para bloquearlas en el CDN o en el hosting).
  • Si hay intentos coordinados desde varios orígenes (indicio de botnet).
  • Si alguien ha conseguido entrar (un login con éxito que no reconoces es señal de alarma inmediata).
• Con qué puedes hacerlo:
  • Vigilante: registro de actividad completo con filtros por tipo de evento, gravedad, método HTTP y fecha y exportación a CSV. Desde cada registro puedes añadir la IP o el User-Agent a la lista blanca o negra del cortafuegos con un clic, y tiene enlaces directos a AbuseIPDB para verificar las IPs. Configura la retención a 30 días como equilibrio entre información útil y espacio en base de datos.
  • WP Activity Log: plugin especializado en el registro de actividad, muy detallado. Si usas un plugin de seguridad sin registro de actividad es un buenísimo complemento.
• Pros: te permite tomar decisiones informadas en vez de actuar a ciegas. Detectas patrones, respondes rápido y aprendes de cada ataque.
• Contras: los registros consumen espacio en la base de datos. Configura un periodo de retención razonable y no acumules meses de logs innecesarios.

Proteger vectores secundarios

• Qué consigues: cerrar puertas laterales que los atacantes pueden usar para obtener información o acceder a tu web sin pasar por el login.
• Qué vectores proteger:
  • API REST y enumeración de usuarios: por defecto la API REST de WordPress expone la lista de usuarios de tu web en /wp-json/wp/v2/users. Un atacante puede obtener nombres de usuario reales y usarlos en ataques de fuerza bruta dirigidos. Bloquea esta exposición para usuarios no verificados.
  • Cabeceras de seguridad: configurar Content Security Policy (CSP), HSTS, X-Frame-Options y otras cabeceras reduce la superficie de ataque general de tu web. No impide la fuerza bruta directamente pero dificulta otros tipos de ataque que pueden complementarla.
  • Archivos sensibles: protege el acceso a .htaccess, wp-config.php, readme.html y otros archivos que pueden revelar información de tu instalación.
• Con qué puedes hacerlo:
  • Vigilante: incluye control de la REST API (tres modos: público, solo autenticados, selectivo), configuración completa de cabeceras de seguridad con herramienta de prueba integrada, y protección de archivos sensibles.
  • AIOS: plugin de seguridad muy completo que incluye protección contra muchos de estos otros vectores de ataque.

Tu último recurso: modo bajo ataque desde la aplicación

Al igual que la CDN tiene su botón de pánico algunos plugins de seguridad tienen el suyo propio dentro de WordPress.

• Qué consigues: reforzar toda la protección de WordPress de golpe cuando estás bajo un ataque que ha conseguido pasar las dos capas anteriores.
• Cómo funciona: es prácticamente lo que hace la CDN pero desde WordPress. Al activarlo se aplican restricciones mucho más agresivas de forma temporal:
  • Desafío JavaScript desde la aplicación
  • Limitación de tráfico muy estricta
  • Bloqueo de métodos HTTP innecesarios
  • Restricción de la REST API
  • Bloqueo total de XML-RPC.
• Con qué puedes hacerlo:
  • Vigilante, que yo sepa ningún otro plugin ofrece esto: el modo bajo ataque aplica todas las restricciones descritas y se desactiva manualmente, o automáticamente a las 4 horas para que no se te olvide que está activo. Te avisa por email cuando se activa y cuando se desactiva.
• Pros: respuesta rápida dentro de WordPress sin necesidad de acceder al CDN o al hosting.
• Contras: siendo honesto, si el ataque es volumétrico (miles de peticiones por segundo), este modo no es el lugar donde deberías frenarlo porque cada petición ya ha llegado a PHP y ha consumido recursos del servidor. El modo bajo ataque del CDN es más efectivo porque frena el tráfico antes. Este modo es útil para ataques dirigidos o persistentes de bajo volumen que las capas anteriores no detectan, o como complemento si no tienes CDN.

¿Qué hago si ya me están atacando?

Has montado todas las capas, todo está configurado, y de repente notas que tu web va lenta, ves cientos de intentos de login en el registro de actividad, o tu hosting te avisa de un consumo de recursos anormal.

Estás bajo un ataque de fuerza bruta activo. Esto es lo que tienes que hacer, en orden, desde fuera hacia dentro.

Activa el modo Under Attack de la CDN

Es la respuesta más rápida y efectiva. En Cloudflare activa el modo Under Attack desde el escritorio de tu dominio (o desde la app del móvil si no estás frente al ordenador). En segundos todo el tráfico tiene que superar un desafío JavaScript y el volumen de peticiones a tu servidor cae drásticamente.

Sí, es incómodo para los visitantes legítimos, y sí, afecta al SEO temporalmente, pero ante un ataque activo priorizar la disponibilidad de tu web es lo fundamental. Un par de segundos de espera es infinitamente mejor que una web caída.

Revisa los logs y bloquea desde el hosting

Con la CDN protegiendo el perímetro, entra en el panel de tu hosting y revisa los registros de acceso.

Si ves IPs o rangos que generan mucho tráfico hacia tu login bloquéalas directamente, si el ataque viene mayoritariamente de un país concreto plantéate bloquear ese país temporalmente.

Revisa el registro de actividad en WordPress

Entra en el registro de actividad de tu plugin de seguridad y analiza:

• ¿Están probando un usuario concreto? Si atacan al usuario «admin», elimínalo o cámbiale el nombre.
• ¿Vienen de muchas IPs o de pocas? Si son pocas bloqueo permanente, si son muchas, como de un botnet, mejor bloqueo geográfico.
• ¿Usan un User-Agent específico? Si hay patrón, bloquéalo en el cortafuegos del plugin o del CDN.
• ¿El ataque viene por wp-login.php o por xmlrpc.php? Si es por XML-RPC bloquéalo ya si no lo tenías ya desactivado.

Activa el modo bajo ataque desde WordPress si fuese necesario

Si el ataque persiste a pesar del CDN y los bloqueos del hosting, o si es un ataque de bajo volumen pero muy dirigido, activa el modo bajo ataque de tu plugin de seguridad como refuerzo adicional.

Reorganiza y optimiza tus defensas

Cada ataque te da información para mejorar.

Crea nuevas reglas de seguridad en el CDN basándote en los patrones detectados, ajusta umbrales en el plugin de seguridad, bloquea rangos de IPs persistentes en el hosting.

La seguridad es un proceso continuo, no una configuración que haces una vez.

Errores típicos que todos cometemos

• Confiar únicamente en el plugin de seguridad: un plugin dentro de WordPress es la última capa, no la primera. Si todo el peso de la seguridad recae en un plugin, tu servidor absorbe toda la carga de los ataques antes de que el plugin pueda actuar.
• No usar CDN/firewall externo: un CDN con plan gratuito te da protección a nivel de red que ningún plugin puede ofrecer. No hay excusa para no usarlo.
• Dejar XML-RPC activo sin necesidad: si no usas aplicaciones que lo requieran bloquéalo. Es un vector de ataque demasiado fácil de explotar.
• No monitorizar: si no tienes registro de actividad no sabes lo que pasa en tu web. Muchos ataques son silenciosos hasta que ya han causado daño.
• Bloquear países sin pensar: bloquear países puede ser efectivo, pero hazlo con criterio. Si bloqueas un país donde operan servicios que tu web necesita (pasarelas de pago, APIs de email, herramientas de monitorización) vas a crear problemas que no tienen nada que ver con la seguridad.
• Instalar varios plugins de seguridad: Wordfence + Security Optimizer + Vigilane no te hace más seguro, te hace más lento y con más probabilidades de conflictos. Elige uno, aprende a configurarlo y compleméntalo con las demás capas.
• No tener copias de seguridad: la seguridad puede fallar, y si todo falla y tu web está comprometida necesitas poder restaurar una copia limpia. Haz copias de seguridad periódicas y guardadas fuera de tu servidor.
• No actualizar: WordPress, plugins, temas y PHP. Todo actualizado, siempre. El caso reciente de los 30 plugins comprados y troyanizados a través de Essential demuestra que incluso plugins legítimos pueden convertirse en amenazas. Si un plugin no se actualiza desde hace más de un año búscate un sustituto.

El plan de batalla completo

Aquí tienes el resumen de toda la estrategia, de fuera hacia dentro, con las herramientas recomendadas en cada paso, configura cada punto en orden.

Lo que hay más arriba en cada tabla es lo primero que actúa y lo más eficiente, lo que está más abajo es la última línea de defensa.

Perímetro: CDN

Muralla: hosting

Guarnición: WordPress

Logística: mantenimiento

Todo lo que ves en esta guía lo puedes configurar en menos de una hora usando solo herramientas gratuitas.

No hace falta gastar dinero en licencias de plugins premium para tener una protección sólida contra ataques de fuerza bruta, lo que hace falta es entender dónde poner cada defensa y configurarla bien.

La seguridad no es cómoda, algunas de estas medidas añaden pasos al login, bloquean visitantes de ciertos países, o te obligan a recordar una URL personalizada, pero la alternativa a la seguridad es peor, porque lo que obtienes es una web caída, datos comprometidos u horas limpiando malware.

Cuando el coste de no protegerte es infinitamente mayor que la pequeña molestia de hacerlo, la decisión es fácil. Y recuerda que la seguridad no es algo que configuras una vez y te olvidas.

Revisa tus logs periódicamente, mantén todo actualizado, y ajusta tus defensas cuando detectes patrones nuevos. Cada ataque que analizas te deja mejor preparado para el siguiente.

Por si no lo sabías, ejecuta un cron semanal con docenas de comprobaciones, pinta un widget en el escritorio con sus propias consultas, y cada vez que entras en Herramientas → Salud del sitio dispara una tanda de peticiones a api.wordpress.org y al propio servidor para verificar loopback, HTTPS y unas cuantas cosas más.

¿A que ni lo imaginabas?

En una web con hosting decente no vas a notarlo, pero en un hosting compartido justito o en un servidor que va al límite igual lo notas ¿o no te has fijado lo que tarda en cargar el widget de salud del sitio del escritorio a veces o lo que tarda en cargar la herramienta?

A veces puedes notar que la semana que le toca ejecutarse deja el admin lento durante unos segundos, que el widget del escritorio ralentiza la entrada al escritorio cada vez que accedes, y no te olvides de las consultas al servidor y la telemetría a WordPress.org.

Pues bien, hoy toca meterle mano y optimizar – también – la herramienta de salud del sitio de WordPress. Aquí te cuento cómo bajarle el volumen sin renunciar a su utilidad, que ni se te ocurra cuestionarla, es imprescindible.

Qué hace Salud del sitio en la trastienda

Hay tres cosas ejecutándose en momentos distintos:

• El cron wp_site_health_scheduled_check, que se lanza una vez por semana y ejecuta todos los tests (loopback, HTTPS, versión de PHP, versión de MySQL, comunicación con WordPress.org, etc.).
• El widget estado de salud del sitio del escritorio, que consulta un transient y, si no existe, lanza las comprobaciones al vuelo.
• Los tests asíncronos que se disparan vía API REST cuando abres la pantalla de salud del sitio.

Los tres se pueden intervenir por separado, y lo ideal es tocar solo lo que esté molestando.

Quitar el cron semanal

Si quieres desactivar la comprobación programada añade esto a un mu-plugin:

/* Quitar la comprobación semanal de salud del sitio */
function ayudawp_remove_site_health_cron() {
    $timestamp = wp_next_scheduled( 'wp_site_health_scheduled_check' );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, 'wp_site_health_scheduled_check' );
    }
}
add_action( 'init', 'ayudawp_remove_site_health_cron' );

Con eso el cron deja de reprogramarse y te ahorras la tanda semanal de comprobaciones, que incluye varias llamadas HTTP externas. Si algún día quieres volver, comenta las líneas o desinstala el snippet y WordPress lo reprograma solo.

Mientras tanto, por supuesto, la herramienta sigue funcionando, solo tienes que visitar su página para que funcione normalmente.

Quitar el widget del escritorio

El widget del escritorio es el que más lata da en el día a día porque lo ves cada vez que entras al admin, pero es que tarda siempre algo, a veces mucho. Para eliminarlo…

/* Quitar el widget de escritorio de salud del sitio */
function ayudawp_remove_site_health_widget() {
    remove_meta_box( 'dashboard_site_health', 'dashboard', 'normal' );
}
add_action( 'wp_dashboard_setup', 'ayudawp_remove_site_health_widget' );

Sigues pudiendo entrar a Herramientas → Salud del sitio cuando te haga falta, pero dejas de cargarlo al escritorio sin pedirlo.

Quitar tests concretos que dan guerra

A veces no quieres matar salud del sitio entera, solo los tests que marcan falsos positivos en tu hosting.

Los dos clásicos son la comprobación de loopback (que falla en entornos con Basic Auth o cortafuegos que bloquean peticiones internas) y la de HTTPS. Con el filtro site_status_tests los quitas uno a uno:

/* Quitar tests específicos de salud del sitio */
function ayudawp_remove_site_health_tests( $tests ) {
    unset( $tests['async']['loopback_requests'] );
    unset( $tests['async']['https_status'] );
    unset( $tests['direct']['available_updates_disk_space'] );
    return $tests;
}
add_filter( 'site_status_tests', 'ayudawp_remove_site_health_tests' );

Los tests async son los que lanzan llamadas HTTP, así que cada uno que quites baja el coste de abrir la pantalla de salud del sitio. Los direct se ejecutan en el mismo hilo.

Cuándo merece la pena meterle mano

Si tu hosting va sobrado no toques nada. Tener el chequeo activo es útil para detectar versiones de PHP obsoletas o problemas de correo antes de que alguien se queje.

En cambio, sí merece la pena intervenir cuando:

• El admin va lento y Query Monitor te señala el widget o los endpoints site-health como culpables.
• Tienes avisos en rojo de loopback o HTTPS que son falsos positivos del hosting y no puedes arreglarlos.
• Estás preparando un pico de tráfico y quieres desactivar todo el cron no crítico durante unos días.

Y si esto te ha interesado, échale un ojo también a los trucos de optimización de admin que tengo publicados en la categoría de WPO del blog, que van en la misma línea de ganar rendimiento con snippets pequeños que hacen cosas grandes.

El pedido HPOS ‘sincronizar al leer’ se ha desactivado

Si no sabes qué es eso ni si te afecta, tranqui, vamos a verlo con calma.

¿Y esto de qué va, he roto algo?

Si no tienes claro qué es HPOS te recomiendo que leas primero la guía básica de HPOS y por qué deberías activarlo.

El resumen rápido es que el HPOS hace que los pedidos de WooCommerce se almacenen en tablas propias en vez de usar las tablas wp_posts y wp_postmeta de WordPress, que es donde históricamente se ha metido todo.

Cuando activas HPOS y el modo de compatibilidad a la vez, WooCommerce mantiene los datos de pedidos sincronizados en ambos sitios (las tablas nuevas y las antiguas).

La idea es que si algún plugin o código personalizado todavía tira de las tablas antiguas, nada se rompa, lo cual, ante un sistema nuevo, es una muy buena idea.

Esa sincronización funciona en dos direcciones:

• La primera y más obvia es de HPOS hacia las tablas de entradas: Cada vez que un pedido se crea o se modifica a través de WooCommerce, los datos se copian también a wp_posts y wp_postmeta. Esa dirección sigue funcionando exactamente igual que antes.
• La segunda es la que cambia, y es esta ya famosa «sincronización al leer» (sync on read): Este mecanismo funcionaba al revés. Si algo modificaba los datos del pedido directamente en la tabla de entradas, saltándose WooCommerce por completo (con un wp_update_post, un update_post_meta o una consulta SQL directa), WooCommerce comparaba las marcas de tiempo de ambos registros al leerlos. Si la copia en la tabla de entradas era más reciente, asumía que alguien había escrito ahí y actualizaba las tablas HPOS para que coincidieran.

¿Es que ha cambiado algo desde WooCommerce 10.7?

Pues sí, desde la versión 10.7 (publicada el 14 de abril de 2026) esa sincronización al leer viene desactivada por defecto.

El motivo es que podía provocar problemas, porque si un dato antiguo en la tabla de entradas tenía una marca de tiempo rara, WooCommerce lo interpretaba como un cambio legítimo y sobreescribía los datos buenos de HPOS. Esto causaba cosas como reversiones de estado de pedido o datos antiguos machacando a los actuales.

Con el sistema de almacenamiento HPOS ya maduro y adoptado por la mayoría de tiendas, el equipo de WooCommerce ha decidido que mantener este mecanismo activo por defecto hace más mal que bien.

La tabla de entradas siempre estuvo pensada como copia de solo lectura, no como fuente de verdad alternativa.

¿A quién le afecta esto?

Aparte de a mi, que por eso te estoy escribiendo y compartiendo lo que me ha tocado aprender, en realidad a muy pocos.

Si en tu tienda usas solo plugins compatibles con HPOS (que a estas alturas son la gran mayoría) este cambio no te afecta en nada. La sincronización normal de HPOS hacia las tablas antiguas sigue funcionando.

Te afecta si cumples estas dos condiciones a la vez:

1. Tienes HPOS activo con el modo de compatibilidad habilitado.
2. Además usas código personalizado o algún plugin que escribe datos de pedido directamente en las tablas wp_posts o wp_postmeta (con funciones como wp_update_post(), update_post_meta() o consultas SQL directas) esperando que esos cambios se reflejen automáticamente en HPOS.

Si no tienes claro si te afecta, hazte estas preguntas:

• ¿Tienes funciones personalizadas en tu functions.php o en mu-plugins que modifiquen datos de pedidos con update_post_meta()?
• ¿Usas algún plugin de gestión de pedidos que no se haya actualizado en mucho tiempo?
• ¿Has escrito consultas SQL directas que toquen la tabla wp_postmeta para campos de pedidos?

Si la respuesta a todo es «NO» puedes descartar el aviso y seguir con tu vida.

¿Y qué hago si me afecta?

Lo primero y más importante es actualizar tu código para que use la capa CRUD de WooCommerce en vez de escribir directamente en las tablas de entradas. Esto ya se recomienda desde WooCommerce 3.0 (que salió en 2017), así que si todavía no lo has hecho va siendo hora.

En la práctica eso significa sustituir cosas como:

// Lo que ya no deberías usar
update_post_meta( $order_id, '_billing_email', 'nuevo@email.com' );

Por el equivalente con los objetos de WooCommerce:

// Lo correcto
$order = wc_get_order( $order_id );
$order->set_billing_email( 'nuevo@email.com' );
$order->save();

Si necesitas tiempo para hacer esos cambios puedes reactivar temporalmente la sincronización al leer con este filtro:

// Reactivar sincronización al leer (solución temporal)
add_filter( 'woocommerce_hpos_enable_sync_on_read', '__return_true' );

Pero ojo, esto es un parche temporal. El equipo de WooCommerce ha avisado de que la sincronización al leer podría eliminarse por completo en una versión futura, así que no te acostumbres.

Pues sí, debes activar HPOS sin compatibilidad en cuando puedas

Si tu tienda lleva un tiempo con HPOS activo, todos tus plugins son compatibles y todo funciona bien, lo mejor que puedes hacer es desactivar el modo de compatibilidad directamente.

Ve a WooCommerce > Ajustes > Avanzado > Características y desactívalo. Así WooCommerce deja de duplicar datos en las tablas antiguas y te ahorras el peso de esa sincronización en cada operación con pedidos.

Eso sí, antes de hacerlo asegúrate de tener una copia de seguridad y de haber comprobado que nada depende de las tablas clásicas.

Si te surge algún problema siempre puedes volver a activar el modo de compatibilidad, esperar a que se sincronice todo y cambiar de vuelta. Aquí tienes la guía de dudas habituales sobre HPOS donde explico el proceso con más detalle.

¿Y las mejoras de rendimiento de WooCommerce?

Además de este cambio en la sincronización, la versión de WooCommerce 10.7 incorporó mejoras de rendimiento bastante interesantes para tiendas con HPOS activo.

La más llamativa es que las consultas de la API REST para pedidos han bajado de 271 a 132 por petición, un 51% menos, gracias a un sistema de precarga de caché que elimina las consultas N+1 durante la serialización.

El pago también reduce un 15% las consultas SQL totales. Si tienes HPOS activado y tu tienda mueve volumen, esta actualización se nota.

Lo que tienes que hacer ahora

Hay varias posibilidades, que te resumo:

• Si ves el aviso en tu escritorio y todo funciona bien, simplemente descártalo.
• Si tienes dudas sobre si tu código personalizado escribe directamente en las tablas de entradas, revísalo.
• Si llevas tiempo con HPOS sin problemas plantéate desactivar el modo de compatibilidad para sacarle todo el jugo al rendimiento.

Para cualquier duda sobre compatibilidad de plugins con HPOS echa un vistazo a este artículo donde explico cómo declarar la compatibilidad o me preguntas en la sección de comentarios, que para eso está.

1. Alguien descubre Claude Code, Cursor, Lovable o cualquier herramienta de vibe coding, o eso dice.
2. Monta un sitio web en una tarde, lo despliega gratis en Vercel, o eso cuenta.
3. Y proclama con orgullo que nunca más va a tocar WordPress.

Los comentarios se llenan de gente celebrándolo, los likes suben, la historia no puede ser más potente. Y, sí, tiene en parte razón, como todo en la vida.

Pero hay un detalle que estos posts nunca cuentan, y es qué pasa en la semana 2, en el mes 3, cuando llega la primera actualización de seguridad, cuando el cliente quiere cambiar un texto o cuando Google indexa el sitio y no encuentra ni estructura ni mapa del sitio.

Si has leído mi tutorial sobre cómo crear un plugin WordPress sin saber programar este artículo bien podría que sea de lectura obligatoria para no venirte demasiado arriba. Y es que una cosa es que puedas hacerlo y otra muy distinta es que debas hacerlo siempre, para todo y sin criterio.

Vamos a leer el cuento, sin dramas y con datos, si es que los hay.

Adios WordPress

El post que más repercusión ha tenido últimamente es uno titulado «Bye bye WordPress» en el subreddit de Claude Code, que acumuló más de 360 votos positivos. El autor contó cómo había migrado dos sitios de clientes a Astro y React, los había desplegado en Vercel sin coste y se había despedido de WordPress para siempre.

La historia es irresistible ¿verdad?, porque tomas una herramienta que todo el mundo conoce (WordPress), la sustituyes por algo nuevo y brillante (IA + framework moderno), y encima te ahorras el hosting (teóricamente).

El David contra Goliat de toda la vida, aplicado al desarrollo web, si obviamos detalles tan poco relevantes (léase la ironía) como que WordPress es Open Source y un proyecto de comunidad (el auténtico David) y las alternativas son en su mayoría siempre aplicaciones cerradas y propietarias (el verdadero Goliat), pero bueno, molar mola.

Luego, si te paras a leer los comentarios con calma también ahí la cosa cambia:

• Propietarios de agencias que explican que sus clientes necesitan landing pages, formularios con lógica, campañas de email y seguimiento, funcionalidades que no vas a replicar con vibe coding en una tarde.
• Desarrolladores experimentados avisando de los problemas que vienen después.
• Gente que directamente dice que están usando la IA no para abandonar WordPress, sino para hacerlo mejor y más rápido.

Es un debate que merece la pena, pero con todos los datos sobre la mesa, no solo con la captura de pantalla del momento en que todo funciona.

Pues sí, tienen parte de razón

Seamos sinceros desde el principio, porque no voy a ponerme a defender WordPress ciegamente. Sí, lo he dicho yo.

Para un sitio estático de cinco páginas tipo tarjeta de visita, con un formulario de contacto y poco más, WordPress siempre fue como usar un cañón para cazar moscas para webs simples, pero no a partir de la IA generativa, siempre.

Un CMS completo con base de datos, sistema de usuarios, panel de administración, actualizaciones periódicas, para mostrar una dirección, un teléfono y cuatro fotos. Ahí el vibe coding, una plantilla HTML, el bloc de notas incluso, tienen todo el sentido del mundo.

Si lo único que necesitas es un sitio estático que no va a cambiar en meses, que no necesita que nadie sin conocimientos técnicos lo edite y que básicamente es un escaparate digital, usar la IA para generarlo y desplegarlo en un hosting gratuito es una opción perfectamente válida.

Ese caso de uso, que es totalmente lógico y que responde a montones de necesidades, probablemente representa un 15 o 20 por ciento del mercado de WordPress, y posiblemente no debería. Para el otro 80 por ciento la historia cambia, mucho.

El día después de la euforia

El post viral típico termina en el momento perfecto, y es cuando todo funciona. La demo está bonita, el despliegue ha ido bien, la captura de pantalla queda espectacular.

Lo que nadie cuenta es lo que viene después, y es bastante menos viral.

Esas puñeteras dependencias

Tu flamante sitio generado con IA probablemente usa React, Astro, Next.js o algún framework de JavaScript moderno, y estos frameworks evolucionan a un ritmo brutal. Next.js saca versiones mayores cada pocos meses, y no son cambios cosméticos, son cambios que rompen cosas.

Tu sitio que hoy funciona perfectamente puede dejar de compilar con la siguiente versión del framework, o del runtime de Node, o de cualquiera de las decenas de dependencias que tiene por debajo.

Con WordPress las actualizaciones siguen ciclos predecibles y las puedes hacer desde el admin sin tocar código, incluso de manera automática. Y si algo falla hay miles de guías y una comunidad enorme para ayudarte. Con tu sitio vibe-coded cuando algo se rompe estás tú a solas con tu prompt y tus ganas.

¡Ahhh los cambios!

Tu cliente, tu jefe o tú mismo quieres cambiar un texto del pie de página, y esto con WordPress abres el editor, lo cambias y listo. Con un sitio generado por IA tienes que abrir el código, encontrar el archivo correcto, modificarlo, volver a desplegar y rezar para que no se rompa nada por el camino. O volver a pedirle a la IA que lo cambie, que a veces lo clava y a veces te reorganiza medio proyecto, o te cambia la codificación de caracteres, a veces te hace perder horas para un simple cambio de un texto.

Para un desarrollador esto no es problema, para el dueño de una peluquería que quiere actualizar sus horarios de verano, es una putada y gorda.

La factura de tokens ¿ah pero esto no era gratis?

Generar el sitio inicial puede costarte unos pocos euros en tokens. pero cada vez que necesitas un cambio, una corrección, una nueva funcionalidad o un arreglo, vuelves a pasar por caja. Y el coste se acumula rápido, sobre todo si el proyecto crece.

Hay un caso que circula por la comunidad de desarrollo que lo ilustra a la perfección, el de un desarrollador que decidió crear un blog desde cero con IA, prescindiendo de cualquier CMS.

El resultado fueron cientos de miles de líneas de código generado, un gasto considerable en tokens y cero escalabilidad para algo que con WordPress tenía gratis, mantenido por una comunidad de millones de personas y con un ecosistema de plugins que cubre prácticamente cualquier necesidad.

El espejismo del hosting gratuito

Uno de los argumentos estrella de los posts virales es «y encima lo despliego gratis en Vercel«. Suena genial, pero tiene trampa.

Los planes gratuitos de Vercel, Netlify y similares están diseñados para proyectos personales y prototipos. Tienen límites de ancho de banda, de proyectos mensuales y de funciones.

Cuando tu sitio empieza a recibir tráfico real esos límites se alcanzan rápido y entonces toca pasar por caja, y los planes de pago de estas plataformas no son precisamente baratos comparados con un hosting WordPress de calidad.

Además, con un hosting WordPress especializado no solo tienes espacio en un servidor, tienes copias de seguridad automáticas, certificados SSL gestionados, CDN integrado, entorno de staging para probar cambios, soporte técnico que entiende tu plataforma y optimizaciones específicas para WordPress. El hosting «gratuito» para tu sitio vibe-coded no te da nada de eso, es un servidor que sirve archivos estáticos, y encima estás solito como un pollito.

La seguridad es esa cosa que no sabes que no sabes

Este es el punto donde la cosa se pone seria de verdad, y donde menos se para a pensar la gente que celebra el vibe coding como sustituto de WordPress.

Los datos son claros y poco tranquilizadores, porque según todos los estudios que se están haciendo estas herramientas como ChatGPT y GitHub Copilot generan código correcto solo entre el 46 y el 65 por ciento de las veces. Y no hablamos solo de errores funcionales, hablamos de vulnerabilidades de seguridad, y para que te hagas una idea, un 40 por ciento de las consultas SQL generadas por IA son vulnerables.

No son cifras pequeñas, no es ver el vaso medio vacío, esos porcentajes cuando hablamos de seguridad son una burrada.

Cuando usas WordPress tienes a tu disposición 20 años de batallas de seguridad ganadas (y perdidas, y aprendidas). Tienes un equipo de seguridad dedicado que revisa el código del núcleo. plugins especializados en seguridad que se actualizan constantemente, hosting especializado con medidas de protección integradas, y tienes una comunidad entera que detecta, reporta y parchea vulnerabilidades a diario.

Cuando usas un sitio generado por vibe coding tienes lo que la IA decidió poner. Si no sabes de seguridad web (que es lo normal si estás usando vibe coding precisamente porque no sabes programar) no vas a detectar que tu formulario de contacto es vulnerable a XSS, que tu API no valida los datos de entrada o que tus rutas no tienen protección contra accesos no autorizados.

En WordPress todo el entorno es conocido, las vulnerabilidades se documentan, se parchean y se publican avisos, tu sitio vibecodeado tiene posibles vulnerabilidades que ni tú conoces.

Y sí, es verdad que WordPress es un objetivo frecuente de ataques precisamente porque alimenta al 40% de Internet, pero eso también significa que cualquier vulnerabilidad se detecta rápido y se parchea más rápido todavía, es una plataforma que ha aprendido de cada golpe. Tu sitio generado por IA no ha recibido ningún golpe todavía, y cuando lo reciba, no tiene ni comunidad ni equipo de seguridad detrás para responder.

Piensa que si mañana se descubre una vulnerabilidad en el formulario de contacto de tu sitio WordPress, lo más probable es que el plugin que uses publique una actualización en horas y tú la apliques con un clic. Si la vulnerabilidad está en tu formulario generado por IA, primero tienes que enterarte de que existe (¿cómo?), luego entender dónde está el problema (¿en qué archivo, en qué función?), después generar un parche con la IA que no rompa nada más, y finalmente desplegarlo. Todo eso asumiendo que te enteras antes de que alguien la explote.

¿Estoy diciendo que no se puede generar una web o código seguro con IA?, para nada, si sabes lo que hacer y cómo hacerlo puedes generar algo aseguro. A lo que me refiero es a que estás a solas ante el peligro, y mucho tienes que saber de seguridad para que no se te pase ninguna comprobación importante, y saber cómo revisarla.

Código más viejo que el hilo negro

Hay una frase que resume esto perfectamente y que viene del blog de Val Town:

El vibe coding genera código anticuado a la velocidad a la que la IA lo escupe

Y, es curioso, pero es que ya existe incluso un nombre para este fenómeno entre los desarrolladores profesionales: «vibe coding rescue«, que es básicamente rescatar proyectos generados por IA que funcionan por fuera pero que por dentro son un desastre.

El problema de fondo es que la programación no consiste en generar líneas de código. Programar consiste en entender cómo funciona lo que has construido, en saber por qué una decisión técnica es mejor que otra, en poder modificar el sistema cuando cambian los requisitos sin que todo se venga abajo.

Cuando le pides a una IA que te genere un sitio web completo, obtienes algo que funciona, pero no entiendes cómo funciona. El día que necesitas cambiarlo (que siempre llega), te encuentras con código que ni tú ni nadie puede mantener de forma razonable.

Es como mirar el motor de un coche sin saber de mecánica. Ves las piezas encajadas, pero no sabes cómo se conectan ni por dónde empezar si necesitas cambiar o arreglar algo.

El comentario más votado en aquel famoso post de Reddit donde alguien proclamaba su despedida de WordPress lo decía bien claro, con más votos incluso que el propio post original, es uno que recordaba que con una solución a medida eres tú el responsable de mantener ese código para siempre. Y «para siempre» es mucho tiempo cuando no entiendes lo que tienes entre manos.

Lo peor es que este problema se multiplica con el tiempo. Cada vez que le pides a la IA que añada algo nuevo o que arregle algo, el código crece, se complica y se vuelve más difícil de entender. Y como la IA no tiene una visión global de la arquitectura (trabaja con lo que le metes en el contexto de cada sesión), las decisiones de diseño pueden ser inconsistentes entre una sesión y otra. El resultado es un proyecto que funciona a base de parches superpuestos, donde cada cambio tiene el potencial de romper algo que funcionaba antes.

Con WordPress, incluso si usas código personalizado o plugins a medida, trabajas dentro de una arquitectura conocida y documentada. Los hooks, los filtros, la estructura de la base de datos, las convenciones de nombres, todo sigue un patrón predecible que cualquier desarrollador de WordPress puede entender. Si mañana necesitas contratar a alguien para que mantenga tu sitio, lo puede hacer.

Si mañana necesitas que alguien mantenga tu sitio generado por vibe coding, buena suerte explicándole donde va cada pieza y para qué sirve.

Los bebés crecen, cagoendiez

Hasta aquí todo suena a problemas teóricos, a cosas que podrían pasar, pero es que pasan, y pasan rápido. Porque los proyectos web no se quedan quietos, incluso tú, sin que nadie te lo pida, empiezas a querer más.

Necesitas un blog

Tu sitio estático de cinco páginas está genial, pero ahora quieres publicar artículos para atraer visitas. Necesitas un sistema de contenidos con categorías, etiquetas, paginación, búsqueda interna, feed RSS, URLs amigables, metadatos para SEO, esas pequeñas cosas que damos por hechas.

En WordPress instalas un tema y empiezas a escribir, con vibe coding, acabas de abrir un proyecto de semanas para algo que lleva resuelto desde 2003.

Quieres vender algo

Puede ser un producto digital, un servicio, unas camisetas, pues necesitas pasarelas de pago, gestión de inventario, gastos de envío, impuestos por zona, facturas, devoluciones, emails transaccionales, página de mi cuenta, la leeecheee.

WooCommerce te da todo eso instalando un plugin y configurándolo. Generarlo desde cero con IA es un proyecto de meses con un nivel de complejidad enorme, y con implicaciones legales y de seguridad que no te puedes permitirte ignorar.

Quieres posicionar en Google

Has creado tu sitio pero nadie lo encuentra. Pues hablamos de SEO técnico, y eso supone estructura de encabezados, datos estructurados, mapa del sitio XML, robots.txt, canonical URLs, velocidad de carga, Core Web Vitals, Open Graph para redes sociales, etc, etc, etc.

WordPress tiene plugins que gestionan todo esto con unos clics. Tu sitio generado por IA lo más seguro es que ni siquiera tenga un mapa del sitio salvo que lo generes aparte, y te acuerdes de actualizarlo.

Tienes que cumplir con el RGPD

En cuanto tu sitio recoge datos (y un simple formulario de contacto ya lo hace) necesitas banner de cookies configurable, política de privacidad, gestión del consentimiento, derecho de acceso y supresión de datos, registro de consentimientos y demás.

En WordPress hay plugins especializados que se actualizan cada vez que cambia la normativa. Con vibe coding, cada requisito legal es código que tienes que generar, revisar, mantener y actualizar tú.

Necesitas varios idiomas

Tu proyecto crece y quieres llegar a más mercados, y toca traducir contenidos, gestionar las relaciones entre idiomas, los selectores de idioma, las URLs por idioma, el puñeterohreflang.

En WordPress hay plugins consolidados que lo resuelven de manera totalmente profesional y con actualizaciones frecuentes, pero generarlo desde cero es una pesadilla técnica que multiplica la complejidad de todo el proyecto.

Accesibilidad

Desde junio de 2025 la Ley Europea de Accesibilidad obliga a muchos negocios digitales a cumplir con requisitos de accesibilidad web. WordPress tiene un equipo dedicado a accesibilidad, temas que cumplen WCAG y plugins específicos para auditar y mejorar la accesibilidad de tu sitio.

Con vibe coding la accesibilidad depende enteramente de lo que la IA haya decidido implementar, que en la mayoría de los casos no incluye ni etiquetas ARIA adecuadas, ni contraste suficiente, ni navegación por teclado correcta.

Cada una de estas necesidades, por separado, ya es un buen motivo para replantearte si tu sitio generado por IA da la talla. Juntas son una lista de tareas pendientes que crece más rápido de lo que la IA puede resolverlas.

La gente pide cosas…

Aquí viene la segunda derivada, y la más peligrosa. Porque hay un paso que mucha gente da sin pensarlo demasiado, me refiero a que tu sitio generado con IA te ha quedado bien, funciona, has aprendido un montón en el proceso, y decides que puedes ofrecer esto como servicio. Hacer webs para otros con vibe coding, sin WordPress, a un precio competitivo y con la velocidad de la IA como argumento de venta.

Suena bien en la teoría, pero en la práctica los problemas que ya tenías con tu propio proyecto se multiplican por cada cliente que añades.

El cliente quiere editar su propia web

Y no sabe de código, ni quiere saber, ni tiene por qué saber, pero se empeña en querer cambiar el horario de verano de su negocio, subir una foto nueva, publicar una oferta. Con WordPress le das acceso al escritorio, le enseñas dónde está el editor en diez minutos y se apaña solo.

Con tu sitio vibe-coded, cada cambio de texto es una llamada que te hacen a ti, o una sesión con la IA que pagas tú, o un despliegue que gestionas tú. Multiplica eso por cinco clientes y ya tienes un trabajo a tiempo completo solo en cambios menores.

Se cae a las tres de la mañana

El sitio de un cliente deja de funcionar un viernes por la noche, cosas que pasan.

Con WordPress en un hosting especializado, probablemente tiene copias de seguridad automáticas diarias que puedes restaurar con un par de clics, además de un equipo de soporte disponible 24/7 que conoce la plataforma.

Con un sitio vibe-coded desplegado en Vercel o Netlify, tienes los logs del servidor (si sabes dónde buscarlos), la documentación del framework (si sabes cuál es el problema) y tu herramienta de IA (si tienes saldo de tokens). A las tres de la mañana, con el teléfono del cliente echando humo. ¡Nahhh, cosas menores! ¿o no?

Otro desarrollador tiene que tomar el relevo

Tú te vas de vacaciones, cambias de trabajo o simplemente dejas de trabajar con ese cliente y alguien tiene que encargarse del sitio. Porque te puedes tomar unos días ¿no?

Con WordPress, le pasas los accesos y en media hora está orientado, sabe dónde está todo, conoce la estructura, entiende los plugins.

Con un sitio generado por IA, le estás pasando miles de líneas de código sin documentar, con una arquitectura que ni tú mismo elegiste conscientemente, y sin ninguna garantía de que las decisiones técnicas sean coherentes entre sí. Ese desarrollador va a tardar más en entender lo que hay que en crearlo de nuevo.

Varios clientes, cero estandarización

Con WordPress cada proyecto nuevo parte de la misma base, tienes el mismo CMS, las mismas convenciones de todo, el mismo panel de administración. Puedes crear procesos, reutilizar configuraciones, formar a un equipo.

Con vibe coding cada proyecto es un mundo aparte. La IA puede tomar decisiones diferentes cada vez, usar estructuras distintas, nombrar las cosas de formas incompatibles, tiene esas cosas, por mucho que te empeñes en darle instrucciones es, por diseño, inconsistente, digámoslo de otro modo, por ponernos poéticos, digamos que la IA «vive el momento».

Gestionar cinco proyectos vibe-coded a la vez es gestionar cinco bases de código completamente diferentes sin ningún denominador común.

Ofrecer sitios generados por IA como servicio profesional sin una plataforma detrás que unifique la gestión, el mantenimiento y la seguridad es asumir una responsabilidad enorme con herramientas que no están pensadas para eso.

Lo que WordPress ya te da resuelto (y que no valoras hasta que lo pierdes)

Cuando llevas años usando WordPress es fácil dar por sentado todo lo que el ecosistema te ofrece. Pero cuando intentas replicarlo desde cero con vibe coding, te das cuenta de la magnitud de lo que tienes gratis:

• Sistema de gestión de contenidos completo, con editor visual, revisiones, borradores programados, papelera y gestión de medios. Algo que parece sencillo hasta que intentas construirlo.
• Sistema de usuarios y permisos con roles diferenciados (administrador, editor, autor, colaborador, suscriptor) y la posibilidad de crear roles personalizados.
• Ecosistema de más de 60.000 plugins que cubren desde SEO hasta comercio electrónico, pasando por seguridad, rendimiento, formularios, copias de seguridad, analítica y prácticamente cualquier necesidad que se te ocurra.
• Miles de temas profesionales, responsivos, accesibles y optimizados para SEO, muchos de ellos gratuitos.
• Hosting especializado con configuraciones optimizadas, copias de seguridad automáticas, certificados SSL, CDN integrado y soporte técnico que entiende WordPress.
• Comunidad global de desarrolladores, diseñadores y usuarios que generan documentación, tutoriales, foros de soporte, meetups y WordCamps en todo el mundo.
• Actualizaciones automáticas de seguridad del núcleo, con un equipo dedicado que responde ante vulnerabilidades.
• Internacionalización nativa, preparado para ser traducido a cualquier idioma con herramientas estándar.
• API REST completa que permite usar WordPress como backend para aplicaciones modernas, incluidas las headless.
• Accesibilidad incorporada, con un equipo específico dentro del proyecto WordPress que trabaja para que el CMS cumpla con las directrices WCAG.

Todo esto no apareció de la noche a la mañana. Son 20 años de desarrollo, de prueba y error, de millones de sitios en producción exponiendo problemas y generando soluciones. Pretender replicarlo con unos cuantos prompts no es ambicioso, es no entender la magnitud del problema.

Software libre frente a dependencia de plataformas

Hay un argumento de fondo que casi nunca aparece en los posts virales de «¡Adiós WordPress!«, y que para mí es de los más importantes. Me refiero a la cuestión de la libertad.

WordPress es software libre, licenciado bajo GPL. Eso significa que el código es tuyo, que puedes modificarlo, redistribuirlo, usarlo para lo que quieras sin pedir permiso a nadie. No dependes de una empresa que pueda cambiar las condiciones, subir los precios o cerrar el servicio mañana.

Si desaparece Automattic WordPress sigue existiendo, si desaparece tu empresa de hosting te llevas tu sitio a otro servidor y listo. Tu contenido, tu código, tus datos son tuyos de verdad.

Ahora piensa en el escenario del vibe coding… Tu sitio depende de una herramienta de IA propiedad de una empresa privada.

Si mañana Anthropic cambia los precios de Claude, si OpenAI modifica las condiciones de uso de su API, si Cursor AI cambia su modelo de suscripción o si Vercel decide que el plan gratuito ya no le sale rentable, tu método y herramientas de trabajo se van a la mierda.

No tienes control sobre ninguna de esas piezas. Estás construyendo sobre un terreno alquilado, y el propietario puede cambiar las reglas cuando quiera.

Y no es solo una cuestión práctica, es también una cuestión de principios. WordPress nació del software libre y sigue siéndolo, la licencia GPL garantiza que las libertades que tienes hoy las van a tener las generaciones que vengan después.

Que cualquier persona, en cualquier parte del mundo, pueda crear su presencia en Internet sin depender de la buena voluntad de una corporación, que el conocimiento acumulado durante dos décadas siga siendo accesible y compartido.

El vibe coding, por muy democratizador que parezca, genera exactamente la dependencia opuesta.

Dependes de modelos de IA propietarios, de plataformas de despliegue con planes de precios que cambian cada trimestre, de frameworks mantenidos por empresas que priorizan su modelo de negocio sobre tu estabilidad.

Si la IA que usas deja de estar disponible o cambia su comportamiento entre versiones (algo que pasa constantemente), tu capacidad de mantener tu propio sitio desaparece con ella.

Con WordPress eres dueño de tu web, con vibe coding eres inquilino de un ecosistema de herramientas IA que no controlas.

Solo contra el mundo (o con una comunidad detrás)

Hay otro aspecto que se pasa por alto en casi todas las comparativas técnicas, y es el factor humano.

Cuando usas WordPress y te atascas puedes buscar en los foros de soporte de WordPress.org, preguntar en grupos de Facebook o Telegram, asistir a un meetup local o contratar a cualquiera de los miles de desarrolladores especializados que hay en el mercado.

Con un sitio generado por vibe coding y te atascas, puedes volver a preguntarle a la IA, que puede o no darte la respuesta correcta. O buscar en foros genéricos de programación, donde tu problema específico con tu código específico generado por tu prompt específico probablemente no lo ha tenido nadie antes.

Esto no es cosa de broma ni un problema menor, ni de lejos.

La comunidad de WordPress es una de las más grandes del mundo del software, hay WordCamps en decenas de países, meetups mensuales en cientos de ciudades, canales de Slack activos, blogs especializados, podcasts, newsletters y una cantidad enorme de conocimiento compartido gratuito. Si tienes un problema con WordPress, es casi seguro que alguien lo ha tenido antes y ha publicado la solución.

Con un sitio generado por vibe coding estás por tu cuenta. Tu código es único, tu arquitectura es única, tus bugs son únicos, y la solución a cada problema pasa por volver a sentarte delante de la IA, explicarle el contexto desde cero y esperar que esta vez acierte.

El camino es WordPress + IA, no WordPress o IA

Aquí es donde está la verdadera oportunidad, y lo que aún me sorprende que haya gente que no lo entienda.

La IA no es el sustituto de WordPress, es su mejor complemento. Los que están sacando más partido de todo esto no son los que abandonan WordPress por el vibe coding, sino los que usan la IA para hacer WordPress mejor, más rápido y más potente.

¿Qué te aporta?

• Desarrollo con turbo: Usar Claude Code, Cursor o herramientas similares para crear plugins a medida, personalizar temas, generar bloques del editor o automatizar tareas repetitivas. En vez de generar un sitio entero desde cero creas las piezas que necesitas dentro de un ecosistema que ya funciona.
• Mantenimiento asistido: Usar la IA para revisar código, detectar cuellos de botella de rendimiento, analizar logs de seguridad o generar consultas SQL optimizadas. Precisamente lo que cuento en el tutorial de vibe coding y agentic coding para WordPress.
• Contenido potenciado: Usar la IA para generar borradores, optimizar textos para SEO, crear descripciones de producto o traducir contenidos. Todo dentro de WordPress, donde tienes el editor, la estructura y las herramientas que ya conoces.
• Sitios más limpios: Cuando la IA te permite crear la funcionalidad exacta que necesitas, dejas de depender de plugins multifunción hinchados que cargan el sitio de código innecesario. El resultado son sitios WordPress que rinden como si fueran a medida, porque en cierto modo lo son.

WordPress está integrando la IA a todos los niveles. Desde el Abilities API hasta los AI Building Blocks, pasando por herramientas como Telex, que permite generar código WordPress con lenguaje natural. Si te interesa saber todo lo que igual te estás perdiendo, lo explico a fondo en mi artículo sobre si merece la pena hacer una web con WordPress en tiempos de inteligencia artificial.

Los desarrolladores que están sacando mejores resultados no son los que se fueron de WordPress. Son los que se quedaron y ahora tienen superpoderes.

¿Para quién sí tiene sentido prescindir de WordPress?

Sería deshonesto e incluso injusto no reconocer que hay casos donde el vibe coding sin WordPress es una opción lógica:

• Proyectos personales y experimentos: Si quieres cacharrear, aprender cómo funciona algo o montar un proyecto para ti sin intención de mantenerlo a largo plazo, adelante. El vibe coding es perfecto para prototipos y proyectos desechables.
• Landing pages con fecha de caducidad: Una página de captación para un evento, una campaña concreta o un lanzamiento que va a durar unas semanas. No necesita mantenimiento a largo plazo, no necesita CMS, no necesita ecosistema.
• Sitios estáticos que nunca van a crecer: Si realmente sabes que tu sitio va a ser cinco páginas para siempre, sin blog, sin tienda, sin formularios complejos, sin necesidad de que nadie técnicamente inexperto lo edite, puede tener sentido.
• Conceptos y prototipos: Quieres validar una idea rápido y barato antes de invertir en un desarrollo serio. El vibe coding te da velocidad, y si la idea funciona, ya construirás la versión definitiva con la tecnología adecuada.

La clave es tener claro en cuál de estos puntos estás, si necesitas algo así. El problema surge cuando alguien monta un prototipo, funciona, y asume que puede escalar a producción sin cambiar de enfoque.

Las tablas de la ley

Para que quede claro de un vistazo, aquí tienes la comparativa entre lo que obtienes con cada enfoque:

Consejos finales: si aun así decides prescindir de WordPress

No voy a decirte que no lo hagas. Cada proyecto tiene sus circunstancias y no existe una herramienta universal. Pero si decides tirar por el camino del vibe coding para un proyecto real, al menos ten en cuenta estas cosas:

1. Revisa siempre el código generado: Nunca, jamás, pongas en producción código que no has revisado. La IA genera código que «funciona» pero eso no significa que sea seguro, eficiente o mantenible a largo plazo.
2. Pide siempre validación de seguridad: Incluye en tus prompts instrucciones explícitas sobre saneado de datos, escapado de salida, validación de entradas y protección contra los ataques más comunes. Y luego revísalo igualmente. Yo tengo publicadas mis SKILLs, por si no sabes por dónde empezar.
3. Documenta todo: Si no entiendes el código al menos que quede documentado qué hace cada parte. Tu yo del futuro (o quien herede el proyecto) te lo agradecerá. Pídele a la IA que te documente cada paso.
4. Ten un plan de mantenimiento: Antes de lanzar, piensa en quién va a actualizar las dependencias, quién va a corregir los bugs, quién va a aplicar los parches de seguridad. Si la respuesta es «nadie» o «ya veré», estás a un incidente de quedarte con un sitio comprometido.
5. No confundas prototipo con producto: Si tu sitio vibe-coded funciona y quieres escalar plantéate seriamente migrarlo a una plataforma profesional. Un prototipo que «va tirando» en producción es una bomba de relojería.
6. Calcula el coste de verdad: Suma los tokens, las horas de depuración, las vueltas con la IA para conseguir lo que quieres, el tiempo de mantenimiento futuro. Compáralo con el coste de un hosting WordPress de calidad y un tema profesional. Puede que te lleves una sorpresa.

El mejor momento para usar WordPress con IA es ya

La narrativa del «Adiós WordPress, la IA me lo hace todo» funciona bien en un post viral. Es simple, es llamativa y tiene ese punto de rebeldía que genera likes.

La realidad del desarrollo web es otra. Los sitios web no son proyectos que se terminan un día y ya, son proyectos que tienen una vida, a veces larga, y hay que mantenerlos. Y es en ese mantenimiento continuo, en la gestión diaria del contenido, en la seguridad, en el cumplimiento legal, en la escalabilidad, en la capacidad de que personas no técnicas participen, donde WordPress lleva dos décadas demostrando su valor.

La IA no viene a sustituir a WordPress sino a hacerlo todavía más potente. Quién entienda esto antes tiene una ventaja enorme sobre el que siga pensando que elegir entre IA y WordPress es la pregunta correcta.

La pregunta correcta es ¿cómo uso la IA para hacer más y mejor con WordPress?

Y esa tiene muchas respuestas buenas, casi todas aquí, en este tu blog.

Los dos maquetadores más usados del ecosistema WordPress han renovado su arquitectura casi a la vez, y eso no pasa todos los días.

No estamos hablando de actualizaciones al uso, con un puñado de funciones nuevas y un par de correcciones, tanto Elementor como Divi han reescrito buena parte de su base de código.

Elementor ha apostado por lo que llaman el «editor atómico«, con un enfoque CSS-first. Divi, por su parte, ha tirado la casa por la ventana con una reescritura completa de Divi Builder desde cero, tras más de tres años de desarrollo (llevo siguiendo todo el proceso, desde la primera demo de Divi 5 hasta la alpha pública).

Así que si llevas tiempo preguntándote cuál elegir, o si te estás planteando cambiar de uno a otro, este es el mejor momento para comparar, vamos a ello.

Migración y retrocompatibilidad

Los dos se han tomado la retrocompatibilidad en serio, pero con estrategias diferentes.

Migrar de Elementor 3 a Elementor 4

Permite usar elementos de v3 y v4 en la misma página. No necesitas migrar nada, los widgets antiguos siguen funcionando tal cual, puedes ir adoptando los elementos atómicos gradualmente. Es lo más seguro y menos agresivo.

Migrar de Divi 4 a Divi 5

Divi 5 incluye un migrador que convierte todos los módulos de Divi 4 al nuevo formato. El proceso es rápido, pero conviene probarlo primero en staging (tengo una guía detallada del proceso de migración a Divi 5 con lo que me he encontrado).

También hay un modo de compatibilidad hacia atrás para módulos de terceros que todavía no se han adaptado.

Elegant Themes mantiene compatibilidad con Divi 4 durante al menos seis meses después del lanzamiento, con actualizaciones de seguridad. Pasado ese periodo las rutas de actualización convergerán y todos los sitios recibirán el aviso de actualización a Divi 5.

Si tienes un sitio complejo con muchos plugins de terceros la migración a Divi 5 requiere más precaución. Con Elementor 4 la transición es más progresiva y con menos riesgo, pero en contrapartida mantiene demasiada compatibilidad con código antiguo.

Arquitectura y rendimiento

Este es el punto donde los dos han metido más trabajo, y donde el cambio respecto a las versiones anteriores es más evidente.

Elementor 4

Elementor ha introducido lo que llaman el «Atomic Editor» para pasar de un sistema basado en widgets con estilos inline a un enfoque basado en CSS donde los estilos se gestionan a través de clases y variables reutilizables.

Esto genera un DOM más limpio y menos código repetido. Según datos de Elementor la reducción de código CSS puede llegar al 70 % en páginas que usan íntegramente los elementos atómicos frente al sistema antiguo de la v3.

Elementor 4 y la versión 3 coexisten en la misma página, no tienes que migrar todo de golpe, puedes ir adoptando los nuevos elementos atómicos poco a poco mientras mantienes los widgets de v3 funcionando.

Lo malo es que la mejora en estas situaciones sería limitada, arrastrando problemas de las versiones 3.x.

Divi 5

La gente de Elegant Themes ha ido más lejos en cuanto a reescritura, pues es un maquetador completamente nuevo, desarrollado con React y una arquitectura moderna desde la misma base.

Y aquí viene lo gordo, porque Divi 5 ha eliminado los shortcodes que lastraban el rendimiento de Divi 4 y ahora usa un formato de almacenamiento basado en HTML5, alineado con el sistema de bloques de WordPress.

Este cambio es enorme, pues ya no hay procesamiento de shortcodes en cada carga de página, el CSS se genera de forma limpia, los scripts no esenciales se cargan en diferido y el peso base de cada página se ha reducido de forma considerable.

Si desactivas Divi 5 ya no te quedas con un montón de shortcodes ilegibles en el contenido como pasaba antes.

Hice mis propias pruebas de rendimiento comparando Divi 5 con Divi 4 cuando todavía estaba en fase alpha, con dos sitios idénticos en el mismo servidor, y ya entonces la mejora apuntaba maneras.

Ahora, con la versión final, los datos son todavía mejores. Según pruebas recientes (WP All Import, Oxygen), Divi 5 iguala o supera a Elementor en varias métricas clave:

• Mejor FCP (First Contentful Paint)
• Mejor Speed Index
• Menos peticiones HTTP
• Puntuaciones de Lighthouse superiores tanto en móvil como en escritorio.

Elementor puede tener un tamaño de página ligeramente menor en algunas situaciones, pero Divi 5 genera menos peticiones al servidor y un CSS más limpio que Elementor.

El salto de rendimiento de Divi 5 frente a Divi 4 ha sido tremendo. Si probaste Divi 4 y te pareció lento, Divi 5 es otro producto.

Frente a Elementor 4, la diferencia ya no es que Divi vaya por detrás, van bastante igualados, con Divi llevando ventaja en varias métricas.

Sistema de diseño

Aquí es donde estos cambios marcan un antes y un después para los dos maquetadores porque ambos han adoptado conceptos que vienen del mundo del diseño de interfaces (Figma, Sketch) y que hasta ahora eran territorio exclusivo de herramientas de desarrollo.

Elementor 4

Trae tres novedades gordas en este apartado:

• Variables: puedes definir valores globales para colores, tipografías y espaciados. Cambias un valor y se actualiza en todo el sitio. Funcionan como design tokens.
• Clases CSS: puedes crear clases reutilizables y asignarlas a cualquier elemento. Nada de ir widget por widget cambiando estilos, que era una pesadilla.
• Sincronización con estilos globales: las nuevas variables y clases se sincronizan automáticamente con los colores y fuentes globales de v3, lo que facilita la transición.

Divi 5

En esto ha ido un paso más allá con un sistema de presets bastante completo:

• Variables de diseño: similares a las de Elementor, permiten definir valores globales para colores, tipografías, tamaños y espaciados.
• Preajustes anidados y apilables: puedes crear presets a nivel de módulo y a nivel de grupo de opciones (por ejemplo, un preset solo para bordes) y anidarlos. Aplicas un preset de módulo y los presets de opciones se aplican automáticamente.
• Inspector: inspirado directamente en Figma. Clic derecho en cualquier sección y ves un panel con todos los estilos aplicados (colores, fuentes, medios, presets). Puedes editar todo desde ahí, incluso hacer cambios en lote. Esto es una pasada para cuando importas layouts y necesitas adaptar la paleta de colores de golpe.

En este apartado Divi 5 lleva ventaja porque el sistema de preajustes anidados y el inspector son herramientas que ahorran mucho tiempo, sobre todo cuando trabajas con plantillas importadas o gestionas varios sitios con la misma identidad visual.

Editor y experiencia de uso

El día a día con un maquetador se juega aquí, no en la lista de funcionalidades.

Elementor 4

Mantiene la estructura de editor que ya conocemos: panel lateral izquierdo con los ajustes del elemento seleccionado y edición visual en el lienzo. Las novedades más visibles son:

• Edición inline mucho más fluida (puedes editar textos directamente en el lienzo).
• La pestaña de estilo se ha unificado para los elementos atómicos, lo que simplifica la navegación.
• Pro Interactions: animaciones al hacer scroll, efectos al pasar el cursor y transformaciones personalizadas sin necesidad de plugins de terceros.
• Selección múltiple de elementos: seleccionas varios a la vez y les aplicas cambios en bloque.

Divi 5

Aquí también ha renovado la experiencia de edición de arriba abajo:

• El maquetador visual es mucho más rápido que en Divi 4. El editor de backend, que era muuuy lento con páginas complejas, ha mejorado de forma impresionante.
• Paneles acoplables: puedes anclar los paneles de ajustes a la barra lateral o dejarlos flotantes, y gestionar varios paneles abiertos a la vez.
• Menú contextual con clic derecho para todo (añadir, copiar, pegar, inspeccionar), que agiliza mucho el flujo de trabajo.
• El Command Center (similar a la paleta de comandos de VS Code) para acceder a cualquier función del maquetador escribiendo su nombre.
• La vista de capas para gestionar la estructura sin tocar el lienzo.
• Siete puntos de ruptura adaptables (responsive) personalizables (Divi 4 tenía tres fijos).

Si quieres ver los cambios de Divi 5 con más detalle tengo una guía visual completa de los cambios de Divi 5 que te puede servir de referencia.

En el caso de que vengas de Divi 4 la mejora de rendimiento del editor es lo primero que vas a notar, si vienes de Elementor, el inspector y los paneles acoplables te van a llamar la atención.

Los dos editores son buenos actualmente pero Divi ha dado un salto más grande porque partía de más atrás.

Componentes y modularidad

Los dos maquetadores han apostado fuerte por los componentes reutilizables, aunque con enfoques distintos.

Elementor 4 Components

Sustituyen a los antiguos widgets globales. La diferencia es que los componentes sincronizan estructura y estilos (los widgets globales solo sincronizaban estilos), y además permiten personalización controlada en cada necesidad.

Es decir, puedes tener un componente de tarjeta de producto que se sincroniza en todo el sitio, pero cambiar el texto o la imagen en cada lugar donde lo uses sin romper la sincronización global.

También los formularios se han modularizado, ahora los Atomic Forms descomponen los formularios en elementos individuales (etiqueta, campo, botón de envío) que puedes organizar libremente en el lienzo.

Divi 5 Nested Modules

Permiten meter módulos dentro de otros módulos sin límites, lo que abre muchas posibilidades, como poder poner un botón dentro de un menú, un formulario dentro de una tarjeta, o construir estructuras de menú complejas sin necesidad de plugins adicionales.

Los controles de Flexbox y CSS Grid se aplican a cualquier contenedor, lo que da una flexibilidad de maquetación que antes no existía en Divi.

Ambas ideas resuelven los problemas de manera muy eficiente.

Elementor con sus Components apuesta por la consistencia a escala (perfecto para agencias que gestionan muchos sitios), mientras que Divi con los Nested Modules apuesta por la flexibilidad creativa (perfecto para diseñadores que quieren control total sobre la estructura).

Integración con IA

Aquí es donde las diferencias se ponen interesantes porque los dos han ido por caminos bastante distintos.

Elementor AI

Tiene como dos capas, o dos modos de usar IA. Por un lado está la IA base, que está integrada directamente en el editor. Genera textos, imágenes, código CSS personalizado y diseños de secciones completas.

Funciona con un sistema de créditos. Un prompt de texto o código cuesta 1 crédito, una imagen 33 créditos, un contenedor con layout 40 créditos.

Los planes específicos de IA van desde unos 44 €/año (24.000 créditos) hasta 176 €/año (100.000 créditos). Con el plan Elementor One (desde 168 €/año en precio de lanzamiento) los créditos se comparten entre IA, optimización de imágenes y otras funciones.

La segunda capa es Angie, un agente de IA que va más allá de generar texto o imágenes, pues entiende la estructura de tu sitio WordPress (tema, plugins, campos personalizados) y puede crear widgets personalizados, snippets de código y extensiones funcionales a partir de instrucciones en lenguaje natural.

Todo se prueba en un entorno de pruebas antes de tocar tu sitio en producción. Usa el Model Context Protocol (MCP) para heredar automáticamente el contexto de tu instalación.

Ahora bien, la realidad de Angie a día de hoy es que según pruebas de empresas como Crocoblock, que basan su negocio en gran medida en Elementor, es que al agente todavía falla bastante.

Tiende a generar HTML en crudo en lugar de usar los widgets de Elementor, y hay muchos prompts complejos que simplemente no funcionan.

Es un concepto prometedor pero todavía está muy verde. Lo que sí funciona bien de Elementor AI es la generación de imágenes y el CSS personalizado, que conoce la estructura de los módulos de Elementor.

Divi AI

El maquetador Divi toma un enfoque diferente pues todo está integrado directamente en el maquetador, sin plugins separados. Desde cualquier campo de texto, imagen o código puedes invocar la IA.

Sus capacidades son estas:

• Generación y reescritura de textos (títulos, párrafos, posts enteros).
• Generación de imágenes.
• Código CSS personalizado, entrenado específicamente con la base de código de los módulos de Divi.
• Generación de layouts completos: le describes tu negocio y una cadena de agentes crea el esqueleto de la página, construye la estructura, rellena con texto e imágenes y personaliza los estilos.

Divi acaba de empezar a desarrollar su propio AI Agent (aparece en los registros de cambio de las versiones 5.1 y 5.2), pero está en fases muy tempranas, todavía no es funcional del todo.

La diferencia grande en precios:, sobre todo porque Divi AI es ilimitado si tienes Divi Pro (unos 255 €/año) o el bundle Lifetime + Pro Services (unos 273 € de pago único + 195 €/año de servicios). Con Divi AI hay créditos, no hay topes, mientras que en Elementor AI pagas por uso.

¿Qué sale mejor?, pues depende:

• Si usas mucho la IA diseñando el modelo de Divi es más predecible en costes.
• Si utilizas la IA para maquetar de forma puntual el sistema de créditos de Elementor puede salir más económico.

WooCommerce

Los dos maquetadores ofrecen compatibilidad completa con WooCommerce, pero con diferencias.

Elementor Pro

La versión 4 ya incluye módulos específicos para WooCommerce:

• Páginas de producto
• Listados de tienda
• Carrito y pago personalizables visualmente.

Pero ojo, el WooCommerce Builder de Elementor completo requiere adicionalmente el plan Advanced Solo (unos 77 €/año) o superior. Con Elementor 4 estos módulos se benefician del nuevo sistema atómico y del rendimiento mejorado.

Divi 5

En esto ha completado la migración de todos los módulos de WooCommerce a la nueva arquitectura:

• Galería de producto
• Módulos de checkout y carrito
• Módulos de pago

Funciona con cualquier plan de Divi, sin restricciones por nivel de suscripción.

El Loop Builder de Divi permite crear listados de productos con consultas personalizadas, filtros avanzados y diseños de cuadrícula flexibles.

En funcionalidad pura de WooCommerce están bastante igualados.

La diferencia es que en Elementor necesitas un plan medio-alto para acceder al builder completo de WooCommerce, mientras que en Divi viene incluido en todos los planes.

Ecosistema y escalabilidad

Elementor tiene una ventaja obvia, porque con más de 12 millones de instalaciones activas, gracias a la acertada estrategia de ofrecer una version (capada) en WordPress.org, su ecosistema de plugins y extensiones de terceros es enorme.

Hay cientos de addons disponibles (JetElements, Essential Addons, Premium Addons…) que amplían las funcionalidades del maquetador. La versión 4 mantiene retrocompatibilidad con los addons de v3 así que el ecosistema existente sigue funcionando.

Además, Elementor se está convirtiendo en una plataforma más que en un simple plugin, porque ofrece hosting propio (Elementor Cloud), integración con herramientas de accesibilidad (Ally), optimización de imágenes, envío de emails transaccionales y gestión centralizada de sitios, todo dentro de su plan One.

Divi tiene su propio marketplace con plugins y módulos de terceros, aunque más reducido que el de Elementor, pues cometieron el error, a mi modo de ver, de no ofrecer versión limitada en WordPress.org.

La transición a Divi 5 ha sido un reto para los desarrolladores de terceros, ya que la reescritura completa del maquetador requiere adaptar los plugins. Muchos ya tienen versiones compatibles, pero otros siguen en desarrollo.

Si dependes mucho de plugins de terceros para Divi, conviene comprobar la compatibilidad antes de migrar.

Divi incluye en su paquete base Divi Cloud (almacenamiento de assets en la nube), Divi Dash (gestión de múltiples sitios) y las extensiones DonDivi (que Elegant Themes ha adquirido recientemente, incluyendo DiviMenus). También tienes Bloom (formularios de suscripción) y Monarch (botones sociales) sin coste adicional.

Modelo de precios

Aquí las diferencias son grandes y merece la pena verlas con calma. Los precios de Elementor están en euros directamente, los de Divi están en dólares (los paso a euros aproximados al cambio actual).

Un par de cosas a tener en cuenta:

Elementor no ofrece licencia ilimitada. Eso significa que si dejas de pagar dejas de recibir actualizaciones y soporte. Divi sí la ofrece, y a 229 € con sitios ilimitados es difícil de batir para quién trabaja con muchos sitios.

En cuanto a Elementor Free, que existe y que a veces se presenta como una ventaja, la realidad es que cada vez se queda más corto. Le faltan el Theme Builder, los formularios, los popups, el WooCommerce Builder y la mayoría de widgets Pro. Es más un gancho comercial para vender la versión de pago que un producto usable en producción.

Divi no tiene versión gratuita, pero ofrece una demo para probar y 30 días de garantía de devolución.

La comparación directa depende mucho del tipo de uso que le vayas a dar:

• Para un solo sitio con WooCommerce, Elementor Advanced Solo (77 €) sale más barato que Divi anual (82 €), pero Divi incluye sitios ilimitados.
• Para agencias, el lifetime de Divi a 229 € con sitios ilimitados es muy difícil de superar frente a los 367 €/año de Elementor Agency.
• Si la IA ilimitada te interesa, los 255 €/año de Divi Pro son más predecibles que el sistema de créditos de Elementor.

Entonces, ¿cuál es mejor actualmente, Divi o Elementor?

No hay un ganador absoluto pero sí perfiles claros para cada uno dependiendo de tus prioridades. Siento no mojarme más, pero es la realidad.

Elementor te viene mejor si:

• Necesitas un ecosistema de plugins de terceros grande y maduro.
• Valoras una transición gradual sin migraciones bruscas.
• Buscas una plataforma todo-en-uno (maquetador + hosting + IA + accesibilidad + email).
• Tu flujo de trabajo se basa en componentes reutilizables sincronizados a escala.
• Gestionas pocos sitios y no necesitas licencias ilimitadas.

Divi te viene mejor si:

• Gestionas muchos sitios y necesitas una licencia que cubra todos sin límite.
• Quieres un pago único (lifetime) y olvidarte de renovaciones anuales del maquetador.
• Usas mucho la IA y prefieres un modelo de uso ilimitado sin créditos.
• Valoras el inspector y el sistema de preajustes anidados para gestionar sistemas de diseño.
• Necesitas flexibilidad máxima de maquetación con módulos anidados y CSS Grid nativo.

Los dos están en un momento de transición, y es algo que también debes valorar.

Elementor 4 es más maduro en su nueva arquitectura (lleva más de un año con las funciones atómicas en alpha y beta). Divi 5 acaba de salir de beta y todavía está puliendo detalles, pero el ritmo de actualizaciones es alto (cada dos semanas).

Si estás empezando un proyecto nuevo hoy, cualquiera de los dos es una buena elección.

Si ya tienes sitios en uno de ellos, la migración al otro rara vez compensa el esfuerzo. Lo que sí conviene es actualizar a las nuevas versiones y aprovechar las mejoras de rendimiento y las nuevas herramientas de diseño que ambos traen.

Si quieres más información, demos o capturas aquí tienes las webs oficiales de ambos:

• Elementor Pro 4
• Divi 5

La nueva funcionalidad se llama Block Visibility y permite ocultar cualquier bloque por tipo de dispositivo (escritorio, tablet o móvil) directamente desde el editor, sin instalar nada. También mantiene la opción de ocultar un bloque por completo, que ya existía desde WordPress 6.9, eso no cambia, pero ahora todo se gestiona desde el mismo sitio.

Te cuento cómo funciona, y también la parte técnica qué necesitas saber si desarrollas temas o plugins.

Cómo ocultar un bloque por dispositivo

Selecciona el bloque que quieras ocultar y abre el menú de opciones (los tres puntos de la barra de herramientas o clic derecho). Verás una opción nueva, Ocultar (Hide en inglés), con el atajo de teclado ⇧⌘H en Mac.

Al pulsar en ese enlace del menú se abre una pequeña ventana emergente con las opciones de visibilidad:

• Omitir del contenido publicado: oculta el bloque por completo. No se procesa en el HTML de la página, así que nadie lo ve en ningún dispositivo. Es lo mismo que hacía blockVisibility: false en WordPress 6.9.
• Ocultar en escritorio: oculta el bloque en pantallas de escritorio.
• Ocultar en tableta: oculta el bloque en tabletas.
• Ocultar en móvil: oculta el bloque en móviles.

Puedes marcar las combinaciones que necesites. Por ejemplo, si quieres que un bloque solo se vea en móvil, marcas «Ocultar en escritorio» y «Ocultar en tableta».

Indicadores en la vista de lista

Cuando un bloque tiene reglas de visibilidad activas la vista de lista del editor muestra iconos junto al nombre del bloque indicando en qué dispositivos está oculto. Viene bien para no perder la pista de qué has ocultado y dónde.

Vista previa en el editor de bloques

Por ir terminando, la comprobación de esta funcionalidad es sencilla, solo tienes que cambiar a la vista previa integrada en el editor de WordPress de un dispositivo que hayas ocultado para comprobar que no se ve, y a más, por supuesto, puedes comprobar en la web que no se verá si cambias el tamaño de pantalla.

Las tripas: CSS en vez de no renderizar

Aquí hay una diferencia importante que conviene tener clara y es que cuando marcas «Omit from published content» el bloque directamente no se incluye en el HTML de la página. No existe en el DOM, no se carga, no aparece en ningún sitio. Esto es lo que ya hacía WordPress 6.9 con blockVisibility: false y sigue funcionando exactamente igual.

Cuando ocultas por dispositivo (desktop, tablet, mobile), la cosa cambia: el bloque sí se renderiza en el DOM. Lo que hace WordPress es aplicar reglas CSS con media queries para ponerle un display: none en los viewports que hayas seleccionado. El contenido está ahí, simplemente no se ve.

Esto tiene implicaciones prácticas. Si ocultas una imagen pesada en móvil con esta funcionalidad, el navegador del móvil sigue descargando la imagen aunque no la muestre. Para casos donde el rendimiento es lo que te preocupa, la opción de «Omitir del contenido publicado» o el enfoque clásico con render_block y wp_is_mobile() siguen siendo mejor opción.

La estructura técnica: metadatos del bloque

La visibilidad se guarda en los metadatos del bloque, dentro de la clave blockVisibility. La estructura ha cambiado respecto a WordPress 6.9, que solo admitía un booleano.

Ocultar un bloque por completo sigue siendo igual:

{
  "metadata": {
    "blockVisibility": false
  }
}

La novedad es que ahora blockVisibility también puede ser un objeto con una clave viewport:

{
  "metadata": {
    "blockVisibility": {
      "viewport": {
        "mobile": false,
        "tablet": true,
        "desktop": true
      }
    }
  }
}

En este ejemplo, mobile: false significa que el bloque no se muestra en móvil. Los valores true o la ausencia de la clave significan que sí se muestra.

La clave viewport está anidada a propósito dentro de blockVisibility. La idea es que en futuras versiones se puedan añadir más criterios de visibilidad al mismo nivel (por ejemplo, por rol de usuario o por franjas horarias), sin romper la estructura actual.

En el markup serializado del bloque, queda así:

<!-- wp:paragraph {"metadata":{"blockVisibility":{"viewport":{"mobile":false}}}} -->
<p>Este párrafo no se ve en móvil.</p>
<!-- /wp:paragraph -->

Los breakpoints actuales

WordPress 7.0 usa tres breakpoints fijos:

• Móvil: pantallas de hasta 480px de ancho.
• Tableta: de 480px a 782px.
• Escritorio: más de 782px.

Estos valores están definidos tanto en PHP (lib/block-supports/block-visibility.php) como en JavaScript (packages/block-editor/src/components/block-visibility/constants.js) y, al menos de momento, no se pueden cambiar ni desde theme.json ni desde ningún filtro.

El punto de corte de 782px te sonará si has trabajado con el admin de WordPress, que usa ese mismo valor para su diseño responsive. El de 480px coincide con los breakpoints de los estilos base de Gutenberg. No son valores especialmente estándar fuera de WordPress (muchos frameworks usan 768px para tablet), pero son coherentes con el resto del ecosistema.

Qué necesitas saber si desarrollas temas o plugins

Si tu tema o plugin genera, transforma o analiza markup de bloques en el servidor, ojo: el campo blockVisibility en los metadatos del bloque ahora puede ser dos cosas distintas. Hasta WordPress 6.9 era siempre un booleano (false). Desde WordPress 7.0 puede ser un booleano o un objeto con la estructura de viewport que acabamos de ver.

Si tu código asume que blockVisibility siempre es un valor escalar, va a petarte cuando se encuentre con un objeto. Revisa y adapta.

Si tus bloques no tocan el markup en el servidor, no tienes que hacer nada. La visibilidad por viewport es un block support que se aplica automáticamente. No hace falta declarar nada en el block.json de tus bloques.

Lo mismo se aplica a patrones y bloques reutilizables, de manera que si ya tienen reglas de visibilidad guardadas funcionan sin tocar nada.

Adiós a los plugins de visibilidad por dispositivo

Plugins como Block Visibility, EditorsKit o Conditional Blocks han hecho un trabajo estupendo cubriendo esta carencia durante años, pero si lo único que necesitabas era ocultar bloques por tipo de pantalla, a partir de WordPress 7.0 ya no necesitas ninguno de ellos para esta funcionalidad.

Ahora bien, si usas características más avanzadas de esos plugins (visibilidad por perfil de usuario, por fechas, por geolocalización, por parámetros de URL), esas cosas siguen sin estar por defecto en WordPress y vas a seguir necesitándolos. WordPress 7.0 solo cubre el caso de visibilidad por viewport, que es el más común y el que más gente pedía.

Y un detalle para quienes vengan de EditorsKit es que si lo desactivas las clases CSS que el plugin añadía a los bloques ocultos siguen estando en tu contenido. Los bloques volverán a mostrarse porque el CSS que los ocultaba ya no se carga.

La funcionalidad nativa de WordPress 7.0 usa un sistema diferente (metadatos del bloque, no clases CSS), así que no hay migración automática. Si tienes bloques ocultos con EditorsKit y quieres pasar al sistema nativo tendrás que reconfigurar la visibilidad bloque a bloque.

Lo que falta y lo que viene en WordPress 7.1

La funcionalidad de WordPress 7.0 es intencionalmente limitada. Se lanzó con lo mínimo para que funcione bien, y el plan es ampliarla en la próxima versión mayor.

Para WordPress 7.1 está previsto:

• Breakpoints configurables desde theme.json: que cada tema pueda definir sus propios puntos de corte y etiquetas de viewport, en lugar de estar limitado a los tres valores fijos actuales.
• Control por tipo de bloque: que los temas puedan activar o desactivar la visibilidad por viewport para bloques concretos, igual que ya se hace con otros block supports como color o tipografía.
• Integración con el style engine: ahora mismo la propiedad CSS display necesita un workaround con el filtro KSES para funcionar. En 7.1 debería gestionarse de forma nativa.

También hay debate abierto sobre si usar media queries de viewport es el enfoque correcto o si container queries serían más apropiadas para bloques individuales. Y sobre el formato de las media queries, que ahora usan la sintaxis moderna de rangos (width <= 480px) en lugar del clásico max-width.

Si te interesa seguir el desarrollo, el issue #75707 en GitHub es donde se está coordinando todo lo de WordPress 7.1. Y la nota oficial de desarrollo de WordPress 7.0 tiene los detalles técnicos de lo que ya está funcionando.

Si gestionas webs para clientes es todavía peor, porque les estás mostrando información que no les aporta nada y ocupa un espacio que podría ser útil.

La buena noticia es que puedes cambiarlo por tus propias fuentes de noticias, ya sea con un poco de código o con un plugin que te lo deja todo listo. Aquí tienes las dos opciones.

Pero antes…

¿Y para qué quiero noticias personalizadas en el escritorio de WordPress?

Si haces webs para clientes, un widget con tus noticias o las de su sector es un detalle de branding que se agradece mucho. El cliente entra al escritorio y ve información relevante en vez del blog de WordPress.org, que probablemente no le dice nada.

También viene bien si tienes un equipo de redactores o editores y quieres que vean novedades del proyecto, fuentes de referencia del sector o avisos internos nada más acceder. Y si simplemente quieres tener a mano tus blogs favoritos sin salir de WordPress, pues también.

Casos típicos donde encaja bien:

• Agencias y freelances que entregan proyectos a clientes y quieren dejar el escritorio personalizado.
• Medios y blogs con varios redactores, para compartir fuentes de información comunes.
• Intranets o sitios corporativos donde el escritorio es la primera pantalla que ven los usuarios.
• Tu propio WordPress, para tener las noticias que te interesan a un clic.

Si aún tienes interés, vamos a las opciones…

Opción rápida: código de funciones

Si solo necesitas mostrar un par de feeds RSS en el escritorio y quieres algo ligero, con un snippet te sobra. Puedes añadirlo a tu plugin de personalizaciones, al functions.php de tu tema hijo o donde tú prefieras.

<?php
/**
 * Widget de escritorio con noticias RSS personalizadas.
 *
 * Sustituye el widget por defecto de WordPress por uno con tus feeds.
 * Quita la primera línea si vas a añadir el código al functions.php o
 * a un plugin de fragmentos de código. Déjala si lo subes como mu-plugin
 *
 * Personaliza los feeds en el array $feeds (url y título).
 * Ajusta $items_per_feed y $max_items a tu gusto.
 */

// Registra el widget personalizado y quita el de WordPress
add_action( 'wp_dashboard_setup', 'ayudawp_custom_news_widget_setup' );

function ayudawp_custom_news_widget_setup() {
    // Quita el widget por defecto de noticias y eventos de WordPress
    remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );

    // Añade el widget personalizado
    wp_add_dashboard_widget(
        'ayudawp_custom_news',
        'Últimas noticias',  // Cambia el título a lo que quieras
        'ayudawp_custom_news_widget_output'
    );
}

function ayudawp_custom_news_widget_output() {
    // === PERSONALIZA AQUÍ ===
    // Añade o quita feeds a tu gusto
    $feeds = array(
        array(
            'url'   => 'https://ayudawp.com/feed/',
            'title' => 'Ayuda WordPress',
        ),
        array(
            'url'   => 'https://es.wordpress.org/news/feed/',
            'title' => 'WordPress España',
        ),
    );

    $items_per_feed = 3;  // Elementos por feed
    $max_items      = 8;  // Máximo total de elementos
    // === FIN DE PERSONALIZACIÓN ===

    include_once ABSPATH . WPINC . '/feed.php';

    $all_items = array();

    foreach ( $feeds as $feed_data ) {
        $rss = fetch_feed( $feed_data['url'] );

        if ( is_wp_error( $rss ) ) {
            continue;
        }

        $feed_items = $rss->get_items( 0, $items_per_feed );

        foreach ( $feed_items as $item ) {
            $all_items[] = array(
                'title'  => esc_html( $item->get_title() ),
                'link'   => esc_url( $item->get_permalink() ),
                'date'   => $item->get_date( 'U' ),
                'source' => esc_html( $feed_data['title'] ),
            );
        }
    }

    if ( empty( $all_items ) ) {
        echo '<p>' . esc_html__( 'No hay noticias disponibles.', 'ayudawp' ) . '</p>';
        return;
    }

    // Ordena por fecha (más recientes primero)
    usort( $all_items, function ( $a, $b ) {
        return $b['date'] - $a['date'];
    } );

    // Limita al máximo configurado
    $all_items = array_slice( $all_items, 0, $max_items );

    echo '<div class="rss-widget"><ul>';

    foreach ( $all_items as $item ) {
        printf(
            '<li><a href="%s" target="_blank" rel="noopener">%s</a> <span class="rss-date">%s</span> <cite>%s</cite></li>',
            esc_url( $item['link'] ),
            esc_html( $item['title'] ),
            esc_html( date_i18n( get_option( 'date_format' ), $item['date'] ) ),
            esc_html( $item['source'] )
        );
    }

    echo '</ul></div>';
}

[imagen del widget de noticias personalizado en el escritorio de WordPress]

Este código hace tres cosas:

1. Quita el widget de noticias de WordPress por defecto
2. Añade uno nuevo con los feeds RSS que tú elijas
3. Los muestra ordenados por fecha.

Lo que tienes que tocar está al principio de la función ayudawp_custom_news_widget_output(), el array $feeds con las URLs y nombres de tus feeds, $items_per_feed para cuántos elementos quieres de cada feed, y $max_items para el total que se muestra en el widget. También puedes cambiar el título del widget en la línea de wp_add_dashboard_widget().

A diferencia del wp_widget_rss_output() que trae WordPress de serie, este código añade varios feeds y los mezcla ordenados por fecha, así ves las noticias más recientes de todas tus fuentes juntas.

Si quieres volver a mostrar el widget original de WordPress, solo tienes que quitar la línea del remove_meta_box().

Opción completa: plugin

Si necesitas más control, o si gestionas sitios para clientes y quieres que el escritorio muestre información útil sin tocar código, el plugin Periscopio te lo pone fácil.

Es un plugin gratuito que sustituye el widget de noticias por defecto por uno totalmente configurable desde una página de ajustes. Lo que te ofrece resumido, es esto:

• Feeds RSS ilimitados, con validación de URL antes de añadirlos y ordenados por fecha.
• Sección de eventos de la comunidad WordPress con localidad personalizable (los saca de la API de WordPress.org).
• Enlaces configurables en el pie del widget, tanto en la sección de eventos como en la de noticias.
• Título del widget editable.
• Caché configurable (de 1 a 72 horas) con opción de vaciarla manualmente.
• Posibilidad de ocultar el widget original de WordPress o dejarlo junto al tuyo.

Instalación y configuración

Lo instalas como cualquier otro plugin desde el directorio de WordPress.org. Una vez activado, ve a Ajustes > Periscopio y ahí tienes todo.

La página de ajustes está dividida en secciones al estilo clásico de WordPress. En la parte de feeds puedes añadir las URLs que quieras, y el plugin las valida antes de guardarlas para evitar errores.

También puedes configurar cuántos elementos quieres por feed y el máximo total.

Periscopio viene con cinco feeds preconfigurados (WordPress.org, el blog de Matt Mullenweg, Make WordPress, WordPress España y Ayuda WordPress), pero puedes cambiarlos todos desde el minuto cero.

¿Qué tal queda?

El widget queda integrado con el estilo nativo de WordPress, así que no desentona, pero con algún detalle que, aunque está mal que lo diga yo, mejora al widget que trae WordPress por defecto.

Los eventos aparecen arriba con información de WordCamps y quedadas cercanas a tu localidad, que puedes modificar, y debajo las noticias de tus feeds mezcladas y ordenadas por fecha.

¿Cuándo usar cada opción?

Si es para ti, para un proyecto concreto o simplemente quieres un par de feeds sin complicarte, el código te vale de sobra.

Si gestionas varios sitios, trabajas con clientes o necesitas la parte de eventos y una gestión de feeds más cómoda (con validación, caché y ajustes visuales), Periscopio te ahorra tiempo y te ofrece mucha más personalización a golpe de clic.

Para seguir enredando con códigos de este tipo relacionados con el mismo asunto, con los widgets de escritorio, también puedes probar como crear widgets de escritorio con contenido propio (no RSS) o añadir un formulario de soporte para tus clientes, tienes más ideas en el blog.

Y si lo que quieres es directamente limpiar el escritorio de cajas que no uses, también puedes hacerlo con un par de líneas de código.

Llevo unos días viendo circular tu manifiesto contra WordPress, eso que empezó como un tuit largo, luego ampliaste en tu blog y que hasta Matt Mullenweg te ofreció quedar por Zoom, como dijo, «aunque no sea para responder, solo para entender de dónde sacas estas conclusiones». Un exitazo.

Esta respuesta seguro que no llega tan lejos, está escrita por un bloguero hispano, y no solemos captar la atención del mundo anglo, por lo que sea, pero alguien la leerá.

Así que voy a tomarte aparte un momento, como un colega que lleva solo unos pocos más años que tú en esto, porque tu manifiesto tiene cosas con parte de razón, otras que son medias verdades y unas cuantas que son directamente falsas. Mezclarlas todas con el mismo volumen no es una llamada de atención, es ruido, o eso me ha parecido.

En lo que sí tienes razón

Vamos a empezar por lo que suscribo del todo, ¿te parece?

• La interfaz para desactivar comentarios en todo el sitio es un lío absurdo repartido por media docena de pantallas, tienes razón.  Yo mismo he compartido como quitar estas mierdas, pero sí, es un jaleo.
• El /wp-admin/options.php existe desde siempre, es súper útil, y no hay un solo enlace visible en el escritorio. Ahora, también te digo que esa pantalla de opciones al completo una burrada, y el 90% de los usuarios no deberían tocar ahí.
• El modo de recuperación mandando el aviso solo al email del admin principal cuando un sitio tiene varios administradores es un fallo de diseño de libro. Como todo en WordPress se puede personalizar con un sencillo filtro, pero razón tienes.
• Y sí, también, contribuir al core puede ser frustrante y lento.

Todo eso lo firmo contigo, son críticas lógicas, más que lógicas, tienes más razón que un santo.

Las medias verdades

Aquí empezamos a tener un problema tú y yo (dialéctico, por supuesto).

Dices que en una instalación limpia «XML-RPC está abierto de par en par» y «en cuanto publicas, los bots empiezan a hacer fuerza bruta contra wp-login», y estás mezclando dos cosas que no son lo mismo.

XML-RPC es un puerta abierta a posibles ataques, correcto, pero los ataques a wp-login.php son otro, y cualquier hosting decente (SiteGround, Kinsta, Cloudways) los frena de serie, y si tu hosting no lo hace tampoco necesitas un plugin de seguridad de 80 euros al año con mil opciones que no vas a tocar. Con uno pequeño y enfocado basta, y para eso tienes este gratuito, Vigilante, que hace eso y mucho más.

Luego dices que «necesitas un plugin para meta titles, descriptions, meta tags básicas, en 2026, no hay excusa, el SEO debería ser nativo».

Marcin, querido amigo, WordPress tiene mapas del sitio nativos desde la versión 5.5, tiene wp_robots, tiene canonical automático, las title tags los gestiona el tema con title-tag desde hace una década. Lo que no tiene es un panel tipo Yoast, y eso es otra cosa muy distinta a «no tiene SEO».

Los huecos que deja el core se tapan con plugins pequeños y enfocados, no con un stack de diez suscripciones anuales como pintas tú. Yo mismo tengo compartidos gratis tres que ejemplifican justo lo contrario de lo que denuncias:

• Automatic Open Graph Tags, un sencillo código (o plugin si lo prefieres) que añade Open Graph y Twitter Cards sin configuración. Cero ajustes, cero suscripciones, gratis del todo.
• Native Sitemap Customizer, que te deja personalizar el mapa del sitio que ya trae WordPress, sin instalar otro plugin que reinvente la rueda.
• NoIndexer, para marcar noindex selectivo en contenidos concretos.

Los tres son gratis, los tres hacen una sola cosa y la hacen bien, los tres son gratis y disponibles para quien quiera utilizarlos, ninguno tiene versión pro, ni suscripción, ni muro de pago. Así que lo de «WordPress te obliga a un stack de plugins de pago para tener SEO» es falso. Hay ecosistema de sobra, y encima gratis, pero hay que buscarlo.

Otra que (casi) me ha dolido leer: «…el hosting es barato porque WordPress funciona en PHP antiguo y en servidores compartidos cutres». Esto es falso de principio a fin.

El core admite PHP 8.3, el mínimo recomendado lo suben con cada versión, y si tu hosting te deja tirado en PHP 7.2 el problema es tu hosting no WordPress. Echarle la culpa al CMS de que el hosting barato sea malo es como culpar al coche de que la gasolina sea de garrafa.

Y, aunque ya te he dicho antes que te suscribo la mayor en esto de contribuir al core, la anécdota del «cogí un bug de la lista de good first bugs, mandé mi PR y nadie me contestó» es ¿cómo decirte?.

Vale, contribuir al core es lento, a veces una putada, eso lo he suscrito, lo firmo si quieres, pero tu anécdota no demuestra que sea imposible, lo que demuestra es que con una experiencia, la tuya, te desanimaste y escribiste un manifiesto. Que es perfectamente legítimo, no digo que no lo sea, solo faltaría, pero no es lo mismo.

Yo mismo he mandado reportes en varias ocasiones y el baile de cambio de sitios donde informar llega a ser hasta molesto, pero bueno, luego me acuerdo de que todos somos voluntarios (por si se te había olvidado) y se me pasa y a otra cosa.

Así se critica WordPress

Aquí viene la parte que más me gusta de todo esto, porque mientras tras escribir tu manifiesto, Nick Hamze leyó lo mismo que hemos leído todos y pensó otra cosa…

De todos los puntos de tu manifiesto lo del modo de recuperación era el único con un fallo concreto y en el que se podía aportar algo funcional. Así que en vez de escribir otra réplica, Nick hizo algo distinto, cogió el bug, escribió el parche, lo acompañó de cuatro tests unitarios, investigó los tickets de Trac relacionados (el #51267, el #47192, el #47352, el #47939) y lo publicó en un gist listo para que alguien lo lleve al core.

Incluye hasta el razonamiento de por qué el parche es defendible pese al ticket que se cerró como «invalid» en 2020, y sugiere cómo plantearlo en Trac si hay reticencias.

Eso es contribuir. Eso, en un rato de sábado por la mañana, vale más que todo tu manifiesto junto, y que este post mío. Desmonta tu queja principal, la de «no se puede aportar a core, el pipeline está cerrado», mejor que cualquier argumento que yo te pueda dar. Nick no ha pedido permiso, no ha esperado a que alguien le conteste en Slack, no ha escrito sobre lo roto que está el sistema, ha escrito el código, ha hecho WordPress.

Lo que no se puede rebatir, solo discutir

Queda la parte grande de tu manifiesto, la de Automattic, WP Engine, la GPL como «estafa», la «comunidad» como ficción. Aquí no hay hechos que rebatir, hay una visión, una opinión. Y las opiniones se debaten, no se discuten ni desmontan.

Mi visión rápida es que sí, hay tensiones, y sí, Automattic es una empresa que extrae valor. Otro sí es que el caso WP Engine es feo y ha dejado mal sabor a mucha gente, yo mismo llevo un año criticando estas posturas.

Ahora bien, llamar a todo esto «un estanque con un solo pez grande» ignora que hay miles de desarrolladores ganándose la vida con WordPress sin que Automattic se les haya comido nada, cientos de plugins pequeños honestos, comunidades locales que sí funcionan, yo mismo he ayudado a organizar unas cuantas y te aseguro que la gente no va a WordCamp Logroño o la Meetup de Sevilla porque Automattic les obligue.

Tu retrato es cinematográfico, queda muy bien, pero no cuadra con lo que yo veo cada día.

Y la teoría de que «nadie en el poder quiere que core sea bueno porque se cargaría a los desarrolladores de plugins» es, con todo el cariño, una tontería que mejora las de Automattic, que las tiene, convirtiéndola en villana cuando la realidad es mucho más aburrida, y es que el core va lento porque tiene 20 años de deuda técnica, millones de sitios que no pueden romper, y un equipo humano limitado.

Ni conspiración ni colapso, solo software viejo.

Querido Marcin, para cerrar

Entiendo tu frustración después de 15 años, yo llevo algunos más y también me frustro con WordPress a menudo.

Pero también te digo que escribir un manifiesto con más pasión que datos, mezclar bugs reales con teorías sobre el pez grande que se come a los pequeños y llamar «colapso hasta en el calendario» a un CMS que mueve el 43% de la web no es una llamada a las armas, más parece un hilo de X buscando ruido. Algo ya lo sabes tú, porque cuando Mullenweg te respondió ofreciéndote sentaros a hablarlo, tu primera reacción fue dudar de si iba en serio.

WordPress tiene problemas, varios, y algunos de los que señalas son reales, pero se arreglan como hizo Nick Hamze, con un .diff y cuatro tests unitarios, o compartiendo plugins gratis y tutoriales a diario desde hace 20 años, como este humilde bloguero español, no con un manifiesto en Twitter.

Un abrazo desde España, de un veterano a otro. Ya me perdonarás los puntillos de ironía, pero seguro que si coincidimos en persona entenderás que soy un poco capullo, es mi particular sentido del (cuestionable) humor.

Al abrir una entrada que otro usuario ya está editando, en lugar de entrar en modo colaborativo, WordPress te muestra el aviso «Esta entrada ya está siendo editada» de siempre, pero con un cambio, este mensaje añadido:

«Debido a que esta entrada usa plugins que no son compatibles con la colaboración en tiempo real solo una persona puede editarla al mismo tiempo.»

Te da dos opciones, o «Tomar posesión» o «Salir del editor«, o sea, el bloqueo de siempre. Y lo más frustrante es que no te dice qué plugin es el incompatible, ni un nombre, ni una pista, te toca adivinarlo.

En este artículo te explico por qué sale este aviso, cómo encontrar el plugin que lo provoca, qué hacer si no eres desarrollador, y cómo corregir la incompatibilidad si mantienes plugins propios, con ejemplo real incluido.

Pero no adelantemos acontecimientos, que igual no sabes qué leches es esto de la colaboración en tiempo real. Te lo cuento.

Qué es la colaboración en tiempo real de WordPress

Hasta ahora, cuando alguien estaba editando una entrada en WordPress, el resto de usuarios quedaban bloqueados. Podías tomar posesión del post o irte, pero editar a la vez no era posible. Desde WordPress 7.0 esto cambia.

La colaboración en tiempo real (RTC) permite que dos o más personas editen el mismo contenido a la vez. Ves el cursor del otro usuario, sus cambios aparecen en tu pantalla al momento y el sistema se encarga de que no haya conflictos. Por debajo usa Yjs, una librería del tipo CRDT (Conflict-free Replicated Data Type) que resuelve los conflictos de edición sin perder datos.

Por defecto, WordPress usa HTTP polling como transporte, lo que significa que los clientes envían y reciben cambios a través de peticiones HTTP normales. No es lo más rápido del mundo, pero funciona en cualquier hosting sin necesidad de WebSockets ni configuración especial. Los proveedores de hosting que quieran ofrecer una experiencia mejor pueden sustituir el transporte por WebSockets usando el filtro sync.providers.

Desde las primeras betas de WordPress 7.0, la funcionalidad se ha podido activar manualmente desde Ajustes > Escritura, marcando la casilla ahí incluida, que por defecto se decidió que estuviese inactiva por defecto, ya que en realidad es muy poca gente quien va a usar esta herramienta y consume recursos.

También hay una constante, WP_ALLOW_COLLABORATION que puedes añadir en wp-config.php y permite activar o desactivar la funcionalidad si pasar por los ajustes, así:

define( 'WP_ALLOW_COLLABORATION', true );

Cómo funcionan las tripas de la sincronización en la RTC

La sincronización, como te acabo de comentar, se basa en Yjs, una librería de CRDT que permite que varios clientes editen el mismo documento sin coordinación central. Cada cambio se codifica como una operación CRDT que se puede aplicar en cualquier orden y siempre lleva al mismo resultado.

El proveedor de transporte mediante HTTP polling hace que los clientes envíen y reciban actualizaciones a través de la REST API de WordPress. Los datos CRDT se almacenan en post_meta en un tipo de contenido interno llamado wp_sync_storage (uno por documento). Las actualizaciones se agrupan en lotes y se compactan periódicamente.

WordPress 7.0 limita inicialmente la colaboración a dos usuarios simultáneos para proteger a los hosting. El equipo de desarrollo ha mencionado varias veces que será configurable desde el wp-config, pero a fecha de hoy todavía no se ha documentado el nombre concreto de esa constante. Los proveedores de hosting también pueden sustituir el transporte HTTP por WebSockets usando el filtro sync.providers para una latencia menor y mejor rendimiento con más usuarios.

Todo lo que pasa por los data stores de WordPress (core/editor, core/block-editor) se sincroniza automáticamente. Eso incluye los atributos de los bloques, el título, el extracto y el post meta registrado con show_in_rest. Lo que no pasa por esos data stores (meta boxes clásicas, handlers de save_post, scripts que modifican el DOM directamente) no se sincroniza.

Lo sé, es un poco técnico, pero es que este artículo es tanto para usuarios como para desarrolladores. No voy a hacer preguntas ni cuenta como nota para examen alguno. Seguimos…

Por qué sale el aviso de plugins no compatibles

La colaboración en tiempo real sincroniza el estado del editor a través de los almacenamientos de datos de WordPress y Yjs. Todo lo que pasa por ahí (atributos de bloques, post meta registrado con show_in_rest) se sincroniza automáticamente entre los usuarios conectados.

Pero las cajas meta clásicas no pasan por ahí. Una caja meta clásica (registrada con add_meta_box()) procesa HTML directamente y guarda sus datos a través de un gancho de save_post. Ese flujo no tiene nada que ver con el almacenamiento de datos de Gutenberg, así que los cambios que hagas en una caja meta clásica no se sincronizan con el otro usuario. Si los dos editáis a la vez, uno puede machacar los cambios del otro sin darse cuenta.

Para evitar eso, WordPress toma una decisión radical, y es que si detecta que hay cajas meta clásicas registradas en el editor desactiva la colaboración entera y te muestra el aviso. No intenta sincronizar unas cosas sí y otras no, simplemente la apaga.

Cómo encontrar el plugin culpable

Esta es la parte que a todo el mundo le interesa, seas usuario o desarrollador. WordPress no te dice qué plugin es, así que te toca investigar. Hay varias formas de hacerlo, de más fácil a más técnica.

Descarte por desactivación (el más fiable)

La forma más rápida y segura de identificar el plugin que bloquea la colaboración es esta:

1. Asegúrate de que la colaboración en tiempo real está activada en Ajustes > Escritura.
2. Desactiva todos los plugins.
3. Abre una entrada con dos usuarios a la vez y comprueba que la colaboración funciona (deberías ver el cursor del otro usuario).
4. Ve activando los plugins uno a uno.
5. Después de activar cada plugin, vuelve a abrir la entrada con los dos usuarios.
6. Cuando la colaboración deje de funcionar y te vuelva a salir el aviso, ese es el plugin problemático.

Es el método clásico de descarte. Lleva un rato, pero no falla, es gratis y tiene cero curva de aprendizaje, es para todos los públicos.

Mirar la parte inferior del editor

Fíjate en la captura del aviso, en la parte inferior de la pantalla del editor se ve el texto «Cajas meta» con un desplegable.

Si algún plugin ha registrado cajas meta en ese contenido las verás listadas ahí. Eso ya te da una pista de cuáles son los candidatos, pero no es definitivo, porque a veces tampoco el editor las coloca ahí abajo.

Buscar en el código (para desarrolladores)

Si tienes acceso por SSH o FTP a tu servidor, un grep rápido te da la lista de todos los plugins que registran meta boxes:

grep -r "add_meta_box" wp-content/plugins/ --include="*.php" -l

Nota importante: No todos los plugins que registran cajas meta causan el problema. Solo los que las registran en tipos de contenido donde quieras usar la colaboración. Un plugin que solo registra cajas meta en una pantalla de ajustes o en un tipo de contenido personalizado que no uses para colaborar no va a interferir.

Query Monitor

Esa joya de plugin por el que nunca estaremos suficientemente agradecidos, Query Monitor, te muestra las cajas meta registradas y qué componente las ha registrado. Con eso puedes identificar rápidamente qué plugin está añadiendo cajas meta al editor.

Qué hacer si no eres desarrollador

Si has identificado el plugin que causa el problema y no tienes ni idea de programación tienes dos opciones, ambas igual de válidas, pero mejor siempre la primera.

Contactar con el desarrollador del plugin

Esta es la mejor opción. Ve al repositorio del plugin en WordPress.org, busca el foro de soporte y abre un hilo explicando el problema. Algo así:

«He activado la colaboración en tiempo real de WordPress 7.0 y el editor me muestra el aviso ‘Debido a que esta entrada usa plugins que no son compatibles con la colaboración en tiempo real solo una persona puede editarla al mismo tiempo’. He comprobado por descarte que el plugin que lo provoca es el vuestro. ¿Tenéis previsto hacerlo compatible?»

Si el desarrollador del plugin lee español, puedes enlazarle este artículo directamente, que más abajo tiene la explicación técnica y el código necesario para hacer la corrección. Si solo lee inglés, la nota oficial de desarrollo y el documento de problemas comunes de VIP tienen toda la información que necesita.

Decidir qué prefieres: el plugin o la colaboración

Mientras el desarrollador actualiza el plugin (si lo hace) tienes que elegir. Si la funcionalidad que aporta el plugin no es imprescindible para ti, desactívalo y disfruta de la colaboración en tiempo real. Si el plugin te hace más falta que la colaboración déjalo activo y sigue editando como siempre, con el bloqueo de edición compartida de siempre.

No es la situación ideal, pero es la realidad de una versión mayor que cambia algo tan de base como el modelo de edición de WordPress. Con el tiempo, la mayoría de plugins se irán adaptando.

Los cuatro problemas de compatibilidad más comunes (para desarrolladores)

A partir de aquí el artículo se pone más técnico. Si desarrollas o mantienes plugins de WordPress, esto te interesa. La dev note oficial y la documentación de WordPress VIP identifican cuatro patrones que causan problemas con la colaboración en tiempo real.

Cajas meta clásicas (el caso más frecuente)

Si tu plugin registra una meta box con add_meta_box() y guarda datos con un gancho de save_post, WordPress desactiva la colaboración para ese tipo de post. Da igual que la meta box sea pequeña o que solo tenga un checkbox. Si está ahí, la colaboración se apaga.

La solución es migrar la funcionalidad a un panel en el sidebar del editor de bloques (usando PluginDocumentSettingPanel) y asegurarte de que el post meta esté registrado con show_in_rest => true. La meta box clásica puedes mantenerla como fallback para el editor clásico.

Inputs no controlados que no reflejan cambios externos

Esto afecta a plugins que ya tienen interfaz en el editor de bloques, pero la han construido usando defaultValue en lugar de value en los inputs. Un input con defaultValue solo responde a lo que escribe el usuario local, no a los cambios que llegan de otros clientes.

La solución: usa siempre inputs controlados con value, derivando ese valor del data store de WordPress con useSelect.

Estado local con useState que desconecta del data store

Otro error habitual: copiar el valor del data store a un useState local. En el momento que haces eso, tu componente se desconecta del estado compartido. Las actualizaciones de otros usuarios llegan al data store, pero tu componente sigue mostrando la copia local que hizo al montarse.

La regla: no copies datos compartidos a useState. Lee siempre directamente del data store.

Bloques con efectos secundarios al insertarse

Si tienes un bloque personalizado que abre un modal automáticamente cuando se inserta, ese modal se abrirá para todos los usuarios conectados, porque el contenido del bloque se sincroniza de inmediato.

La solución: en lugar de abrir el modal automáticamente, muestra un placeholder con un botón que abra el modal al hacer clic. Así el efecto es local y voluntario.

Ejemplo práctico: Adaptando el plugin AI Share & Summarize

Vamos a verlo con un caso real, mi plugin AI Share & Summarize, que tiene una caja meta en la barra lateral del editor que permite ocultar los botones de compartir en entradas o páginas individuales. Es una casilla sencilla, pero esa caja meta clásica es suficiente para que WordPress desactive la colaboración en tiempo real en todos los tipos de contenido donde esté registrada. Pequeñita pero potente ¿no?

Vamos a ver el código actual, entender por qué falla y hacer las modificaciones necesarias paso a paso.

El código actual y por qué causa el problema

El archivo includes/class-meta-box.php del plugin hace tres cosas: registra el post meta con register_post_meta() y show_in_rest => true (esto está bien hecho), registra una caja meta clásica con add_meta_box() (esto causa el problema) y guarda los datos desde un gancho de save_post (necesario para el editor clásico, pero innecesario en el de bloques).

La buena noticia es que la parte más complicada ya está resuelta, porque el meta está correctamente registrado para la REST API. Solo necesitamos cuatro cambios.

Paso 1: Añadir revisions_enabled al registro del meta

La nota para desarrolladores de WordPress 7.0 recomienda que el post meta registrado para la colaboración tenga revisions_enabled => true. Esto hace que los cambios en el meta se registren en el historial de revisiones, algo que viene muy bien cuando hay varios editores trabajando a la vez.

En el método ayudawp_register_meta(), añade el parámetro:

public function ayudawp_register_meta() {
    $post_types = get_post_types( array( 'public' => true ), 'names' );

    foreach ( $post_types as $post_type ) {
        register_post_meta( $post_type, self::META_KEY, array(
            'show_in_rest'      => true,
            'single'            => true,
            'type'              => 'boolean',
            'default'           => false,
            'revisions_enabled' => true, // Track changes in revision history.
            'auth_callback'     => function() {
                return current_user_can( 'edit_posts' );
            },
        ) );
    }
}

Paso 2: Registrar la meta box solo en el editor clásico

Este es el cambio clave. Necesitamos que add_meta_box() solo se ejecute cuando estemos en el editor clásico. Cuando el editor de bloques esté activo, no registramos la meta box, y eso permite que la colaboración funcione.

Modifica el método ayudawp_add_meta_box():

public function ayudawp_add_meta_box() {
    $post_types = get_post_types( array( 'public' => true ), 'names' );

    foreach ( $post_types as $post_type ) {
        // Skip if the block editor is active for this post type.
        if ( function_exists( 'use_block_editor_for_post_type' )
            && use_block_editor_for_post_type( $post_type )
        ) {
            continue;
        }

        add_meta_box(
            'ayudawp_aiss_exclude_metabox',
            __( 'AI Share & Summarize', 'ai-share-summarize' ),
            array( $this, 'ayudawp_render_meta_box' ),
            $post_type,
            'side',
            'default'
        );
    }
}

Con este cambio, los usuarios del editor clásico siguen teniendo la meta box de siempre. Los que usen el editor de bloques no la verán, y la colaboración no se desactivará.

Paso 3: Crear un panel en la barra lateral del editor de bloques

Ahora necesitamos que los usuarios del editor de bloques puedan seguir ocultando los botones en entradas individuales. Para eso toca crear un panel en la barra lateral del editor usando PluginDocumentSettingPanel.

Creamos (bueno, yo en este ejemplo, que el plugin es mío) un nuevo archivo assets/js/editor-sidebar.js:

/**
 * AI Share & Summarize - Block Editor Sidebar Panel
 *
 * Replaces the classic meta box in the block editor with a sidebar panel
 * compatible with WordPress 7.0 real-time collaboration.
 */
( function () {
    var el              = wp.element.createElement;
    var registerPlugin  = wp.plugins.registerPlugin;
    var PluginDocPanel  = wp.editor.PluginDocumentSettingPanel
                          || wp.editPost.PluginDocumentSettingPanel;
    var CheckboxControl = wp.components.CheckboxControl;
    var useSelect       = wp.data.useSelect;
    var useDispatch     = wp.data.useDispatch;
    var __              = wp.i18n.__;

    /**
     * Sidebar panel component
     *
     * Reads the exclusion meta value directly from the data store
     * using a controlled input. This keeps the panel in sync across
     * all connected editors during real-time collaboration.
     */
    function AissExcludePanel() {
        // Always read from the data store, never from local state.
        var isExcluded = useSelect( function ( select ) {
            var meta = select( 'core/editor' ).getEditedPostAttribute( 'meta' );
            return meta && meta._ayudawp_aiss_exclude ? true : false;
        }, [] );

        var editPost = useDispatch( 'core/editor' ).editPost;

        return el(
            PluginDocPanel,
            {
                name: 'aiss-exclude-panel',
                title: 'AI Share & Summarize',
                icon: 'share',
            },
            el( CheckboxControl, {
                label: __( 'Hide share buttons on this content', 'ai-share-summarize' ),
                checked: isExcluded,
                onChange: function ( value ) {
                    editPost( { meta: { _ayudawp_aiss_exclude: value } } );
                },
                help: __(
                    'Check this box to prevent the share and AI buttons from appearing on this specific content.',
                    'ai-share-summarize'
                ),
            } )
        );
    }

    registerPlugin( 'aiss-exclude-panel', {
        render: AissExcludePanel,
        icon: 'share',
    } );
} )();

Hay varios detalles importantes en este código. El valor del checkbox se lee siempre del data store con useSelect, nunca se copia a un useState local. El input usa checked (controlado), no defaultChecked. Y los cambios se escriben directamente al data store con editPost. Esos tres puntos son los que garantizan que el panel funcione correctamente cuando varios usuarios editan a la vez.

El archivo no necesita JSX ni siquiera proceso de build. Usa wp.element.createElement directamente, así que funciona tal cual.

Paso 4: Encolar el script en el editor de bloques

Ahora hay que decirle a WordPress que cargue ese script cuando se abra el editor de bloques. Añade el gancho en el constructor de la clase y el nuevo método:

En el constructor:

public function __construct() {
    add_action( 'add_meta_boxes', array( $this, 'ayudawp_add_meta_box' ) );
    add_action( 'save_post', array( $this, 'ayudawp_save_meta_box' ), 10, 2 );
    add_action( 'init', array( $this, 'ayudawp_register_meta' ) );
    add_action( 'enqueue_block_editor_assets', array( $this, 'ayudawp_enqueue_editor_sidebar' ) );
}

Y el nuevo método:

public function ayudawp_enqueue_editor_sidebar() {
    wp_enqueue_script(
        'ayudawp-aiss-editor-sidebar',
        AYUDAWP_AISS_PLUGIN_URL . 'assets/js/editor-sidebar.js',
        array( 'wp-plugins', 'wp-editor', 'wp-components', 'wp-data', 'wp-element', 'wp-i18n' ),
        AYUDAWP_AISS_VERSION,
        true
    );
}

El gancho enqueue_block_editor_assets se dispara solo cuando se carga el editor de bloques, así que el script no se carga en ningún otro sitio.

El archivo completo modificado

Para que no tengas que ir juntando piezas, abajo tienes el archivo includes/class-meta-box.php completo con todos los cambios aplicados, para que veas el resultado final por si te sirve para tu plugin. Puedes descargarlo directamente desde el enlace que he puesto al final del artículo.

Qué pasa con los datos existentes

Las entradas que ya tenían la casilla marcado con la caja meta clásica siguen funcionando con el panel nuevo sin tocar nada. Ambos sistemas leen y escriben en la misma clave de meta (_ayudawp_aiss_exclude). El editor clásico guarda el valor como string '1' y el editor de bloques lo guarda como booleano true, pero la función ayudawp_is_post_excluded() hace un cast a booleano con (bool), así que las dos representaciones funcionan bien. No hay que migrar datos.

Probar la colaboración

Con los cambios hechos, los pasos para comprobar que todo funciona:

1. Asegúrate de tener WordPress 7.0 instalado y la colaboración activada en los ajustes de escritura
2. Abre una entrada en el editor de bloques con dos usuarios distintos. Si todo va bien verás el cursor del otro usuario en el editor y podréis editar a la vez sin que salte el aviso
3. Revisa que el panel «AI Share & Summarize» (o el tuyo, claro) aparece en la barra lateral de la pestaña «Entrada» (no confundir con la pestaña «Bloque»)
4. Marca y desmarca la casilla desde ambas sesiones y comprueba que el cambio se refleja en la otra

Resumen de los cambios para desarrolladores

Para que quede claro qué archivos se tocan y qué cambia en cada uno:

En includes/class-meta-box.php se hacen cuatro modificaciones: se añade revisions_enabled => true al register_post_meta(), se condiciona add_meta_box() para que solo se registre en el editor clásico, se añade el gancho enqueue_block_editor_assets en el constructor, y se añade el método ayudawp_enqueue_editor_sidebar() para encolar el script.

Se crea un archivo nuevo, assets/js/editor-sidebar.js, con el panel del sidebar para el editor de bloques.

No se toca nada más. El handler de save_post se mantiene porque sigue siendo necesario para el editor clásico. La función ayudawp_is_post_excluded() también se mantiene porque lee de la misma clave de meta sea cual sea el editor que la haya guardado.

Resumen de comprobación de compatibilidad de RTC para plugins

Si mantienes plugins de WordPress y quieres que sean compatibles con la colaboración en tiempo real de WordPress 7.0, repasa estos puntos.

Cajas meta

Comprueba si tu plugin registra meta boxes con add_meta_box(). Si lo hace, tienes dos opciones: eliminar la meta box y sustituirla por un panel en el sidebar del editor de bloques, o mantener la meta box solo para el editor clásico y crear el panel en paralelo (como en el ejemplo de arriba). Para cualquiera de las dos opciones, el post meta tiene que estar registrado con register_post_meta() y show_in_rest => true.

Componentes JavaScript

Revisa que todos tus componentes que leen datos compartidos (meta, atributos de bloques) los lean directamente del data store con useSelect. No copies esos valores a useState. Usa inputs controlados (value y checked), no inputs no controlados (defaultValue y defaultChecked).

Efectos secundarios

Si alguno de tus bloques ejecuta código automáticamente al insertarse (abrir un modal, hacer una petición HTTP, disparar un evento), ten en cuenta que ese efecto se ejecutará en todas las sesiones conectadas. Convierte esos disparadores automáticos en acciones manuales para que solo afecten al usuario que los inicia.

Revisiones

Añade revisions_enabled => true a los post meta que modifiques desde el editor. Así el historial de revisiones recoge los cambios en el meta y no solo en el contenido de la entrada.

Cómo desactivar la colaboración desde un plugin

Puede que tengas un plugin donde la colaboración cause problemas que no puedes resolver de momento, o que quieras desactivarla durante un despliegue gradual. Hay una forma limpia de hacerlo sin tocar nada de WordPress.

El filtro sync.providers controla qué proveedores de sincronización están activos. Si devuelves un array vacío la colaboración se desactiva:

import { addFilter } from '@wordpress/hooks';

addFilter( 'sync.providers', 'my-plugin/disable-collab', () => [] );

Esto es temporal y limpio. No afecta a ninguna otra funcionalidad del editor.

Documentación y recursos

Los enlaces a la documentación oficial para profundizar en todo lo que hemos visto:

• Nota oficial de desarrollo de la colaboración en tiempo real – La referencia principal. Cubre las meta boxes, el filtro sync.providers y los problemas comunes para plugins.
• Guía para probar la colaboración en tiempo real – Escenarios de prueba detallados y cómo configurar tu entorno.
• Feedback temprano de usuarios de VIP – Lecciones aprendidas de los primeros usuarios en producción.
• COMMON_ISSUES.md del repositorio de VIP – Ejemplos detallados de código con los anti-patrones más frecuentes y sus correcciones.
• Guía de migración de meta boxes en el Block Editor Handbook.
• Issue de seguimiento #52593 en el repositorio de Gutenberg.
• Clase meta box de Ai Share & Summarize usada en el ejemplo.

Si te ha saltado el aviso de plugins no compatibles y has conseguido identificar cuál era el culpable (o si eres desarrollador y has adaptado tu plugin), cuéntamelo en los comentarios.

Saber qué plugins dan problemas con la colaboración en tiempo real nos viene bien a todos, y si tienes dudas con la migración de cajas meta también te puedo echar una mano por ahí.

La funcionalidad se llama PHP-only block registration y llega gracias al flag autoRegister en la función register_block_type(). Registras tu bloque con PHP, defines los atributos, escribes el callback de renderizado y WordPress se encarga del resto: el bloque aparece en el insertador del editor y genera automáticamente los controles en el panel lateral para que el usuario pueda configurarlo.

¿Es un sustituto de los bloques JavaScript completos? Pues no, y tampoco pretende serlo.

Está pensado para bloques que solo necesitan renderizado del lado del servidor, los típicos que muestran datos dinámicos (últimas entradas, cajas de autor, alertas, widgets de datos) y que no requieren edición en tiempo real dentro del editor.

Para estos casos, que son la mayoría de los que necesita un desarrollador PHP en su día a día, es una solución limpia y sin complicaciones.

En esta guía tienes todo lo necesario para empezar a crear tus propios bloques PHP-only, desde la referencia técnica completa, explicada como yo la he entendido, hasta tres ejemplos prácticos que van de menos a más:

1. Un bloque creado desde cero
2. Migración de un shortcode clásico a bloque
3. Integración real de un bloque en un plugin ya publicado en WordPress.org.

Requisitos para seguir este tutorial: Todos los códigos de esta guía necesitan que tengas instalado ya WordPress 7.0 o superior, disponible desde el 9 de abril de 2026. Si quieres probarlo antes de esa fecha puedes instalar la última beta de WordPress 7.0 con el plugin WordPress Beta Tester o el plugin Gutenberg en un sitio de pruebas. En versiones anteriores de WordPress el flag autoRegister (a continuación lo explico) se ignora y los bloques no aparecerán en el editor.

Cómo funciona autoRegister

Lo que tienes a continuación es la referencia técnica que necesitas como desarrollador PHP para trabajar con esta API. Lo he preparado para que no tengas que ir a buscar en la documentación en inglés cada vez que quieras consultar algo, y por si te sirve mi manera de explicar las cosas.

La estructura básica

Un bloque PHP-only se registra con register_block_type() en el hook init, como cualquier otro bloque, pero con dos requisitos obligatorios:

• El flag autoRegister a true dentro de supports
• Un render_callback que devuelva el HTML del bloque

Demostración, como diría el Malaguita…

add_action( 'init', 'ayudawp_register_my_block' );

function ayudawp_register_my_block() {
    register_block_type(
        'mi-plugin/mi-bloque',
        array(
            'title'           => 'Mi bloque',
            'icon'            => 'admin-generic',
            'category'        => 'widgets',
            'description'     => 'Descripción del bloque.',
            'keywords'        => array( 'ejemplo', 'php' ),
            'attributes'      => array(
                // Aquí van los atributos
            ),
            'render_callback' => 'ayudawp_render_my_block',
            'supports'        => array(
                'autoRegister' => true,
            ),
        )
    );
}

function ayudawp_render_my_block( $attributes ) {
    $wrapper = get_block_wrapper_attributes();
    return sprintf( '<div %s>Contenido del bloque</div>', $wrapper );
}

Cuando WordPress detecta el flag autoRegister registra automáticamente el bloque en el editor del lado del cliente a través de un global JavaScript (autoRegisterBlocks) y utiliza ServerSideRender para la previsualización.

O sea, cada vez que el usuario cambia un atributo en el panel lateral el editor hace una llamada a la API REST de WordPress, ejecuta tu render_callback en PHP y muestra el resultado. Sencillo, limpio, eficaz, como es PHP.

Tipos de atributos y controles automáticos

La gracia de autoRegister es que WordPress genera automáticamente los controles del Inspector (panel lateral del editor) a partir de los atributos que definas. Pero no todos los tipos generan controles, solo los que WordPress sabe representar como campo de formulario.

Estos son los tipos admitidos y el control que genera cada uno:

Los atributos que no encajen en estos tipos (arrays, objetos) o los que tengan el rol local no generan ningún control en el panel.

Un detalle importante es que definas siempre un valor default para cada atributo. Si no lo haces el bloque puede no renderizar nada la primera vez que lo insertes, porque los atributos llegarán vacíos al callback.

Así se definen los atributos en la práctica, cubriendo los cuatro tipos:

'attributes' => array(
    // String → TextControl
    'titulo' => array(
        'type'    => 'string',
        'default' => 'Título por defecto',
    ),
    // String con enum → SelectControl
    'tamano' => array(
        'type'    => 'string',
        'enum'    => array( 'pequeno', 'mediano', 'grande' ),
        'default' => 'mediano',
    ),
    // Integer → NumberControl
    'cantidad' => array(
        'type'    => 'integer',
        'default' => 5,
    ),
    // Boolean → ToggleControl
    'mostrar_fecha' => array(
        'type'    => 'boolean',
        'default' => true,
    ),
),

Los supports nativos funcionan igual

Además de autoRegister, puedes activar los mismos supports que en cualquier bloque (color, espaciado, tipografía, bordes). WordPress aplicará los estilos heredados del tema activo sin que tengas que escribir CSS propio.

'supports' => array(
    'autoRegister' => true,
    'color'        => array(
        'background' => true,
        'text'       => true,
    ),
    'spacing'      => array(
        'margin'  => true,
        'padding' => true,
    ),
    'typography'   => array(
        'fontSize' => true,
    ),
),

Cuando activas estos supports WordPress añade los controles correspondientes en el panel lateral (selector de color, controles de márgenes, etc.) y aplica las clases y estilos inline automáticamente. Para que funcionen correctamente en el HTML de salida, usa siempre get_block_wrapper_attributes() en tu callback de renderizado.

Cargar CSS y JavaScript

Si tu bloque necesita estilos propios o algún script, lo habitual es registrarlos en el hook init y con enqueue desde el callback. De esta forma solo se cargan en las páginas donde esté disponible el bloque.

add_action( 'init', 'ayudawp_register_block_assets' );

function ayudawp_register_block_assets() {
    wp_register_style(
        'ayudawp-mi-bloque-style',
        plugins_url( 'assets/css/mi-bloque.css', __FILE__ ),
        array(),
        '1.0.0'
    );
}

function ayudawp_render_my_block( $attributes ) {
    // Solo se encola cuando se renderiza el bloque
    wp_enqueue_style( 'ayudawp-mi-bloque-style' );

    $wrapper = get_block_wrapper_attributes();
    return sprintf( '<div %s>...</div>', $wrapper );
}

Ejemplo 1: Bloque de caja de información autor (desde cero)

Vamos con el primer ejemplo práctico, que es un bloque muy práctico que muestra la información de un autor de WordPress (avatar, nombre, biografía y enlace a su web). Lo vamos a crear como mu-plugin para que sea fácil de probar.

Este bloque tiene un detalle interesante, y es que el selector de autor se genera dinámicamente a partir de los usuarios de WordPress mediante un enum construido con get_users(). Es un buen ejemplo de cómo aprovechar toda la potencia de PHP dentro de la definición del bloque.

Crea el archivo dentro de /wp-content/mu-plugins/ayudawp-author-box-block.php con el siguiente contenido:

<?php
/**
* Plugin Name: Bloque de caja de autor (PHP)
* Plugin URI: https://servicios.ayudawp.com
* Description: Bloque de caja de autor registrado solo con PHP. Requiere WordPress 7.0 o superior o la última versión del plugin Gutenberg.
* Version: 1.0.0
* Author: Fernando Tellado
* Author URI: https://ayudawp.com
* License: GPL-2.0-or-later
* Requires PHP: 7.4
*/

// Prevent direct file access
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', 'ayudawp_register_author_box_block' );

/**
 * Register the author box PHP-only block.
 *
 * Generates the user list dynamically for the author selector.
 */
function ayudawp_register_author_box_block() {

    // Build the list of users for the selector
    $users    = get_users( array( 'fields' => array( 'ID', 'display_name' ) ) );
    $user_ids = array();

    foreach ( $users as $user ) {
        $user_ids[] = (string) $user->ID;
    }

    // If no users, fallback to avoid empty enum
    if ( empty( $user_ids ) ) {
        $user_ids = array( '1' );
    }

    register_block_type(
        'ayudawp/author-box',
        array(
            'title'           => __( 'Caja de autor', 'ayudawp' ),
            'icon'            => 'admin-users',
            'category'        => 'theme',
            'description'     => __( 'Muestra información del autor: avatar, nombre, biografía y sitio web.', 'ayudawp' ),
            'keywords'        => array( 'author', 'bio', 'avatar' ),
            'attributes'      => array(
                'user_id'      => array(
                    'type'    => 'string',
                    'enum'    => $user_ids,
                    'default' => $user_ids[0],
                ),
                'avatar_size'  => array(
                    'type'    => 'integer',
                    'default' => 96,
                ),
                'show_bio'     => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
                'show_website' => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
            ),
            'render_callback' => 'ayudawp_render_author_box_block',
            'supports'        => array(
                'autoRegister' => true,
                'color'        => array(
                    'background' => true,
                    'text'       => true,
                ),
                'spacing'      => array(
                    'padding' => true,
                    'margin'  => true,
                ),
            ),
        )
    );
}

/**
 * Render callback for the author box block.
 *
 * @param array $attributes Block attributes.
 * @return string Block HTML output.
 */
function ayudawp_render_author_box_block( $attributes ) {

    $user_id      = absint( $attributes['user_id'] ?? 1 );
    $avatar_size  = absint( $attributes['avatar_size'] ?? 96 );
    $show_bio     = (bool) ( $attributes['show_bio'] ?? true );
    $show_website = (bool) ( $attributes['show_website'] ?? true );

    $user = get_userdata( $user_id );

    if ( ! $user ) {
        return '';
    }

    $wrapper = get_block_wrapper_attributes(
        array(
            'style' => 'display:flex;gap:1.5em;align-items:flex-start;',
        )
    );

    $output  = sprintf( '<div %s>', $wrapper );
    $output .= get_avatar( $user_id, $avatar_size );
    $output .= '<div>';
    $output .= sprintf(
        '<strong style="font-size:1.2em;">%s</strong>',
        esc_html( $user->display_name )
    );

    if ( $show_bio && $user->description ) {
        $output .= sprintf(
            '<p style="margin-top:0.5em;">%s</p>',
            esc_html( $user->description )
        );
    }

    if ( $show_website && $user->user_url ) {
        $output .= sprintf(
            '<p><a href="%s" target="_blank" rel="noopener noreferrer">%s</a></p>',
            esc_url( $user->user_url ),
            esc_html( $user->user_url )
        );
    }

    $output .= '</div></div>';

    return $output;
}

Una vez guardado el archivo ve al editor de WordPress, busca «Caja de autor» en el insertador de bloques y deberías tenerlo disponible para insertarlo, hazlo.

Con el bloque ya insertado y seleccionado, en el panel lateral verás un desplegable con los IDs de los usuarios, un campo numérico para el tamaño del avatar y dos interruptores para mostrar u ocultar la biografía y el enlace web.

Además, si activas los supports de color y espaciado, podrás personalizar los colores de fondo y texto, y los márgenes y relleno directamente desde el editor.

Un apunte importante sobre el selector de usuarios es que el control SelectControl que genera WordPress muestra los valores del enum tal cual, en este caso los IDs numéricos de los usuarios. No es lo más elegante visualmente (lo ideal sería mostrar el nombre), pero es la limitación actual de la generación automática de controles.

Para un bloque de producción con un selector más refinado ya necesitarías JavaScript, pero para un uso interno o un tema personalizado funciona de sobra, y se ve perfecto.

Si quieres profundizar en otras formas de mostrar una caja de información del autor en WordPress, por si no te termina de convencer el uso del bloque, y te ha entrado la curiosidad y ganas de usar algo así, echa un vistazo a esta guía sobre cómo mostrar la información del autor sin plugins.

Ejemplo 2: Migrar el shortcode de entradas recientes a bloque

Ahora empieza la parte más interesante del tutorial, pues para empezar a darle caña a esto vamos a tomar un shortcode que ya funciona y convertirlo en un bloque PHP-only.

Usaremos como base el shortcode de entradas recientes que publiqué hace un tiempo, y lo vamos a mejorar de paso con un par de atributos nuevos.

Pero la mejora real no son los atributos extra, sino dónde puedes usar este bloque.

Como shortcode estabas limitado a pegarlo dentro del contenido de una entrada o página, como bloque PHP-only puedes insertarlo en cualquier plantilla del editor de sitio (la página de inicio, el pie de página, la plantilla de entradas individuales, la 404, etc.) sin depender de plugins ni tocar los archivos del tema.

El bloque nativo de últimas entradas de WordPress hace algo parecido, pero no te deja ordenar por número de comentarios, ni mostrar entradas aleatorias, ni activar el extracto con un interruptor, este sí.

El shortcode original

El shortcode [entradas_recientes] usa get_posts() para mostrar una lista de entradas filtrable por categoría, con parámetros de orden y cantidad. Así era el código:

function ayudawp_recent_posts_shortcode( $atts, $content = null ) {
    global $post;
    extract( shortcode_atts( array(
        'cat'     => '',
        'num'     => '5',
        'order'   => 'DESC',
        'orderby' => 'post_date',
    ), $atts ) );
    $args = array(
        'cat'            => $cat,
        'posts_per_page' => $num,
        'order'          => $order,
        'orderby'        => $orderby,
    );
    $output = '';
    $posts  = get_posts( $args );
    foreach ( $posts as $post ) {
        setup_postdata( $post );
        $output .= '<li><a href="' . get_the_permalink() . '">' . get_the_title() . '</a></li>';
    }
    wp_reset_postdata();
    return '<ul>' . $output . '</ul>';
}
add_shortcode( 'entradas_recientes', 'ayudawp_recent_posts_shortcode' );

Qué cambia al convertirlo en bloque

Los parámetros del shortcode se convierten en atributos del bloque, y cada uno se mapea al tipo que mejor encaje para generar un control automático en el editor:

Los dos atributos nuevos (show_date y show_excerpt) son de tipo boolean, así que generarán un interruptor cada uno en el panel lateral. De esta forma, en un solo ejemplo ves los cuatro tipos de control que genera autoRegister.

El bloque completo

Crea el archivo wp-content/mu-plugins/ayudawp-recent-posts-block.php:

<?php
/**
* Plugin Name: Bloque de entradas recientes
* Description: Bloque PHP-only de entradas recientes. Migración del shortcode [entradas_recientes]. Requiere WordPress 7.0 o superior, o el plugin Gutenberg 14.0+ en versiones anteriores.
* Plugin URI: https://servicios.ayudawp.com
* Version: 1.0.0
* Author: Fernando Tellado
* Author URI: https://ayudawp.com
* License: GPL-2.0-or-later
* Requires PHP: 7.4
*/

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', 'ayudawp_register_recent_posts_block' );

/**
 * Register the recent posts PHP-only block.
 */
function ayudawp_register_recent_posts_block() {
    register_block_type(
        'ayudawp/recent-posts',
        array(
            'title'           => __( 'Entradas recientes (PHP)', 'ayudawp' ),
            'icon'            => 'list-view',
            'category'        => 'theme',
            'description'     => __( 'Muestra una lista personalizable de entradas recientes.', 'ayudawp' ),
            'keywords'        => array( 'posts', 'recent', 'latest', 'entries' ),
            'attributes'      => array(
                'num'          => array(
                    'type'    => 'integer',
                    'default' => 5,
                ),
                'cat'          => array(
                    'type'    => 'string',
                    'default' => '',
                ),
                'order'        => array(
                    'type'    => 'string',
                    'enum'    => array( 'DESC', 'ASC' ),
                    'default' => 'DESC',
                ),
                'orderby'      => array(
                    'type'    => 'string',
                    'enum'    => array( 'post_date', 'title', 'modified', 'rand', 'comment_count' ),
                    'default' => 'post_date',
                ),
                'show_date'    => array(
                    'type'    => 'boolean',
                    'default' => false,
                ),
                'show_excerpt' => array(
                    'type'    => 'boolean',
                    'default' => false,
                ),
            ),
            'render_callback' => 'ayudawp_render_recent_posts_block',
            'supports'        => array(
                'autoRegister' => true,
                'color'        => array(
                    'text' => true,
                    'link' => true,
                ),
                'spacing'      => array(
                    'margin'  => true,
                    'padding' => true,
                ),
                'typography'   => array(
                    'fontSize' => true,
                ),
            ),
        )
    );
}

/**
 * Render callback for the recent posts block.
 *
 * @param array $attributes Block attributes.
 * @return string Block HTML output.
 */
function ayudawp_render_recent_posts_block( $attributes ) {

    $num          = absint( $attributes['num'] ?? 5 );
    $cat          = sanitize_text_field( $attributes['cat'] ?? '' );
    $order        = in_array( $attributes['order'] ?? 'DESC', array( 'ASC', 'DESC' ), true )
                    ? $attributes['order']
                    : 'DESC';
    $orderby      = sanitize_key( $attributes['orderby'] ?? 'post_date' );
    $show_date    = (bool) ( $attributes['show_date'] ?? false );
    $show_excerpt = (bool) ( $attributes['show_excerpt'] ?? false );

    $args = array(
        'posts_per_page' => $num,
        'order'          => $order,
        'orderby'        => $orderby,
        'post_status'    => 'publish',
    );

    if ( ! empty( $cat ) ) {
        $args['cat'] = absint( $cat );
    }

    $posts = get_posts( $args );

    if ( empty( $posts ) ) {
        return '';
    }

    $wrapper = get_block_wrapper_attributes();
    $output  = sprintf( '<div %s><ul style="list-style:none;padding:0;">', $wrapper );

    foreach ( $posts as $post ) {
        $output .= '<li style="margin-bottom:0.75em;">';
        $output .= sprintf(
            '<a href="%s">%s</a>',
            esc_url( get_permalink( $post ) ),
            esc_html( get_the_title( $post ) )
        );

        if ( $show_date ) {
            $output .= sprintf(
                ' <span style="color:#666;font-size:0.85em;">— %s</span>',
                esc_html( get_the_date( '', $post ) )
            );
        }

        if ( $show_excerpt && $post->post_excerpt ) {
            $output .= sprintf(
                '<br><span style="font-size:0.9em;color:#555;">%s</span>',
                esc_html( wp_trim_words( $post->post_excerpt, 20 ) )
            );
        }

        $output .= '</li>';
    }

    $output .= '</ul></div>';

    return $output;
}

/*
 * Opcional: mantiene funcional el shortcode por retro-compatibilidad.
 * Los usuarios que ya tengan [entradas_recientes] en su contenido
 * pueden seguir usándolo mientras migran al bloque.
 */
add_shortcode( 'entradas_recientes', 'ayudawp_recent_posts_shortcode_compat' );

/**
 * Shortcode compatibility wrapper.
 *
 * @param array  $atts    Shortcode attributes.
 * @param string $content Shortcode content (unused).
 * @return string HTML output.
 */
function ayudawp_recent_posts_shortcode_compat( $atts, $content = null ) {
    $atts = shortcode_atts(
        array(
            'cat'     => '',
            'num'     => '5',
            'order'   => 'DESC',
            'orderby' => 'post_date',
        ),
        $atts,
        'entradas_recientes'
    );

    return ayudawp_render_recent_posts_block(
        array(
            'num'          => (int) $atts['num'],
            'cat'          => $atts['cat'],
            'order'        => $atts['order'],
            'orderby'      => $atts['orderby'],
            'show_date'    => false,
            'show_excerpt' => false,
        )
    );
}

Qué hemos ganado con la migración

Fíjate en lo que ha cambiado, que es mucho:

• El usuario ya no necesita recordar la sintaxis [entradas_recientes num="5" cat="12"]. Inserta el bloque desde el insertador, configura todo desde el panel lateral con controles visuales y ve una previsualización en tiempo real de las entradas seleccionadas.
• El callback de renderizado es prácticamente el mismo que el del shortcode, con las mejoras de seguridad (validación de los parámetros, esc_url(), esc_html()) y los dos atributos nuevos.

Al final del archivo hemos incluido además una función de compatibilidad que mantiene el shortcode [entradas_recientes] funcionando, reutilizando el mismo callback del bloque. Así, las entradas o páginas que ya tengan el shortcode insertado seguirán mostrando las entradas recientes sin tener que tocar nada. Puedes ir migrando a tu ritmo.

Este patrón de migración (bloque nuevo + shortcode de compatibilidad que llama al mismo renderizado) es exactamente lo que deberías aplicar siempre que conviertas un shortcode a bloque. Nunca elimines el shortcode de golpe, mantenlo como alternativa.

Para saber más sobre shortcodes y cómo crearlos, tienes la guía completa de shortcodes de WordPress. Y si te has encontrado con el problema de los shortcodes que dejan de funcionar al desactivar un plugin, echa un vistazo a la guía de shortcodes huérfanos.

Ejemplo 3: Migrar el shortcode de botones de AI Share & Summarize a bloque

Para cerrar los ejemplos prácticos vamos con un caso real sobre un plugin publicado en WordPress.org, y no es ni más ni menos que la migración del shortcode [ayudawp_share_buttons] del plugin AI Share & Summarize a un bloque PHP-only.

Este plugin combina botones de compartir en redes sociales con botones para generar resúmenes en IA (Claude, ChatGPT, Perplexity, DeepSeek y muchas más). Tiene inserción automática, pero también un shortcode muy completo con parámetros para el estilo, tamaño, iconos, alineación y selección de botones concretos.

El shortcode que vamos a migrar

El shortcode admite estos parámetros principales:

[ayudawp_share_buttons style="brand" size="normal" show_icons="true" alignment="left" icon_style="circular"]

Cada uno de estos parámetros se traduce directamente en un atributo del bloque:

Cómo se integra en el plugin

A diferencia de los ejemplos anteriores (que son mu-plugins independientes) aquí el bloque se registra dentro del propio plugin, en un archivo nuevo de la carpeta /includes.

La clave está en el render_callback: en vez de pasar por do_shortcode(), llama directamente al método estático AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html(), que es la misma función que ya usa internamente el shortcode para generar el HTML de los botones. Es mucho más eficiente y sin duplicar código.

Si miras la clase AyudaWP_AISS_Shortcode del plugin, verás que el shortcode pilla las opciones guardadas con get_option( 'ayudawp_aiss_options' ), sobrescribe las que vengan como parámetro del shortcode y pasa todo a AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html().

El render callback del bloque hace exactamente lo mismo, pero recibiendo los valores desde los atributos del bloque en vez de desde los parámetros del shortcode.

<?php
/**
 * PHP-only block registration for AI Share & Summarize
 *
 * @package AiShareSummarize
 * @since   2.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', 'ayudawp_aiss_register_share_block' );

/**
 * Register the share buttons as a PHP-only block.
 */
function ayudawp_aiss_register_share_block() {
    register_block_type(
        'ayudawp/share-buttons',
        array(
            'title'           => __( 'AI Share & Summarize', 'ai-share-summarize' ),
            'icon'            => 'share',
            'category'        => 'widgets',
            'description'     => __( 'Share buttons and AI summary buttons.', 'ai-share-summarize' ),
            'keywords'        => array( 'share', 'social', 'ai', 'summarize' ),
            'attributes'      => array(
                'style'      => array(
                    'type'    => 'string',
                    'enum'    => array( 'minimal', 'brand', 'outline', 'dark', 'custom', 'icons-only' ),
                    'default' => 'minimal',
                ),
                'size'       => array(
                    'type'    => 'string',
                    'enum'    => array( 'compact', 'normal', 'large', 'fluid' ),
                    'default' => 'normal',
                ),
                'show_icons' => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
                'alignment'  => array(
                    'type'    => 'string',
                    'enum'    => array( 'left', 'center' ),
                    'default' => 'left',
                ),
                'icon_style' => array(
                    'type'    => 'string',
                    'enum'    => array( 'circular', 'square' ),
                    'default' => 'circular',
                ),
                'show_title' => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
            ),
            'render_callback' => 'ayudawp_aiss_render_share_block',
            'supports'        => array(
                'autoRegister' => true,
                'spacing'      => array(
                    'margin'  => true,
                    'padding' => true,
                ),
            ),
        )
    );
}

/**
 * Render callback for the share buttons block.
 *
 * Replicates the shortcode logic: loads plugin options,
 * overrides with block attributes, and calls the existing
 * AyudaWP_AISS_Buttons renderer directly.
 *
 * @param array $attributes Block attributes.
 * @return string Block HTML output.
 */
function ayudawp_aiss_render_share_block( $attributes ) {

    // Check the rendering class exists (plugin active)
    if ( ! class_exists( 'AyudaWP_AISS_Buttons' ) ) {
        return '';
    }

    // Load the saved plugin options as base
    $options = get_option( 'ayudawp_aiss_options' );

    if ( ! is_array( $options ) ) {
        return '';
    }

    $block_options = $options;

    // Override options with block attributes (same as shortcode does)
    if ( ! empty( $attributes['style'] ) ) {
        $block_options['button_colors'] = sanitize_text_field( $attributes['style'] );
    }

    if ( ! empty( $attributes['size'] ) ) {
        $block_options['button_size'] = sanitize_text_field( $attributes['size'] );
    }

    if ( isset( $attributes['show_icons'] ) ) {
        $block_options['show_icons'] = (bool) $attributes['show_icons'];
    }

    if ( ! empty( $attributes['icon_style'] ) ) {
        $block_options['icon_style'] = sanitize_text_field( $attributes['icon_style'] );
    }

    if ( isset( $attributes['show_title'] ) && ! $attributes['show_title'] ) {
        $block_options['title_text'] = '';
    }

    // Get the enabled buttons from plugin settings
    $enabled_buttons = isset( $options['enabled_buttons'] ) ? $options['enabled_buttons'] : array();

    if ( empty( $enabled_buttons ) || ! is_array( $enabled_buttons ) ) {
        return '';
    }

    $current_url   = get_permalink();
    $current_title = get_the_title();

    // Call the same renderer the shortcode uses
    $html = AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html(
        $enabled_buttons,
        $block_options,
        $current_url,
        $current_title
    );

    if ( empty( $html ) ) {
        return '';
    }

    $wrapper = get_block_wrapper_attributes();

    return sprintf( '<div %s>%s</div>', $wrapper, $html );
}

Fíjate en el render callback, hace exactamente lo mismo que el método ayudawp_shortcode_share_buttons() de la clase AyudaWP_AISS_Shortcode, carga las opciones del plugin, sobrescribe con los valores que vienen del bloque (en vez de los del shortcode), y pasa todo a AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html() junto con la URL y título de la entrada actual.

El resultado es que bloque y shortcode comparten el mismo motor de renderizado, sin duplicar nada de código.

El usuario podrá insertar los botones de compartir y resumir como un bloque nativo del editor, configurando el estilo, tamaño, iconos y alineación desde el panel lateral, con una previsualización que se actualiza con cada cambio.

El shortcode [ayudawp_share_buttons] seguirá funcionando exactamente igual para todos los que ya lo tengan insertado en su contenido, que la compatibilidad no se toca.

Esta integración estará disponible en una próxima versión del plugin. Aún no está perfecta pero lo estará.

Cuándo usar bloques PHP-only y cuándo no

Después de ver los tres ejemplos, conviene tener claro para qué sirve esta herramienta y para qué no. No todo debería ser un bloque PHP-only, igual que no todo debería ser un shortcode.

Es buena elección cuando…

Los bloques PHP-only son la opción adecuada para contenido dinámico que se genera en el servidor, sin necesidad de interacción en el editor más allá de configurar unos parámetros.

Hay muchos ejemplos de esto, como listados de entradas, cajas de autor, alertas o avisos personalizables, CTAs, widgets de datos, embeds de herramientas propias, botones de compartir, bloques informativos que tiran de la base de datos o de APIs externas, suma y sigue.

Todo lo que antes resolvías con un shortcode o con una función en el functions.php pero con la ventaja de una interfaz visual en el editor.

También son ideales para temas de bloques y FSE, donde puedes crear componentes específicos para tu tema sin depender de plugins de terceros.

No es la mejor opción cuando…

Si necesitas edición en tiempo real dentro del editor, como por ejemplo, escribir texto directamente en el bloque, arrastrar elementos o manipular contenido inline. En estos casos necesitas un bloque JavaScript completo. Pasa lo mismo si tu bloque debe contener otros bloques dentro (InnerBlocks), que es algo que los bloques PHP-only no admiten de momento.

Ten en cuenta que la previsualización de un bloque PHP-only usa ServerSideRender, por lo que cada vez que cambias un atributo, el editor hace una petición REST al servidor para obtener el HTML actualizado. Para bloques sencillos esto es imperceptible pero si tu callback hace consultas pesadas o llamadas a APIs externas, cada cambio de atributo puede generar un retardo visible en el editor.

¿Y los shortcodes?

Los shortcodes siguen siendo perfectamente válidos para retro-compatibilidad y para situaciones o webs donde no puedes usar el editor de bloques (campos personalizados, widgets clásicos, plantillas PHP). Pero si estás creando algo nuevo los bloques PHP-only son su sucesor natural porque ofrecen la misma facilidad de desarrollo con una experiencia de usuario mucho mejor en el editor.

Consejos prácticos y errores comunes

Para terminar unas cuantas cosas que no están en la documentación oficial y que te pueden ahorrar algún dolor de cabeza:

• Define siempre valores default en los atributos. Si un atributo llega vacío o sin definir al callback, tu bloque puede renderizar en blanco o dar un error. Un default te garantiza que siempre hay un valor válido con el que trabajar.
• Usa siempre get_block_wrapper_attributes(). Esta función genera los atributos HTML del contenedor del bloque (clases, estilos inline de los supports como color o espaciado). Si no la usas, los supports que actives no tendrán efecto.
• El namespace del bloque es obligatorio. El primer argumento de register_block_type() debe llevar el formato namespace/nombre-bloque (por ejemplo, ayudawp/author-box). Sin el namespace, el registro fallará.
• Los enum solo muestran el valor, no una etiqueta legible. Si tu enum tiene valores como array( 'small', 'medium', 'large' ), el desplegable en el editor mostrará exactamente esos textos. No hay forma (de momento) de mostrar una etiqueta más descriptiva al lado de cada valor sin recurrir a JavaScript.
• Las etiquetas de los controles son el nombre del atributo. Los controles que genera autoRegister en el panel lateral usan directamente el nombre del atributo como etiqueta, en mayúsculas y sin formato. No hay ninguna propiedad para personalizar esa etiqueta desde PHP. Por eso conviene nombrar los atributos de forma legible desde el principio (por ejemplo, autor en vez de user_id, o biografia en vez de show_bio). No es lo ideal pero es lo que hay de momento. Si necesitas etiquetas descriptivas y una interfaz más cuidada en el panel lateral, ya te toca escribir JavaScript con InspectorControls.
• Cuidado con las plantillas en el editor de sitio. Se ha detectado un problema en las betas de WordPress 7.0 donde los bloques PHP-only se renderizan correctamente en las previsualizaciones de plantillas, pero el CSS aplicado globalmente o por bloque no siempre se muestra. Es un tema que el equipo de desarrollo está resolviendo.
• InnerBlocks no están soportados. No puedes crear un bloque PHP-only que acepte otros bloques dentro. Si necesitas esta funcionalidad, toca usar bloques JavaScript.
• El rendimiento del editor depende de tu callback. Como cada cambio de atributo genera una petición REST que ejecuta tu render_callback, intenta que sea lo más ligero posible. Si haces consultas a la base de datos, plantéate usar transients para cachear los resultados.
• No necesitas block.json. Para bloques PHP-only, toda la definición del bloque (título, icono, categoría, atributos, supports) va directamente en el array que pasas a register_block_type(). No necesitas crear un archivo block.json separado.

Próximos pasos

WordPress 7.0 está disponible desde el 9 de abril de 2026. Si quieres probar todo esto antes puedes instalarte una versión beta o el plugin Gutenberg en un sitio de pruebas.

De cara a WordPress 7.1, el equipo de desarrollo ya está trabajando en Block Fields, una evolución de esta misma idea que promete ampliar los tipos de controles automáticos disponibles, y en mejorar la compatibilidad con Block Bindings, el sistema que conecta los atributos de los bloques con fuentes de datos externas.

Todo apunta a que la creación de bloques solo con PHP seguirá mejorando en las próximas versiones.

Si quieres aprender a crear estos bloques usando inteligencia artificial como copiloto, en la guía de vibe coding y agentic coding para WordPress tienes técnicas y prompts concretos para generar código de plugins y bloques con Claude o ChatGPT.

Y si necesitas repasar los fundamentos de PHP antes de meterte con los bloques, la guía de PHP básico para WordPress es un buen punto de partida, y cuando descubras que esta magia del código es lo tuyo, aquí tienes el único curso de programación para WordPress que existe, preparado por mi y muchos de los mejores profesionales que hay.

Para todo lo demás aquí me tienes.