WordPress Pódcast (español)

Vuelve a aparecer un problema histórico en WordPress: la lista de usuarios se puede ordenar siempre por nombre, pero no por apellidos.

Recuerda que puedes escuchar este programa desde:

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 28 de septiembre al 4 de octubre de 2026.

Gutenberg 24.1 es, ante todo, una versión de consistencia en las herramientas de diseño: unas 140 de sus contribuciones se dedican a que casi todos los bloques de core tengan las mismas opciones de fondo, color, sombra y tipografía. Imagen de fondo, tamaño y degradado, sombras, bordes y colores de enlaces, encabezados y botones llegan ya a bloques como Acordeón, Tabs, Comentarios o los de entrada, y los bloques Grupo, Biografía del autor y Lista de términos ganan además soporte de columnas de texto. La sombra de texto que se estrenó hace unas versiones tiene ahora panel propio en Estilos Globales y está disponible en Párrafo y Encabezado, y los bloques Cover y Media y Texto estrenan una sección de selección de medios en el inspector, igual que ya tenían Imagen y Logo del sitio.

El plugin de la Presence API, la pieza que muestra quién está trabajando y dónde dentro del escritorio de WordPress y que se anunció en abril, llega a la versión 0.14.0 con varias novedades de calado. La más relevante es el soporte multisitio: el administrador de red puede ver ahora quién está conectado en todos los sitios a la vez, activado por defecto en redes que no sean grandes. También cambia cómo se gestionan los bloqueos de edición de entradas, que pasan de guardarse como metadatos de la entrada a vivir en la tabla propia de presencia; así, renovar un bloqueo ya no invalida la caché de consultas de entradas en sitios con caché de objetos persistente, un problema de rendimiento real. La presencia funciona además con cualquier tipo de contenido con editor, incluido lo que alguien tenga abierto en el Editor del Sitio, y con roles que solo editan páginas o tipos personalizados.

Dos aspectos destacan por encima del resto. En privacidad, el registro está activado por defecto, pero se puede desactivar por sitio o para toda la red, y hay sección en la política de privacidad y herramientas de exportación y borrado de datos; además, saber dónde está cada persona queda reservado por defecto a quien pueda listar usuarios, mientras que el resto solo ve quién está conectado. Y en el apartado de IA, los agentes que editan por la API REST o por MCP no envían el pulso de actividad habitual, así que desde la 0.13 cada guardado registra una presencia temporal que aparece con una etiqueta de «Agente» en la barra de administración y en la columna de editores. El plugin no decide quién es un agente: lo consulta al plugin Agent Users o a cualquier otro que responda por el filtro previsto. Entre los pulidos, mejor rendimiento con una sola pestaña que consulta y comparte resultados con las demás, Site Health que avisa si Heartbeat no mantiene la presencia al día, y un depurador en la barra de administración solo para desarrollo.

Se ha reabierto un viejo problema de WordPress: en la pantalla de perfil el nombre siempre va antes que el apellido y ningún idioma puede cambiarlo. En japonés, húngaro, chino, coreano o vietnamita se escribe primero el apellido, y WordPress ya lo admite a la hora de mostrar el nombre públicamente, pero no al introducirlo. El ticket de Trac más antiguo es de 2008, y desde entonces el asunto ha ido de aplazamiento en aplazamiento, a la espera de una solución global con un único campo de nombre completo que nunca ha llegado, mientras los usuarios de Japón o Malasia recurren a trucos como meter el apellido en el campo del nombre o invertir los campos con CSS.

La propuesta es partir el problema en dos. Primero, un cambio pequeño: que cada idioma pueda reordenar los campos del perfil mediante una cadena traducible y un filtro, sin alterar el significado de los datos, de modo que no hay problemas de compatibilidad. Después, y más adelante, un ajuste a nivel de sitio con tres opciones: nombre primero, apellido primero o campo único de nombre completo. Fumiki reconoce el sesgo de la muestra: quienes participan en Slack o en Trac ya se han acostumbrado al orden inglés y responden que no les molesta, pero la persona más afectada, como el dueño de un pequeño café que monta su web en su idioma, casi nunca aparece por ahí. Pide a los equipos de cada idioma que cuenten cómo se escriben los nombres en documentos oficiales, qué hacen hoy en WordPress y si el cambio les serviría.

Los primeros comentarios ya aportan matices: en ruso lo formal es apellido primero, pero el orden actual de WordPress no resulta extraño porque nombre, patronímico y apellido también es natural, y lo habitual es omitir el patronímico si no hay campo, antes que mezclarlo con el nombre o el apellido. Tor-Björn Fjellner, mentor de Polyglots, defiende que lo más razonable es un único campo, porque es imposible adivinar dónde va cada parte, y sugiere un segundo campo con el valor de ordenación. Fumiki lo ve coherente con las recomendaciones de internacionalización del W3C, y añade que lo que más le interesa es saber cómo escribe la gente de verdad su nombre en cada región, no la teoría.

Se ha detectado una contradicción en el manual de Comunidad sobre quién puede organizar un evento de meetup. Una página del manual, titulada «Any Member Can Organize an Event», dice que cualquier miembro puede hacerlo sin filtros, mientras que las Cinco Reglas de Buena Fe hablan de miembros «fiables y de confianza». La autora de la propuesta se encontró en medio cuando alguien que nunca había ido a un meetup le pidió organizar uno y le sugirió asistir primero a uno existente; un miembro le preguntó entonces si cualquiera puede organizar o no, y no supo dar una respuesta clara. Su hipótesis es que, al dividir el contenido en páginas separadas en 2023, el texto se copió pero se perdió el contexto: en la versión de 2016 la frase hablaba de una casilla concreta en las herramientas del grupo, y el título de la página actual la convierte en un principio general.

La respuesta del equipo, que le llegó por mensaje privado y no está escrita en ningún sitio, es que cualquier miembro puede organizar un evento sin ser co-organizador, pero debe coordinarse con los co-organizadores, que confirman que es de fiar y que cumple las reglas. Por eso se propone confirmar esa interpretación, retirar la página «Any Member Can Organize an Event» y repartir su contenido entre la documentación de gestión del grupo, las reglas y el registro del caso en la auditoría de manuales.

En el equipo de Fotos han detectado que la norma contra las imágenes generadas por IA existe, pero solo de forma oral. Se han repasado los hilos del canal de Slack desde 2023 y se ha dicho en varias ocasiones que una imagen generada no es una fotografía y no se acepta, y los moderadores piden que se envíen solo fotos reales. Sin embargo, ni las directrices, ni la lista de comprobación previa a la subida, ni el correo de rechazo, ni las preguntas frecuentes mencionan la IA, así que quien envía una imagen no se entera hasta que se la rechazan. Tampoco hay documentado cómo recurrir un rechazo, lo que ha dejado sin respuesta a contribuyentes que decían haber subido fotos reales, con la dificultad añadida de que la imagen se borra al rechazarla.

La propuesta son cuatro cambios sencillos: añadir «imágenes generadas por IA» a la frase de las directrices que ya excluye capturas de pantalla y arte digital, hacer lo mismo en la casilla de la lista de comprobación, ampliar el motivo de rechazo «No es una foto» o crear uno propio para la IA, y añadir a las preguntas frecuentes que quien crea que ha sido un error puede responder al correo de rechazo adjuntando la foto. Se limita a imágenes totalmente generadas, y deja para otro debate la edición con IA, como el escalado o el relleno generativo.

bbPress 2.6.19 es una nueva versión de seguridad que aplica las contraseñas heredadas de los foros a las respuestas de la API REST y a la actividad de BuddyPress, y refuerza las comprobaciones de acceso al contenido restringido en feeds, foros de grupo y otras vistas indirectas. También endurece los permisos de moderación y de roles de foro, protege las credenciales del importador y la gestión de cuentas, y mejora el escapado en perfiles y administración.

Entre los arreglos de mantenimiento hay correcciones en las asociaciones y notificaciones de foros de grupo de BuddyPress, en la limpieza del conversor, en las contraseñas de bases de datos importadas, en los correos de suscripción y en la posición de las respuestas.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Si quieres contribuir en WordPress mediante una IA, ya puedes conectar el servidor MCP del Trac para encontrar tickets, cambios y todo lo necesario para rebuscar entre todo el trabajo pendiente.

Recuerda que puedes escuchar este programa desde:

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 21 al 27 de septiembre de 2026.

Cuarta versión de seguridad de la serie en apenas mes y medio, y esta vez con severidad crítica: WordPress 7.1.2 corrige una vulnerabilidad reportada de forma responsable que permite a un atacante sin autenticar hacer que la resolución de plantillas de página incluya un archivo PHP local arbitrario, siempre que sea legible, situado fuera de los directorios del tema activo. Si se dan ciertas condiciones previas tanto en el entorno del servidor como en el tema activo, esto puede derivar en ejecución remota de código. Tiene CVE propio, el CVE-2026-87902.

Actualización recomendada de forma inmediata, sin excusas esta vez: los parches ya se han retroportado a todas las ramas con soporte de seguridad, desde la 4.7 hasta la 7.0, así que toca comprobar versión y actualizar cuanto antes.

Consecuencia directa del episodio que ya contamos sobre el lanzamiento de WordPress 7.1 en el escenario de WordCamp US: Anne McCarthy anuncia que WordPress abandona el formato de lanzamiento en directo sobre un escenario. Tras dos rondas del experimento, como el State of the Word 2025 y la propia 7.1 en WordCamp US, el equipo reconoce que atar el lanzamiento a un evento físico trae más problemas que ventajas: logística compleja, límites de cuánta gente del release squad puede desplazarse al evento, y el propio squad reportando que ejecutar un proceso que no estaba pensado para hacerse sobre un escenario añade estrés real de más.

La alternativa, propuesta por Matt tras hablarlo con Anne, es pasar a un formato de seminario web por Zoom en streaming, sin fecha de evento fija: quienes forman parte del release squad y de la propia versión pueden compartir la sesión en directo, mientras el resto observa y pregunta, permitiendo que participe más gente del equipo según su zona horaria, sin el coste de desplazarse a un evento. Este nuevo formato arranca ya con WordPress 7.2, prevista para principios de diciembre, con más detalles sobre cómo unirse a medida que se acerque la fecha.

Gutenberg ha completado la migración de sus tests unitarios y de integración en JavaScript, dejando atrás Jest en favor de Vitest. El motivo son dos ventajas de peso: mejor soporte nativo de módulos modernos de JavaScript, que con Jest exigía mantener configuración especial cada vez que una dependencia adoptaba ese formato; y la posibilidad de ejecutar tests de componentes en un navegador real en lugar de simularlo, para comprobar cosas como estilos calculados, tamaños, scroll o interacción por teclado sin depender de imitaciones. Los propios tests en Vitest terminaron antes que el grupo más lento de los que corren en Node, así que la nueva cobertura en navegador no ha alargado el tiempo total de ejecución.

Para los que contribuyen en el núcleo de WordPress, ya hay servidor MCP público y gratuito para consultar Trac desde cualquier asistente de IA, sin cuenta ni clave de API. Funciona con Claude, ChatGPT o cualquier otro cliente compatible con MCP, y permite preguntar cosas como qué queda pendiente en un ticket concreto y qué pull requests siguen abiertos, o pedir un resumen de un changeset y su diff, con herramientas específicas para buscar tickets, leer un ticket con su discusión y adjuntos, consultar un changeset, o revisar el timeline. Por defecto conecta con el Trac de Core, pero funciona igual con el resto de Tracs de WordPress.org, como Meta, Themes, Plugins, bbPress, BuddyPress o GlotPress, cambiando el endpoint.

El WordPress Contributor Toolkit llega a la 1.2 con una novedad de peso: soporte completo para contribuir también a Gutenberg, no solo al núcleo. El flujo es paralelo al de Core: al crear un sitio se elige si se contribuye a WordPress Core o a Gutenberg, una decisión que ya no se puede cambiar después y que determina qué repositorio clona y cómo lo construye. Para Gutenberg, en lugar de vincular un ticket de Trac se vincula un issue de GitHub, que trae consigo sus propias pull requests con un botón «Apply…» para probarlas directamente, y al terminar el trabajo se puede abrir la pull request en el repositorio correspondiente sin salir de la aplicación, con autenticación por device flow que vive solo en memoria mientras la aplicación está abierta.

El Dev Tools Dock de WordPress Playground suma una herramienta más: un panel de correo electrónico que captura y muestra los correos que genera el sitio, sin montar servidor de correo ni revisar una bandeja de entrada real. Cuando WordPress envía un mensaje por su vía habitual, PHP lo escribe hacia un programa compatible con sendmail, y Playground intercepta ese mensaje en el navegador en lugar de entregarlo de verdad, mostrándolo con su asunto, remitente, destinatario y cuerpo, con vista previa en HTML si el mensaje lo lleva. Es útil para casi cualquier plugin que envíe correos por el camino normal de WordPress: formularios de contacto, mensajes de bienvenida o aprobación en membresías, confirmaciones de pedidos o reservas, o simplemente para comparar cómo queda una plantilla de correo entre distintos temas o versiones de WordPress.

Tercera versión de bbPress en poco más de un mes, aunque esta vez sin sobresaltos de seguridad: la 2.6.18 es una versión de mantenimiento centrada en importación de foros antiguos y en la actualización de contraseñas en el primer inicio de sesión. Los usuarios importados desde formatos de foro antiguos pueden ahora actualizar su contraseña al iniciar sesión por primera vez, incluso en casos donde ya no existe la base de datos original del foro; también se corrigen los estados de tema, el recuento de respuestas y las fechas de foro al importar desde PHPWind, y se restaura el enlace de edición de Super Moderador en las pantallas de usuario del frontend.

El equipo de Comunidad da novedades sobre la migración de los grupos de meetup de WordPress desde Meetup.com hacia events.WordPress.org, la alternativa basada en GatherPress. Tras la llamada a pruebas de finales de agosto, que dejó bastante feedback útil, el plan para los cerca de 700 grupos afectados avanza en tres fases: ahora mismo se está trabajando sobre ese feedback; el siguiente paso es que grupos reales organicen eventos reales en la plataforma para ver qué funciona y qué se rompe, incluyendo probar la herramienta de migración que importa datos desde Meetup.com; y solo cuando la plataforma y esa vía de migración hayan aguantado el uso real, se abrirá al resto de grupos.

Hay ya varias cosas decididas: la herramienta de migración importará eventos próximos y sedes como borradores para que el organizador los revise antes de publicar, pero no copiará la lista de miembros, ya que cada persona tendrá que unirse por su cuenta con una cuenta de WordPress.org, y de momento la ejecutará alguien del propio equipo en lugar del organizador del grupo, con los eventos pasados fuera de esta primera ronda. Precisamente por eso el equipo insiste en que quien organice un grupo empiece ya a animar a sus miembros a crearse una cuenta de WordPress.org, porque va a ser un requisito ineludible para poder seguir en el grupo tras la migración.

Quedan dos preguntas abiertas relevantes: si será posible migrar miembros en bloque emparejando cuentas de Meetup con cuentas de WordPress.org, algo que depende de una decisión pendiente sobre gestión de datos de usuarios; y qué pasará finalmente con la página de Meetup.com de cada grupo, que durante el piloto se mantendrá activa pero redirigiendo a la nueva plataforma en lugar de llevar su propia lista de asistencia paralela.

Mary Hubbard, directora ejecutiva del Proyecto WordPress, asume la presidencia de la Open Website Alliance, el organismo que agrupa a las organizaciones detrás de Drupal, Joomla!, TYPO3 y WordPress para defender el software libre de forma conjunta. El cargo es rotatorio entre los miembros de la Alianza, así que le toca el turno a WordPress.

La Alianza nació en 2024 a partir del trabajo conjunto de estos cuatro proyectos respondiendo a la Cyber Resilience Act de la Unión Europea, defendiendo ante los legisladores que sus gestores de contenido no son solo infraestructura digital de base, sino la maquinaria con la que negocios reales llegan a sus clientes y venden productos, y que cualquier requisito de seguridad debería tener en cuenta ese papel económico sin ahogar cómo trabajan las comunidades de desarrolladores, traductores y colaboradores que mantienen el software.

Hubbard enmarca el nombramiento en la misma línea que la reciente firma de WordPress de la carta sobre modelos de IA de peso abierto: la idea de que cualquiera debería tener libertad para usar, modificar y compartir las herramientas de las que depende.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Ya sabemos el roadmap para WordPress 7.2, lo que se plantea que llegue en esta versión, y lo que no debería llegar.

Recuerda que puedes escuchar este programa desde:

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 14 al 20 de septiembre de 2026.

WordPress 7.2 está previsto para principios de diciembre de 2026, y el equipo ya ha publicado el roadmap oficial del ciclo. Como en cada roadmap, el propio equipo avisa de que todo lo que aparece aquí está en desarrollo activo, pero nada garantiza que llegue tal cual a la versión final: es la hoja de ruta de intenciones, no una lista cerrada de compromisos.

La novedad que más titulares se ha llevado esta semana es el propio tema por defecto: se llama Ipsum, y con él WordPress rompe una tradición de más de una década de bautizar sus temas con el año de lanzamiento. A partir de ahora, cada tema por defecto tendrá su propio nombre y cambiará cuando el diseño lo pida, no cuando lo marque el calendario. La historia detrás es interesante: el equipo llevaba meses trabajando en un tema mucho más ambicioso y expresivo, con nombre en clave Mētis, pensado para lucir todo lo que Gutenberg ya permite hacer. Tras revisar la dirección con Matt, el criterio cambió: el tema que se empaqueta con WordPress debe ser el punto de partida más simple posible, dejando que el diseño más elaborado exista aparte. Mētis sigue viva como proyecto independiente, pero no se incluirá en esta versión.

Ipsum, cuyo nombre viene del clásico «lorem ipsum», el texto de relleno que ocupa la página hasta que llega el contenido real, es un lienzo en blanco pensado para blogs, con líneas discontinuas simulando el trazo de un lápiz de editor, un puñado de combinaciones tipográficas y variaciones de estilo que retiñen toda la página, imágenes incluidas. Todas las combinaciones cumplen WCAG AA. Ya está disponible para descargar y probar desde GitHub, con la ventana de feedback muy ajustada antes del lanzamiento de la 7.2.

Las Notas, el sistema de comentarios internos del editor, dan el salto más ambicioso hasta la fecha: llega el modo de sugerencias, donde en lugar de simplemente comentar sobre un bloque se puede proponer directamente un cambio de texto concreto para que otra persona lo acepte o lo rechace, un paso de gigante hacia una colaboración mucho más directa entre quienes editan un mismo contenido. Se suman también reacciones con emoji sobre las propias notas y un atajo dedicado en la barra de herramientas del bloque para añadir una nota sin salir del flujo de escritura.

El apartado de seguridad trae tres piezas de peso. La más llamativa conceptualmente es el llamado «modo sudo»: una función en fase muy inicial que plantea exigir una reautenticación puntual para acciones administrativas especialmente sensibles, aunque ya haya sesión iniciada, algo habitual en sistemas operativos pero nuevo en WordPress; de momento solo se ha anunciado la intención, con propuesta detallada pendiente de publicarse. La segunda es la Secrets API ya comentada en su propuesta inicial: sigue avanzando camino de la 7.2, con soporte desde el primer día para WP-CLI y la interfaz de administración pospuesta a una versión posterior. La tercera es una ronda de mejoras y endurecimiento para Application Passwords, con mejor detección de entornos locales frente a HTTPS, notificaciones por correo cuando se añade una nueva contraseña de aplicación, y una gestión más segura del rol por defecto que se les asigna. A esto se suma trabajo continuado de refuerzo sobre la API de procesamiento de HTML, para que WordPress interprete el marcado de forma más segura y fiable en todo el núcleo.

El mensaje del equipo sobre la IA es muy claro y, siendo justos, un poco frenazo: el ciclo de la 7.1 dejó constancia de que las funciones de IA necesitan demostrar primero adopción real y valor práctico antes de plantearse su entrada en el núcleo, así que todo el trabajo de este apartado se sigue haciendo en el plugin de IA, sin ninguna garantía de aterrizar en la 7.2. Entre lo que se está cocinando: más abilities de WordPress, incluyendo las primeras de escritura y no solo de lectura; una actualización del adaptador MCP a la especificación más reciente, con planes de publicarlo como plugin normal en el directorio; activación de MCP con configuración mínima directamente desde el propio plugin de IA; experimentación con WebMCP en flujos de trabajo de agentes dentro del propio navegador; un modelo de identidad y delegación para que los agentes tengan una identidad auditable y permisos gestionables de forma independiente a las cuentas humanas; contexto de sitio y directrices editoriales reutilizables entre distintas funciones de IA; soporte de embeddings compartido para búsqueda semántica; y streaming de respuestas de IA en el cliente PHP.

El roadmap destaca cuatro frentes concretos de alto esfuerzo sobre accesibilidad: que los avisos del escritorio de administración se anuncien correctamente a tecnología de asistencia y sean más fáciles de descartar por teclado; introducir tests automatizados con axe-core para prevenir regresiones; permitir desactivar por completo el reordenamiento de metaboxes, que llevaba tiempo dando problemas de complejidad visual y cambios accidentales en móvil; y eliminar el modo de accesibilidad de widgets, para reducir el número de modos de gestión distintos que hay que mantener.

Llega un nuevo bloque de Lista de Descripción, formado por tres bloques estáticos que serializan a las etiquetas HTML 

Uno de los cambios de fondo más importantes del ciclo: el Editor del Sitio extensible avanza hacia una base nueva, construida sobre el paquete de enrutado wordpress/boot, ya cerca de tener paridad de funciones con el editor actual. Lo relevante no es solo el rediseño técnico, sino que por primera vez se abre a terceros: un endpoint de configuración de vistas en el servidor permitirá que autores de plugins registren sus propias pantallas y ajustes dentro del propio Editor del Sitio, en lugar de tener que construirse su propia API desde cero cada vez. Otros proyectos en marcha, como la edición de navegación, ya se están apoyando en esta base en lugar de duplicar trabajo.

El sistema de DataViews y DataForms sigue puliendo su extensibilidad, con configuración de vistas y formularios registrada en el servidor y campos y acciones también registrables ahí; como parte de esto, el propio inspector de la publicación, es decir, la imagen destacada, extracto, estado, fecha, autor o plantilla, se está migrando a un DataForm, y ya se pide ayuda para probar esa pieza en concreto. La omnibar, que llegó en la 7.1, sigue iterando con la sustitución de dashicons por iconos SVG, mejoras al command palette y revisión continuada de accesibilidad. Y hay una nueva tanda de mejoras a los mensajes de error: más claros, más diagnosticables, y con un botón de copiar para poder buscarlos o compartirlos fácilmente, siguiendo los principios de diseño defensivo que planteó Matt hace unas semanas. Se retoma también el widget «Un día como hoy», que ya se había intentado meter en la 7.1 sin éxito.

Por fin se podrá estilar de forma consistente elementos de formulario, como botones, campos de texto, desplegables y la etiqueta que faltaba, directamente desde Estilos Globales, sin tocar theme.json a mano. El estilado responsivo que llegó en la 7.1 se amplía a más controles, con una API pública para que bloques de terceros con controles personalizados también puedan aprovecharlo. Se puede definir un estado personalizado «activo» para bloques interactivos, como el elemento de menú actual en una navegación, empezando por el bloque de Enlace de Navegación y el bloque Tabs. Y retorna, esta vez con más peso, el proyecto de mostrar los estilos heredados de Estilos Globales directamente en el inspector del bloque, la función que se aparcó en la 7.1 tras varios intentos fallidos de diseño; ahora se suma la incógnita de si mostrar de forma visible cuándo un valor global ha sido sobrescrito localmente y cómo ofrecer una forma clara de revertir ese cambio.

El procesamiento de medios en el cliente, que debutó en la 7.1, se centra ahora en madurar el sistema: reforzar el proceso de subida, ampliar formatos soportados y cerrar trabajo de rendimiento pendiente. El insertor de medios se rediseña pensando en bibliotecas de medios muy grandes, con más fuentes para la galería dinámica y opciones de ordenación para la galería estática. El modal de edición de medios de la 7.1 se centra en el seguimiento de la relación entre una imagen original y sus recortes, resolviendo un problema real: cada recorte crea hoy un adjunto independiente sin ningún vínculo registrado con el original, lo que puede acabar llenando la biblioteca de medios de duplicados sueltos. En rendimiento, el foco está en eliminar la concatenación de scripts y estilos a favor de precarga, y en imágenes responsivas mejoradas, con el plugin Enhanced Responsive Images del equipo de Performance disponible para quien quiera ayudar a probar. Y las revisiones visuales, que llegaron en la 7.0, siguen puliéndose para que comparar y restaurar cambios resulte más fluido.

Una ausencia deliberada y con razón: la edición colaborativa en tiempo real no está en el roadmap de la 7.2, aunque el trabajo sigue en paralelo al ciclo de la versión. El equipo reconoce que aún faltan decisiones arquitectónicas importantes por resolver, y en lugar de listarla aquí para tener que retirarla después, como pasó en ciclos anteriores, prefieren dejarla fuera del todo por ahora.

Mientras esperamos la llegada de la 7.2, ya está aquí WordPress 7.1.1, la primera versión de mantenimiento de la 7.1. Trae 17 correcciones en core, 19 en el editor de bloques, y once fallos de seguridad, así que es actualización recomendada de forma inmediata: el propio anuncio insiste en ello, como toca en cualquier versión de seguridad.

Entre los fallos corregidos destacan un XSS almacenado en wpautop() explotable por un visitante sin cuenta, con el comentario pendiente de aprobación; un problema en la HTML API que permitía escapar de un comentario HTML mediante secuencias de cierre abrupto; un XSS almacenado en temas con soporte de cabeceras personalizadas; URLs especialmente manipuladas que permitían instalar y previsualizar automáticamente un tema inactivo desde WordPress.org; y una travesía de rutas autenticada en el controlador REST de plantillas, reportada de nuevo por Anthropic.

La lista sigue con más fallos de peso: un administrador de sitio podía activar en red un plugin pensado solo para red que estuviera instalado sin estarlo; XML-RPC permitía publicar cambios de personalización saltándose la comprobación de permiso para editar CSS; una sobrescritura arbitraria de posts por parte de un Contributor, también reportada por Anthropic; una comprobación de permisos ausente que filtraba el título de un post padre privado a través de los metadatos del adjunto; una divulgación del slug de un post en borrador o pendiente por parte de un Contributor sin la autorización adecuada; y un fallo que permitía a cualquier usuario autenticado reasignar el padre de un comentario, notas incluidas. Como viene siendo costumbre, los parches se están retroportando a todas las ramas con soporte, desde la 4.7 hasta la 7.0.

Ya está disponible Gutenberg 24.0. La novedad más práctica es que las revisiones visuales por fin incluyen el título del artículo, que hasta ahora quedaba fuera: ver los cambios de título junto a los del cuerpo del texto evita tener que adivinar cuándo se renombró algo. La Galería estrena una variación de cuadrícula totalmente personalizable que sustituye al layout flexible no editable de siempre, y tanto el número de columnas como el recorte de imágenes se pueden configurar de forma distinta según el dispositivo, así que una galería puede mostrar cuatro columnas en escritorio y dos en tableta sin tocar una línea de CSS.

El Título del Sitio gana la opción «fit-text», que hace que el texto escale para ocupar todo el ancho disponible en lugar de quedarse fijo en un tamaño de punto y tener que saltar de línea o quedarse corto. Entre el resto de novedades destaca un rediseño de casi cien iconos hacia un lenguaje visual unificado basado en trazos, la posibilidad de indentar y desindentar con Tab un elemento de lista completo o varios seleccionados a la vez, imágenes de fondo que ya aceptan directamente una URL sin tener que pasar por la Biblioteca de medios, y que los espacios de no separación se vuelvan visibles mientras se edita, en lugar de quedar invisibles y cambiar el salto de línea sin que nadie se entere.

El equipo de Core que trabaja en la edición colaborativa en tiempo real ha explicado por qué la función sigue fuera del roadmap. El diseño actual mezcla los cambios solo en el navegador, sin que el servidor intervenga hasta que alguien guarda, y eso deja tres huecos serios: no sabe quién escribió cada cambio dentro de una sesión, lo que permitiría colar HTML no autorizado bajo los permisos de otra persona; no puede participar cuando la actualización llega por la API REST o WP-CLI; y no puede mediar si dos personas se dessincronizan, con riesgo real de perder trabajo.

La solución propuesta es que la colaboración pase a ser «consciente del servidor»: en lugar de intercambiar cambios directamente entre sí, cada persona se los envía a WordPress, que comprueba permisos, fusiona los cambios de todos y resuelve los conflictos, en vez de dejarlo todo en manos del navegador. El coste es más carga en el servidor, así que habrá que cuidar el rendimiento, sobre todo en hostings más modestos.

Hay tres motores de sincronización en fase de prueba, disponibles como plugin para quien quiera probar y dar feedback: uno basado en la biblioteca Yjs, otro con fusión a tres bandas que sincroniza solo al guardar, y un tercero que registra descripciones breves de cada cambio en lugar del contenido completo.

Ya está disponible en Learn WordPress el curso «AI-Powered WordPress», pensado para explicar de forma progresiva todo lo que ha ido llegando con el plugin canónico de IA desde la 7.0. Se estructura en cuatro módulos: los tres primeros van dirigidos a cualquiera que gestione o publique en un sitio WordPress, como propietarios, redactores, editores o administradores, sin necesidad de saber programar, y cubren desde conectar el primer proveedor de IA desde la pantalla de Connectors, hasta usar las herramientas editoriales para redactar, resumir y clasificar contenido, generar texto alternativo accesible de forma automática, moderar comentarios con análisis de sentimiento y toxicidad, y controlar qué está haciendo la IA en el sitio con el registro de peticiones y las aprobaciones de conectores.

El cuarto módulo da un salto hacia el desarrollo, sin asumir experiencia previa en PHP aunque ayuda haber tocado antes archivos de tema o plugin: cubre cómo conectar asistentes como Claude o ChatGPT a un sitio mediante el adaptador MCP, cómo registrar una Ability de WordPress para que las herramientas de IA descubran las funciones de un plugin propio, y cómo usar el WordPress AI Client para lanzar prompts desde plugins y temas propios. El curso completo se estima en unas nueve horas, requiere un sitio con WordPress 7.0 o superior y acceso de administrador, y cierra con un bloque sobre buenas prácticas responsables a la hora de publicar y construir con IA dentro de WordPress.

Anécdota curiosa: bbPress ya va por la 2.6.17, saltándose la 2.6.16, porque el propio John James Jacoby encontró un fallo de SQL justo después de etiquetar esa versión y prefirió sacar el arreglo sin esperar. Es otra actualización de seguridad y mantenimiento. Refuerza la visibilidad heredada de foros privados y ocultos, los límites de los foros de grupo de BuddyPress, las comprobaciones de acceso para suscriptores, la edición de perfil, las peticiones a la API REST y XML-RPC, los resultados de búsqueda, las redirecciones canónicas, las etiquetas de tema, mover respuestas, dividir temas, y el escapado de salida en general.

La otra pieza importante es una revisión a fondo de las herramientas de mantenimiento y reparación de contadores, como temas, respuestas, foros, subforos, participación, voces y contribuciones de usuario, que ahora se comportan mejor durante moderación, movimientos, fusiones, divisiones, borrado, restauración, reasignación y peticiones simultáneas. Además, los temas de bloques reciben ya soporte de primera clase mientras bbPress sigue usando sus propias plantillas PHP.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

ha sido una semana sin noticias, pero con una notica que ha dado mucho que hablar por lo ocurrido en tan sólo 33 horas.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

hoy vamos a hablar de Mateo Carlos… en concreto, de Matthew Charles Mullenweg, al que, si me permitís, a partir de ahora llamaremos Matt.

Matt nació el 11 de enero de 1984 en Houston, Texas, hijo de un programador que trabajaba para una gran ingeniería y que puso ordenadores en casa desde muy pronto. La informática, en su caso, fue ambiente familiar antes que vocación.

Pero antes que el código llegó la música. Estudió saxofón jazz en la High School for the Performing and Visual Arts, y esa manera de entender el trabajo, con el improvisar, tocar en grupo, sacar cosas a menudo aunque no estén perfectas, se le quedó pegada para siempre. Y por eso no es casualidad que cada versión de WordPress lleve el nombre de un músico de jazz. La otra afición que le viene de esa época es la fotografía, que sigue practicando y que, curiosamente, ha acabado apareciendo en esta historia.

Aunque ya hemos hecho un poco de historia de WordPress, y nos queda un poco más, la historia empieza en 2003. Matt tenía 19 años, estudiaba Ciencias Políticas en la Universidad de Houston y usaba un pequeño sistema de blogs llamado b2/cafelog, que se había quedado huérfano cuando su desarrollador, el francés Michel Valdrighi, dejó de mantenerlo.

En enero escribió en su blog que alguien debería coger ese código y seguir adelante. Le respondió un desarrollador británico, Mike Little, y entre los dos hicieron el fork. El 27 de mayo de 2003 salió WordPress 0.7, nombre sugerido por su amiga Christine Selleck.

Y aquí hay un detalle que parece menor y no lo es: b2/cafelog estaba bajo licencia GPL, así que WordPress heredó la GPL desde el minuto uno. Esa herencia es la que explica toda la cultura de plugins y temas libres del ecosistema, y también es la que marca la frontera de lo que se puede y no se puede controlar. Porque el código es libre; la marca, no. Ahí está el germen del conflicto de los últimos dos años.

Ese mismo año, un cambio de licencias en Movable Type, que era el sistema de blogs más importante de la época, pero de pago, empujó a media blogosfera a buscar alternativa, y WordPress estaba ahí en el momento justo y el lugar exacto.

En 2004 dejó la universidad para irse a San Francisco a trabajar en CNET, con el acuerdo de poder dedicar parte de su tiempo a WordPress. Duró poco: en 2005 se marchó y fundó Automattic, cuyo nombre esconde su propio nombre dentro.

Automattic nació con una idea rara para la época: una empresa totalmente distribuida, sin oficinas, con gente trabajando desde cualquier parte del mundo. De hecho, llegó a cerrar su oficina de San Francisco porque casi nadie iba. Sus primeros productos fueron WordPress.com, el alojamiento gestionado, y Akismet, el antispam que todavía hoy tiene medio Internet instalado. Y en 2006 se celebró la primera WordCamp, también en San Francisco, el embrión de la red de eventos que hoy sostiene la comunidad en todo el mundo.

La jugada estratégica clave llegó en 2010, cuando se creó la WordPress Foundation y Automattic le cedió la marca registrada. Sobre el papel, la marca queda en manos de una fundación sin ánimo de lucro. En la práctica, el dominio wordpress.org sigue siendo propiedad personal de Mullenweg, y esa distinción, que durante quince años pareció un tecnicismo, es exactamente el nudo de todo lo que ha pasado desde 2024.

Luego está Audrey Capital, que mucha gente confunde con una empresa del grupo y no lo es. Es su vehículo personal de inversión ángel e investigación, fundado a finales de la década de 2000 y bautizado, según se cuenta, con el nombre de su gata.

Desde entonces ha participado en más de cien operaciones en startups de software libre, internet de consumo, inteligencia artificial y salud. Audrey también ha pagado el sueldo de contribuidores que trabajan en el proyecto WordPress, lo cual añade otra capa a un organigrama que ya de por sí no está nada claro.

En la parte de negocio, Automattic es una empresa privada, distribuida, sin oficinas centrales de verdad, valorada en 7.500 millones de dólares en su última ronda de 2021 y con casi mil millones levantados en total.

El dinero viene sobre todo de suscripciones: alojamiento en WordPress.com, Jetpack, WooCommerce y WordPress VIP para grandes clientes. A eso se suma una colección de compras muy variada: Akismet, Gravatar, WooCommerce en 2015, Tumblr en 2019, Day One, Pocket Casts, Texts.com y Beeper. La plantilla llegó a superar las dos mil personas y se redujo con fuerza tras el recorte del 16% de abril de 2025.

Y hay un dato que conviene retener para entender el final de esta historia: pese a todo ese capital levantado, Mullenweg nunca perdió la mayoría. Automattic es una empresa privada donde el fundador mantiene el control efectivo. No es un CEO contratado, es el dueño.

Y ahí está la tensión que lo explica casi todo: Matt es a la vez CEO de una empresa privada con inversores que esperan retorno, líder vitalicio del proyecto de software libre que sostiene el negocio, director de la fundación que guarda la marca y propietario personal de la infraestructura donde vive la comunidad.

Su iniciativa Five for the Future, de 2014, pedía a las empresas del ecosistema dedicar el 5% de sus recursos al proyecto. Diez años después, esa idea razonable se convirtió en la vara de medir con la que exigió a WP Engine un 8% de sus ingresos brutos, y de ahí salió el litigio que sigue vivo.

Y llegamos a hoy, o mejor dicho la última semana, donde comienza «el culebrón de las 33 horas»

El pasado miércoles 9 de septiembre, el consejo de administración de Automattic votó poner a Mullenweg en excedencia remunerada en contra de su voluntad.

Lo contó él mismo en el canal de anuncios de Slack, acusando al director financiero Mark Davies de haber conspirado con los consejeros Ann Dunwoody, Toni Schneider y Sue Decker.

Según su mensaje, recibió la resolución cincuenta minutos antes de la reunión y le negaron tiempo para que un abogado externo la revisara. La empresa confirmó por escrito la excedencia y el nombramiento de Davies como CEO interino, con la fórmula habitual de plena confianza en su liderazgo.

Nadie explicó los motivos. Y a día de hoy, siguen sin explicarse.

Desde WordPress.org, Mary Hubbard, que es la directora ejecutiva del proyecto y a la vez trabajadora de Automattic, salió rápido a tranquilizar a la comunidad: el cambio en la empresa comercial no afecta al proyecto de código abierto, Mullenweg sigue siendo su líder y los equipos continúan con lo previsto.

Que hiciera falta decirlo en voz alta ya dice bastante sobre lo entrelazadas que están las dos cosas.

Y entonces, giro de guion. Porque Mullenweg no se fue.

Lo interesante del caso es que no recuperó el puesto mediante una votación formal del consejo. Simplemente se negó a marcharse y se quedó con las llaves de casa. Echó del Slack corporativo al resto de administradores, la cuenta de Mark Davies apareció desactivada y empezó a publicar mensajes diciendo que todo estaba resuelto.

Abrió uno de ellos con un «Don’t call it a comeback», enlazó el vídeo de «Mama Said Knock You Out» de LL Cool J y se cambió el avatar por uno con sombrero y parche de pirata. También escribió que ahora era un pirata, con alguna palabrota incluida, algo llamativo en alguien conocido por no decir tacos jamás. Y añadió: si esto es un problema de recursos humanos, que alguien me controle, porque mis controladores habituales están con Mark Davies.

En X apuntó además que esta era probablemente la quinta vez que se enfrentaba a un golpe interno. Y cuando le preguntaron si todo aquello era trolleo, respondió que no era un troll, sino un pirata, obviamente. Prometió también un artículo explicando su vuelta; el artículo llegó, pero iba sobre el barco-casa que se había comprado.

El sábado 12, Automattic confirma el regreso

El sábado por la noche llegó por fin el comunicado oficial. Un portavoz declaró a TechCrunch que Mullenweg es presidente y consejero delegado de Automattic, con el apoyo total del consejo, y añadió que basta con mirar internet para ver a directivos y trabajadores respaldándolo, en referencia aparente a los mensajes de apoyo que él mismo llevaba días republicando en X.

El dato exacto lo dio después la propia empresa: estuvo apartado 33 horas y 20 minutos. Poco más de un día.

El 14 de septiembre, la junta entera, estaba de patitas en la calle.

Y aquí es donde el desenlace se vuelve realmente inusual. Los tres consejeros que votaron apartarlo ya no están.

Toni Schneider, primer CEO de Automattic y hoy al frente de Bluesky, renunció a su asiento, y llegó a borrar de su web personal el párrafo donde mencionaba su papel en la compañía. Sue Decker también dimitió: su perfil de LinkedIn indica ahora que estuvo en el consejo desde marzo de 2020 hasta septiembre de 2026. Y a la generala Ann Dunwoody la retiró directamente Mullenweg.

Preguntada por los cambios, Automattic declinó dar detalles, aunque reconoció que ha habido salidas. Todavía no se sabe quién compone el nuevo consejo.

El 16 de septiembre llega el día de los los paracaídas dorados

Porque entonces TechCrunch publicó los documentos que explican qué pasó durante esas 33 horas. Es la parte más surrealista de todo el asunto.

Mark Davies, el director financiero convertido en CEO interino, y Andy Missan, el director jurídico, firmaron cada uno el acuerdo de indemnización del otro, con fecha efectiva del 10 de septiembre. Es decir: se firmaron mutuamente el paracaídas mientras el fundador estaba apartado.

Cada acuerdo incluía doce meses de salario base en un pago único, vesting acelerado de sus acciones, la posibilidad de ejercer las opciones ya consolidadas y un año más de cobertura médica. Entre los dos, el paquete suma 8,15 millones de dólares que Automattic debería ahora, porque Mullenweg los despidió nada más volver.

El departamento legal está decidiendo si paga o impugna la validez de esos acuerdos. Hay otro detalle que ha alimentado las sospechas: según un documento de recursos humanos, Davies no tenía ya acciones de Automattic cuando salió, porque las habría vendido meses atrás, aunque sí conservaba un buen paquete de opciones ejercitables. Jordan Hinkes, el asesor jurídico general, también tiene la cuenta desactivada, aunque Mullenweg ha dicho en X que su salida estaba planeada desde hacía semanas porque se va a una startup de inteligencia artificial.

El 15 de septiembre llegó la artillería pesada legal

Y es que en paralelo, Automattic ha cambiado de bufete. Deja a Gibson Dunn y ficha a Stephen Shackelford y Shawn J. Rabin, de Susman Godfrey.

Y el fichaje es un mensaje en sí mismo. Shackelford fue co-director de la demanda de Dominion Voting Systems contra Fox News, la que acabó con un acuerdo de 787 millones y medio de dólares. Rabin es especialista en antimonopolio y litigios comerciales complejos, con un arbitraje reciente de 987 millones contra Walgreens a sus espaldas.

El anuncio lo hicieron en X con una frase que no deja lugar a dudas sobre el tono: dicen estar deseando trabajar juntos para luchar por la libertad y el open source. Contra quién exactamente, no lo especifican. Puede ser WP Engine, pueden ser sus propios exconsejeros, o puede ser la ofensiva contra las otras diez empresas de hosting que WP Engine reveló en su demanda de febrero.

Y aquí es donde quedan las dos lecturas posibles

TechCrunch plantea dos interpretaciones, y ninguna está confirmada.

La primera: el consejo actuó para proteger a la empresa. En julio, WP Engine acusó a Mullenweg de destruir pruebas, en concreto mensajes en Signal, WhatsApp y Telegram. Si los consejeros consideraban que aquello se había convertido en un riesgo corporativo serio, apartarlo y cambiar la dirección podía servir para demostrar al tribunal que se tomaban el asunto en serio, y de paso reducir sanciones o mejorar las condiciones de un acuerdo. Que Davies y Missan se blindaran a toda prisa encaja con quien sabe que, si la jugada sale mal, se va a la calle. Y salió mal.

La segunda es la que sospecha el propio Mullenweg: que el consejo buscaba crear una ventana de control temporal para alguna operación estratégica. Él mismo admite que nunca le dieron un motivo, así que está especulando igual que el resto; la falta de explicación y la venta de acciones del director financiero alimentaron sus sospechas y pesaron en su decisión de retomar el mando y barrer al consejo.

También está el factor propiedad, y el factor valoración

Porque nada de esto se entiende sin volver al principio: Mullenweg levantó mucho capital, pero mantuvo la mayoría. Un consejo puede votar lo que quiera; si el fundador controla las acciones, el pulso lo gana él. Y lo ha ganado.

Ahora bien, hay un contrapunto incómodo a dia de hoy. BlackRock, que entró en la ronda de 2021, lleva desde 2024 rebajando el valor que asigna a su participación. Y, según recogía Scripting News a partir de la última presentación del fondo ante la SEC, la marca habría caído hasta los 14,33 dólares por acción, frente a los 85 que pagó en su día, lo que implicaría una valoración de la compañía en torno a los 1.200 millones en lugar de los 7.500. Automattic no ha confirmado esas cifras, y conviene tomarlas como lo que son: la valoración contable de un inversor, no un precio de mercado. Pero la tendencia lleva dos años apuntando en la misma dirección.

Así que, como resumen

En cuestión de una semana, el consejo intentó apartar al fundador, el fundador se negó a irse, tomó el control de las comunicaciones internas, la empresa acabó confirmando su regreso, los tres consejeros que votaron en contra han desaparecido, dos directivos han sido despedidos con ocho millones largos en indemnizaciones en el aire, y de paso se ha contratado a uno de los bufetes más temidos de Estados Unidos.

Es un desenlace muy poco habitual en gobernanza corporativa: el fundador con control mayoritario le ha ganado el pulso a su propia junta directiva, y ha salido de la crisis con más poder del que tenía antes de empezar.

Lo que sigue sin saberse es lo esencial: por qué votaron apartarlo, quién forma el nuevo consejo, si esos 8,15 millones se pagan o se pelean en los tribunales, y si todo esto tiene conexión real con el caso WP Engine, porque oficialmente nadie la ha establecido.

Aunque, hay que dejar una cosa muy clara, y es importante: para quien tiene su web o su negocio montado sobre WordPress, el mensaje práctico es que el proyecto sigue funcionando igual y que las actualizaciones van a seguir llegando. El problema de fondo es otro: la gobernanza de la plataforma que mueve más del 40% de la web ha quedado retratada como algo que se decide, y se deshace, en un Slack privado, en poco más de treinta horas.

Aunque WebMCP todavía es un proyecto para ser un estándar de Internet, ya se ha integrado en WordPress Playground para ser usado con ChatGPT de escritorio, que le da soporte.

Recuerda que puedes escuchar este programa desde:

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 7 al 13 de septiembre de 2026.

Ya está formado el Release Squad de WordPress 7.2, con Matt Mullenweg de vuelta como Release Lead, tras la convocatoria de voluntarios. David Baumwald coordina la versión, George Mamadashvili y Peter Wilson son los Tech Leads, y el equipo se completa con los responsables de triage y testing, más los leads de diseño y desarrollo del nuevo tema por defecto, Twenty Twenty-Seven, encabezados por Henrique Iamarino en diseño y Maggie Cabrera y Carolina Nymark en desarrollo.

Como viene siendo norma desde la 6.7, la 7.2 mantiene el modelo de squad reducido, apoyándose mucho en los representantes de cada equipo Make para coordinar el trabajo desde dentro de sus propios equipos en lugar de centralizarlo todo en el squad de la versión. El número de voluntarios superó con creces las plazas disponibles, así que quien no haya sido seleccionado esta vez puede seguir aportando en testing, bug scrubs, triage o documentación durante todo el ciclo, que es donde de verdad se nota el volumen de trabajo de cada versión.

WordPress Playground incorpora soporte de WebMCP, un estándar todavía en fase de borrador que permite a una página web exponer directamente acciones como herramientas que un agente de IA puede descubrir y usar sin salir del navegador. Es una vía distinta a MCP, que conecta con un servidor local o remoto: WebMCP funciona dentro de la propia página web abierta, sin intermediario. OpenAI ya ha añadido soporte para esto en el navegador integrado de la aplicación de escritorio de ChatGPT, bajo el nombre «Site tools», así que ahora también se puede trabajar con Playground pidiéndole en lenguaje natural que construya una página de inicio o prepare una demostración reproducible de un plugin.

El reto técnico interesante es que WordPress corre dentro de un iframe anidado en la página de Playground, y un agente que solo mira la página principal no ve las herramientas que un plugin registre dentro de ese WordPress. La solución es un proxy de WebMCP que expone hacia fuera las herramientas registradas dentro del sitio y reenvía las llamadas hacia dentro, de forma que un plugin que ofrezca, por ejemplo, la acción de crear un borrador de evento, se vuelve descubrible y usable por el agente sin montar ningún servidor aparte.

El equipo ya ha probado varios flujos de trabajo reales: construir una página de inicio completa de turismo a partir de una sola instrucción, montar un panel de seguimiento de compatibilidad entre versiones de WordPress con tarjetas editables, o convertir las funciones de un plugin en demostraciones interactivas que cualquier visitante puede probar sin instalar nada.

El equipo de Plugins ha activado una revisión de seguridad automatizada para cada nueva versión de cualquier plugin del directorio, antes de que llegue a distribuirse por la API de actualizaciones. Hasta ahora los plugins nuevos se revisaban antes de entrar al directorio, pero las actualizaciones posteriores no pasaban ningún filtro sistemático, y un plugin seguro hoy podía introducir una vulnerabilidad o código malicioso en cualquier versión futura sin que nadie se enterase a tiempo. El detonante concreto fue un incidente real: el 28 de julio se coló un backdoor en una actualización de un plugin con unas 20.000 instalaciones activas, que la revisión automática detectó y puntuó como alto riesgo, bloqueando su distribución antes de que llegara a ningún sitio, con el plugin cerrado del todo 26 minutos después.

El mecanismo se apoya en el periodo de cuarentena de seis horas que ya existe desde junio para toda actualización de plugins y temas: durante esa ventana, varios modelos de IA analizan los cambios de cada versión, cruzan resultados entre sí para reducir falsos positivos, y asignan una puntuación de riesgo. Si supera el umbral de alto riesgo, la distribución se bloquea automáticamente sin depender de que haya alguien del equipo disponible en ese momento, y se avisa por correo a todos los autores del plugin con los hallazgos concretos; una puntuación alta no implica intención maliciosa, ya que una vulnerabilidad introducida sin querer puede puntuar igual de alto que un ataque deliberado.

El equipo de Comunidad ha propuesto crear un fondo de patrocinio educativo conjunto para estudiantes de WPCredits y de WordPress Campus Connect, pensado como paquete estándar en la convocatoria de patrocinadores de los tres WordCamps insignia: Asia, Europa y US. Hasta ahora esto se ha resuelto caso por caso: en WordCamp US 2025 asistieron dos estudiantes de Campus Connect, y en WordCamp Europe 2026 cinco estudiantes de WPCredits, con valoraciones de 8 a 10 sobre 10 en el informe de impacto posterior. La propuesta busca convertir ese esfuerzo puntual en un proceso repetible, con un formulario de recomendación que rellenan organizadores o mentores, y criterios de selección centrados en trayectoria de contribución sostenida y calidad del perfil en WordPress.

El plan es lanzarlo primero como piloto en WordCamp Asia 2027, con una cohorte de ocho estudiantes, un objetivo de financiación de 30.000 dólares y una aportación mínima de patrocinador de 3.000, antes de extenderlo a Europa y Estados Unidos si funciona bien. Quedan muchas dudas sobre cómo estructurar el patrocinio en franjas de precio por plaza, dónde alojar de forma centralizada el enlace de interés para patrocinadores durante todo el año en lugar de repetir el proceso por cada evento, qué pasa si se recauda solo para la mitad de las plazas previstas, y la logística de confirmar los fondos con tiempo suficiente para que los estudiantes puedan tramitar vuelos y visados.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Josep ha estado este mes de agosto en WordCamp US en el equipo de organización de Comunidad y nos trae su experiencia.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Por segundo año llega el WP Agency Forum, el evento de agencias WordPress en España, que se reúne en Madrid. Asiste presencialmente con un 20% de descuento en la entrada. Usa el cupon WPPODCAST.

Recuerda que puedes escuchar este programa desde:

Te dejamos este especial sobre el WP Agency Forum 2026 que se celebrará en Madrid el próximo 7 de octubre.

Asiste presencialmente con un 20% de descuento en la entrada. Usa el cupon WPPODCAST.

Los iconos que han mostrado WordPress desde la versión 3.8 parece que desaparecerán en WordPress 7.2, donde se sustituirán por imágenes vectoriales.

Recuerda que puedes escuchar este programa desde:

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 31 de agosto al 6 de septiembre de 2026.

Ya hay calendario para la primera versión de mantenimiento de la versión actual: WordPress 7.1.1 llegará el 17 de septiembre. El propio equipo reconoce que el volumen y la gravedad de los reportes recibidos en foros, Trac y el repositorio de Gutenberg desde el lanzamiento de la 7.1 justifican preparar esta versión de mantenimiento con más antelación de lo habitual.

Como es norma en este tipo de versiones, la 7.1.1 se centra exclusivamente en corregir fallos: solo entran tickets que sean regresiones introducidas durante el propio ciclo de la 7.1 o funciones que se aplazaron deliberadamente al final de ese ciclo, nada de funciones nuevas.

También está disponible Gutenberg 23.9, centrada sobre todo en pequeñas comodidades de edición del día a día. Ya no hace falta ir a buscar el botón de insertar bloque cuando este está escondido: ahora se puede añadir directamente desde la barra de herramientas del propio bloque, así que meter una imagen más en una galería o un bloque nuevo dentro de un grupo ya no obliga a cambiar de selección ni a hacer scroll para encontrarlo. Los Estilos Globales, por su parte, ganan un pequeño punto indicador en cada bloque que tenga una anulación de estilo personalizada, con la opción de filtrar y ver de golpe solo los bloques que se han tocado a mano, en lugar de tener que revisarlos uno por uno.

Entre el resto de novedades destaca el espaciado independiente entre elementos en horizontal y vertical para el bloque Grupo con diseño flexible o de cuadrícula, la posibilidad de personalizar el estilo de las etiquetas de formulario desde el theme.json, y soporte de Estilos Globales para citas, campos de entrada y desplegables. También se puede añadir una paleta de colores dúotono propia desde el propio panel de Estilos Globales, en lugar de depender solo de las que ofrezca el tema. El resto son mejoras internas de accesibilidad y rendimiento, entre ellas una selección de bloques notablemente más rápida en artículos largos.

Hay un parche en marcha que sustituye los Dashicons de la barra de administración y el menú lateral por los nuevos iconos SVG de WordPress, apoyándose en la nueva función que llegó con la 7.1. El motivo no es solo estético: los iconos de fuente tipográfica, como los Dashicons, tienen varios problemas de fondo. Los lectores de pantalla los anuncian de forma imprevisible, ya que ocupan puntos de código Unicode sin significado definido y a veces se leen como un carácter sin sentido en mitad de una frase; se rompen con el modo de alto contraste de Windows y otros ajustes de color forzado, porque el sistema los trata como texto; y cuando el archivo de la fuente falla o carga lento, el resultado son cuadros o símbolos extraños que parecen un sitio roto, mientras que un SVG simplemente no se muestra si falla.

El cambio es muy visible de cara al usuario, así que el equipo pide expresamente más opiniones de las que ha tenido hasta ahora en el ticket. Quedan un par de detalles abiertos: el icono de búsqueda queda mirando hacia el lado contrario al Dashicon que sustituye, y el icono de Entradas podría dejar de ser una chincheta a favor de una pluma, aunque ya hay debate sobre cuál encaja mejor.

Los Dashicons aparecieron por primera vez en WordPress 3.8 Parker, lanzado el 12 de diciembre de 2013. Llegaron junto con el rediseño del administrador, el proyecto MP6, sustituyendo los antiguos sprites de iconos por una fuente de iconos vectorial, más nítida en cualquier resolución. La versión inicial incluía 167 iconos; en WordPress 3.9 se añadieron 30 nuevos, llegando a 197.

Un grupo de contribuidores mantuvo en WordCamp US una charla informal, bajo la regla de Chatham House, sobre la relación de WordPress con el lenguaje PHP y su comunidad. El diagnóstico de fondo es conocido: buena parte de la comunidad PHP no considera a quien desarrolla para WordPress un «desarrollador PHP» de verdad, en parte porque se percibe que el compromiso de compatibilidad hacia atrás de WordPress frena la evolución del propio lenguaje, y WordPress apenas participa en las discusiones donde se deciden las nuevas funciones de PHP. Esa misma ventana larga de compatibilidad genera fricción real en el ecosistema de plugins, cuyas dependencias externas ya no siempre soportan versiones de PHP tan antiguas como las que WordPress sigue admitiendo.

El dato que más pesa es la adopción: PHP 7.4 sigue corriendo en aproximadamente un 18% de los sitios web, con poco incentivo reciente para actualizar más allá de la seguridad, ya que esas versiones antiguas ya no reciben parches. Se habló de empujar desde el lado del hosting con una actualización coordinada, de hacer PHP 8.x notablemente más rápido para que la velocidad sea el argumento de peso, y de la preocupación de fondo con PHP 9: si trae un cambio de sintaxis mayor, podría hacerse imposible mantener una sola versión de WordPress compatible con PHP 7.4 y con PHP 9 a la vez.

El resto de la charla giró en torno a cómo estrechar lazos con el proyecto PHP: retomar la conversación sobre WebAssembly, que ya se descartó una vez por falta de interés pero que ahora tiene más sentido dado el uso que WordPress ya hace de WASM en Playground; llevar a PHP el trabajo ya hecho en la API de HTML de WordPress, en lugar de mantenerlo solo puertas adentro; y la idea, todavía a nivel de lista de deseos, de que plugins con dependencias inseguras puedan cargarse con permisos restringidos, marcando como no confiable cualquier código que dependa de ellos. Como seguimiento concreto, se plantea revisar si la distribución de versiones antiguas de WordPress en sí ha cambiado, y explorar el envío de avisos automáticos a desarrolladores de plugins cuando su código no sea compatible con una versión de PHP determinada.

El Code Reference estrena ejemplos de código ejecutables de verdad, apoyados en WordPress Playground: WordPress 7.1 ya trae los dos primeros, con más previstos para la 7.2. En una de las páginas de referencia hay un botón «Run» que ejecuta el fragmento de código directamente en el navegador, sin salir de la documentación ni montar nada en local.

Estos fragmentos interactivos se definen directamente en el DocBlock de cada método, dentro del propio código de WordPress, con una sintaxis ligeramente distinta a la de un ejemplo de código normal. El equipo promete publicar en breve una página del manual con todos los detalles para quien quiera documentar sus propias funciones con este mismo formato.

Toca actualizar foros con bbPress porque la versión 2.6.15 corrige cinco fallos de seguridad y varias mejoras de compatibilidad. Los parches refuerzan los permisos a la hora de editar temas y respuestas, dividir o fusionar temas, actualizar el perfil de usuario, y ver foros privados u ocultos; también se blinda la verificación de contraseñas importadas de otros sistemas y se corrigen avisos de PHP en algunas peticiones al foro. Uno de los fallos tiene CVE propio.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

WordPress trabaja en un sistema de cifrado de las claves que se almacenan en el sistema, tanto para las API de conectores como las que usan otros plugins y herramientas.

Recuerda que puedes escuchar este programa desde:

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 24 al 30 de agosto de 2026.

La comunidad ha recibido una propuesta de gran calado para WordPress 7.2: una Secrets API, la primera forma nativa de guardar una credencial en WordPress. Hoy, cualquier plugin que necesite guardar una clave de API la escribe en texto plano en la tabla de opciones, lo que significa que acaba en cada copia de seguridad, cada clon de staging y cada terminal compartida; con la llegada de servicios de IA con claves de pago por uso, perder una credencial así ha dejado de ser un problema menor. La propuesta plantea funciones sencillas con cifrado obligatorio y sin opción de desactivarlo, sin ningún filtro que pueda interceptar un secreto en texto plano al recuperarlo, y con soporte desde el primer día para WP-CLI, precisamente para evitar que las credenciales queden expuestas en el historial de la terminal.

El plan de trabajo es algo inusual: antes de tocar el core, se publicará como plugin independiente para que la comunidad lo pruebe con sitios reales, y solo después llegará el parche al núcleo con una API idéntica a la del plugin, con la interfaz de administración pospuesta deliberadamente hasta la 7.3 para no precipitar un diseño importante.

La propuesta ha generado ya un debate técnico serio en los comentarios, sobre todo por parte de gente de hosting gestionado que explica que sus almacenes de secretos externos son de solo lectura desde WordPress y que el cifrado tiene que resolverse en su HSM externo, no dentro de WordPress, algo que la propuesta actual no contempla bien porque asume que el proveedor de almacenamiento nunca recibe el secreto en texto plano. Se sigue pidiendo feedback activamente, y todo apunta a que el diseño final se moverá bastante respecto a esta primera versión antes de llegar a un parche real.

El equipo de IA confirma un dato que conecta directamente con esto: la Secrets API para la 7.2 ya viene probada de antes, ya que es básicamente la misma que lleva meses funcionando como experimento de cifrado de claves dentro del propio plugin de IA. El equipo se ha alineado formalmente a favor de llevarla al núcleo en la 7.2, aunque piden que la documentación incluya una forma sencilla de detectar si la función está disponible, para poder migrar código antiguo con secretos en texto plano de forma limpia.

El equipo de Seguridad ha anunciado la Core Security Initiative, un esfuerzo coordinado que explica de paso algo que ya veníamos viendo estas últimas semanas: la avalancha de parches de seguridad de la serie 7.0. Según el propio equipo, el volumen de informes de seguridad ha crecido muchísimo en el último año, en buena parte porque los modelos de IA más avanzados hacen que analizar código en busca de vulnerabilidades sea cada vez más accesible, algo que está pasando en todo el ecosistema del software, no solo en WordPress. Lo cual es, dicen, un buen problema: más ojos puestos en el código hace a WordPress más seguro, pero obliga a escalar cómo se clasifican, validan y resuelven esos informes.

La iniciativa se apoya en tres frentes. El primero es un proceso de lanzamiento más sólido y automatizado, con mejores tests de extremo a extremo, para que los parches de seguridad salgan de forma fiable y predecible. El segundo es reducir el backlog de informes abiertos, sumando más gente al equipo y a voluntarios, con el objetivo declarado de llegar a cero incidencias pendientes. El tercero es usar la propia IA para buscar vulnerabilidades de forma proactiva antes de que alguien las explote, como complemento a los informes que llegan por la vía de divulgación responsable.

WordPress Playground se ha convertido en algo bastante más ambicioso que un simple sandbox: ahora permite arrancar en el navegador cualquier versión histórica de WordPress, desde la 0.7 hasta la 6.2, mucho antes de que existiera el editor de bloques o la API REST. La novedad se activa con una casilla nueva de «Include older versions» en el panel de ajustes, y por debajo hace un trabajo bastante fino: para WordPress 0.7 a 4.9 usa un compilado de PHP 5.2.17 en WebAssembly, mientras que de la 5.0 a la 6.2 fija PHP 7.4, porque esas versiones intermedias se comportan de forma más fiable ahí que en un PHP moderno. El selector incluso muestra los nombres en clave de cada versión, así que probar la WordPress 2.8 «Baker» es tan sencillo como elegirla en un desplegable.

La utilidad práctica es clara para quien desarrolla plugins o temas: reproducir un informe de compatibilidad de un cliente que sigue en WordPress 4.9, comprobar de verdad qué se rompe antes de decidir retirar soporte a una versión antigua, o comparar cómo se comportaba el editor clásico frente al de bloques sin tener que mantener una máquina virtual con PHP antiguo y base de datos aparte.

Un grupo de contribuidores está construyendo la alternativa a Meetup.com para los grupos de la comunidad de WordPress, basada en el plugin GatherPress, y ya piden ayuda para probarla en Events.WordPress.org. La idea es que cada grupo tenga su propio sitio donde la gente pueda unirse y confirmar asistencia a eventos, con los organizadores gestionando todo desde la parte pública, sin pasar por el escritorio de administración. Para probarlo basta con entrar en el grupo de pruebas interno con la cuenta de WordPress, momento en el que automáticamente se pasa a ser «Member»; hay otros dos roles con más permisos, «Event Organizer» y «Organizer», accesibles también desde la propia página de miembros para quien quiera probar esas vistas.

El equipo pide expresamente una primera impresión general antes que un informe de fallos exhaustivo: unirse a un grupo, confirmar asistencia a un evento, ver patrocinadores y miembros, y sobre todo comparar la experiencia con la de Meetup para detectar qué echaría en falta alguien acostumbrado a esa plataforma. Los primeros comentarios ya han sacado varias carencias interesantes: el editor de descripción del evento es bastante más limitado que el editor de bloques habitual, no se muestra la zona horaria del evento, algo importante para eventos en línea con gente en varios países, y al menos un caso donde abandonar un grupo no retira correctamente la confirmación de asistencia a un evento ya guardado. También hay peticiones de tener un sitio de pruebas en español, ya que el equipo de traducción de Meta y WordCamp ya está trabajando en las cadenas de texto nuevas.

WordPress ha firmado la carta abierta «Open Weights and American AI Leadership», que pide a los responsables políticos de Estados Unidos no imponer restricciones tempranas a los modelos de IA de peso abierto, que son los que cualquiera puede descargar, inspeccionar, modificar y ejecutar en su propia infraestructura. La carta se publicó el 24 de julio y ya suman más de 270 empresas y organizaciones firmantes; el argumento de fondo es el mismo que cualquiera familiarizado con el código abierto reconocerá enseguida: la tecnología mejora y es más segura cuanta más gente puede estudiarla y construir sobre ella.

Mary Hubbard, directora ejecutiva de WordPress, enmarca la firma precisamente en esa filosofía de veinte años del propio proyecto: la gente que usa una tecnología debería poder moldearla a su gusto, y los modelos de peso abierto extienden esa misma libertad al terreno de la IA. Entre las peticiones concretas de la carta a los legisladores están ampliar el acceso a capacidad de cómputo para startups e investigadores, invertir en recursos compartidos como conjuntos de datos públicos y herramientas de evaluación, mantener más de un tipo de modelo disponible en lugar de reducir el campo a un puñado de sistemas cerrados, y no tratar como robo por defecto prácticas habituales como usar la salida de un modelo para mejorar otro.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Ya tenemos un prototipo del próximo plugin de laboratorio Accessibility Lab, al estilo de lo que hacen el de IA y el de Performance.

Recuerda que puedes escuchar este programa desde:

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 17 al 23 de agosto de 2026.

WordPress 7.1 se lanzó finalmente el 19 de agosto, con nombre en clave Mary Lou, tras pasar por cuatro release candidates, ya que la RC4 llegó con más de 26 correcciones adicionales sobre la RC3 y una congelación de código extendida más allá de las 24 horas habituales, a petición expresa de los committers, para dar tiempo a verificar bien el paquete final antes de publicarlo. El equipo de Core ya busca voluntarios para las versiones de mantenimiento 7.1.x, con la 7.1.1 prevista a principios de septiembre según la gravedad de los bugs que vayan apareciendo.

Para quien administre servidores: WordPress 7.1 mantiene el mínimo de PHP 7.4 y es totalmente compatible desde PHP 7.4 hasta PHP 8.5. PHP 8.3 ya está en soporte solo de seguridad y PHP 8.2 llega a fin de vida el 31 de diciembre de este año, así que si hay sitios en esas versiones, conviene planificar la migración.

El estreno no estuvo exento de drama. Anne McCarthy, release lead de la versión, ha publicado un extenso diario de decisiones del ciclo donde detalla, entre otras muchas cosas, qué pasó realmente el día del lanzamiento en el escenario de WordCamp US: un commit disparó las actualizaciones automáticas antes de tiempo, con unos 300.000 sitios ya actualizados y un fallo de compatibilidad con WP Rocket reportado en directo, mientras Matt Mullenweg seguía en el escenario sin confirmar si quería «pulsar el botón» del lanzamiento en persona. Ante la falta de comunicación con Mullenweg y con las actualizaciones automáticas ya en marcha, McCarthy tomó la decisión de publicar el anuncio directamente sin esperar al acto en el escenario, asumiendo la responsabilidad de la decisión públicamente.

Gutenberg 23.8, publicada el mismo día del lanzamiento de WordPress 7.1, incluye las revisiones visuales, que dan otro paso: ahora se puede enlazar directamente a una revisión concreta, ya que la URL se actualiza sola según se navega por el historial, por lo que compartir un cambio exacto con un compañero es tan sencillo como copiar el enlace, y se añade una vista de diferencias en código dentro del propio editor. Las Notas, por su parte, completan el círculo de las menciones: cuando alguien menciona a otro usuario con una arroba, ahora recibe un correo en su propio idioma con enlace directo a la conversación.

La otra gran novedad es de rendimiento puro: la vista de lista recibe una tanda de mejoras que, sumadas, la hacen dramáticamente más rápida en posts largos; en una entrada de 1.000 párrafos, seleccionar todos los bloques pasa de 16,8 a 0,4 segundos. El lienzo vacío del editor también deja de mostrar un simulacro de bloque y renderiza ya un bloque real por defecto, así que lo que se ve antes de escribir es exactamente lo que se obtiene. El bloque Playlist, todavía experimental, mejora su flujo de conversión desde Audio y permite seleccionar varios archivos de golpe desde la Biblioteca de medios, y el bloque Tabs gana navegación por teclado con las teclas Inicio y Fin.

El equipo de IA ha lanzado el plugin AI 1.3.0, con dos experimentos nuevos en el editor: traducción de contenido, que traduce bloques de párrafo, encabezado y opcionalmente el título sin salir del editor, dejando siempre el resultado para revisar antes de publicar; y generación de slugs, que sugiere permalinks concisos a partir del título y el contenido, disponible tanto en los controles de permalink como en el flujo previo a publicar.

También hay un refuerzo de seguridad notable: verificación de nonce antes de generar texto alternativo o resúmenes en bloque, validación de que las URLs de imágenes externas son públicas y de tipo permitido, y límites configurables de tamaño y tiempo de espera para las descargas de imágenes personalizadas.

Además, se apunta hacia dónde va todo esto: de cara a WordPress 7.2, el equipo quiere llevar al núcleo un patrón de Abilities estilo CRUD en lugar de exponer directamente la API REST, para que cada ability pueda anotarse con precisión sobre si es de solo lectura o realiza una acción destructiva.

En el Blog de Desarrolladores se ha publicado un tutorial práctico y muy completo sobre la nueva API pública de iconos de la 7.1. Se construye paso a paso un plugin de ejemplo con iconos de restaurante, y aunque el detalle es muy de desarrollador, resume bien el flujo básico: registrar una colección, registrar cada icono pasándole una etiqueta y el contenido SVG o la ruta a un archivo, y usar el resultado directamente en el bloque Icon. Como curiosidad de estilo de código, recomienda apoyarse en enumeraciones de PHP con valores, disponibles desde PHP 8.1, en lugar de arrays sueltos, para evitar errores tontos de tipeo y ganar autocompletado en el editor.

Dicho y hecho. Ya está aquí el primer prototipo del plugin Accessibility Lab, que se empezó a comentar hace tan solo unos días. Sigue el modelo ya conocido del plugin Performance Lab y del plugin de IA: reunir en un solo sitio experimentos rumbo al núcleo de WordPress y herramientas prácticas ya probadas por la comunidad, con la diferencia de que aquí todo se queda agrupado en un único plugin en lugar de repartirse en varios pequeños. El equipo insiste mucho en lo que NO es: no sustituye arreglar la accesibilidad directamente en core, y los fallos evidentes, como atributos ARIA mal puestos, etiquetas que faltan o problemas de teclado, se siguen corrigiendo donde están, sin pasar primero por este plugin.

El prototipo trae ya tres módulos funcionando. El primero amplía las opciones de vista de la Biblioteca de medios más allá del simple interruptor de scroll infinito que llegó con la 7.1, añadiendo control sobre cuántos elementos se muestran, la densidad y si se ve siempre el nombre de archivo, pensado explícitamente para recoger feedback real de cara a cómo debería resolverse esto en core. El segundo incorpora el trabajo ya existente de Troy Chaplin con su plugin Block Accessibility Checks: validación en tiempo real de bloques, campos meta y estructura del documento contra las WCAG, con un sistema de tres niveles de aviso y enganchable también por bloques de terceros. El tercero es una validación de jerarquía de encabezados que avisa en el momento si un bloque de Encabezado salta un nivel, por ejemplo un H2 seguido directamente de un H4, algo que llevaba años pedido en Gutenberg sin resolverse.

De cara al futuro, la idea que más ilusión genera es hacer buscable el texto alternativo de las imágenes, que hoy vive en post meta y por eso no se puede indexar ni buscar a escala, un ticket de Trac abierto desde hace años.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.