
Sign up to save your podcasts
Or


Con la Presence API aparece una columna de editores activos en el listado de posts, un indicador en la barra de administración con los avatares de quién está en esa misma pantalla, y un par de widgets en el dashboard.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
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 27 de abril al 3 de mayo de 2026.
El equipo de Core ha publicado un plugin experimental llamado Presence API, pensado como punto de partida para su posible integración en el núcleo de WordPress. La idea es sencilla: añadir una capa de presencia al escritorio de administración para saber quién está conectado, en qué pantalla está cada usuario y qué entradas está editando en ese momento.
Hoy en día, si dos personas están editando el mismo post a la vez, WordPress no avisa hasta que ya hay una colisión de bloqueo, y para entonces puede que el trabajo se haya solapado. Con Presence API aparece una columna de editores activos en el listado de posts, un indicador en la barra de administración con los avatares de quién está en esa misma pantalla, y un par de widgets en el dashboard. Todo ello restringido a usuarios con capacidad de editar entradas.
En cuanto a la parte técnica, el plugin utiliza una tabla propia para datos efímeros con un tiempo de vida de 60 segundos, lo que evita el problema de rendimiento que se identificó durante el desarrollo de WordPress 7.0, donde guardar datos de alta frecuencia en tablas compartidas provoca una invalidación masiva de caché. Los datos se mueven a través del Heartbeat API.
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.
1956… setenta años atrás. La inteligencia artificial no nació en 2022 con ChatGPT. Tiene mucha más historia.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
El lanzamiento de WordPress 7.0 ya vuelve a tener fecha, con 4 semanas de margen sobre la fecha en que se había prometido dar información. Si todo sigue su nuevo curso, el 20 de mayo tendremos esta nueva versión mayor.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
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 20 al 26 de abril de 2026.
WordPress 7.0 ya tiene fecha de lanzamiento: 20 de mayo de 2026, seis semanas después del 9 de abril que estaba previsto originalmente.
El nuevo calendario publicado esta semana recoge lo que ya se intuía: el ciclo se reinicia en la práctica, aunque no en el nombre. La RC3, prevista para el 8 de mayo, se comporta como una nueva Beta 1, y la RC4 funcionará como la verdadera Release Candidate 1.
El 24 de abril, previo a todo este proceso, se lanzó una llamada a proveedores de hosting para probar compatibilidad, con una herramienta específica que pone a prueba las conexiones de múltiples usuarios de forma sostenida en las pantallas colaborativas del editor.
Lo interesante es que el equipo ha mantenido la numeración RC en lugar de volver a betas, algo que ya explicamos: si WordPress publicara una «Beta 7» después de una RC2, la función version_compare de PHP no la reconocería como más reciente, y las actualizaciones automáticas se romperían. Así que RC3 y RC4 son, en la práctica, una nueva beta y una nueva release candidate disfrazadas. Lo que no sabemos es si estas seis semanas extra serán suficientes para cerrar la tabla personalizada de la colaboración en tiempo real, el motivo real del retraso, o si el 20 de mayo volverá a moverse. De momento, hay calendario.
El nuevo Gutenberg 23.0 llega con tres líneas principales de trabajo.
La primera: el panel de revisiones para plantillas, partes de plantilla y patrones, que hasta ahora solo estaba disponible para entradas y páginas. Es experimental y forma parte del proyecto DataForm, así que hay que activarlo desde la pantalla de experimentos.
La segunda: el panel Identity del Editor del Sitio se completa con los campos de Site Title y Site Tagline, que se suman al Site Logo y Site Icon. Los cuatro ajustes de identidad del sitio están ahora en un solo panel, editable sin ir a la configuración general, y los cambios se reflejan en tiempo real en el canvas porque escriben en la misma entidad que leen los bloques correspondientes.
La tercera: Real-time Collaboration da un paso importante con la compatibilidad con meta boxes obsoletos; los plugins pueden marcar meta boxes individuales como compatibles con RTC mediante un flag, ganando en fiabilidad.
El equipo de Core ha publicado la edición 7.0 de la tabla de herramientas de diseño por bloque, que lista qué soportes de diseño tiene cada bloque del editor. Esta edición acumula los cambios desde la 6.1 y trae novedades destacadas: el bloque Verse pasa a llamarse Poetry, y se añaden nueve bloques: Accordion, Breadcrumbs, Icon, Math, Post Time to Read y Term Query, todos con soporte completo de herramientas de diseño. Además, varios bloques existentes reciben nuevas capacidades: Paragraph ahora soporta alineación, Cover añade layout e imagen de fondo, Navigation soporta alineación, y Details recibe layout, entre otros.
El plugin de IA mantiene un ritmo de desarrollo alto: en dos semanas ha pasado de la 0.7.0 a la 0.8.0, con 234 commits entre ambas.
La 0.7.0 trajo tres experimentos nuevos: Content Classification para sugerir categorías y etiquetas existentes, Meta Description Generation para SEO sin salir del editor, y Alt Text en lote desde la Biblioteca de Medios, además de un Abilities Explorer con filtros y hooks de extensibilidad para desarrolladores.
La 0.8.0 sube la apuesta: Image Generation and Editing se convierte en la primera funcionalidad estable del plugin, siendo lo primero que gradúa del laboratorio; llega Refine from Notes para que la IA revise, anote y corrija automáticamente sobre sus propias notas, y se añaden widgets de dashboard que muestran el estado de IA y las capacidades del conector configurado. También las abilities pasan a respetar las guías de estilo de Gutenberg: si el sitio tiene normas editoriales, la IA las usa al generar contenido.
Lo más destacado de estas versiones no es solo lo que añaden, sino lo que corrigen: la generación de títulos y entradillas ya no incluye preámbulos conversacionales, comillas extra ni artefactos markdown cuando se usan modelos pequeños, un problema habitual de los LLMs pequeños que tienden a devolver texto conversacional en vez de solo el resultado. Y que las abilities respeten las guías no es un detalle menor: la IA trabaja dentro de las reglas editoriales del sitio, no al revés. El plugin está pasando de «experimento con IA» a herramienta con criterio.
En la 0.9.0 ya se preparan Content Resizing, moderación de comentarios, logging de peticiones y procedencia de contenido vía C2PA, lo que significa que el texto y las imágenes generadas por la IA podrían llevar incorporada esta trazabilidad: se sabría que fueron generadas por IA, con qué modelo y en qué fecha, siendo un paso hacia la transparencia en contenido generado automáticamente.
El equipo de Hosting ha publicado un aviso directo: más de 70 hostings participan en el programa de tests distribuidos, pero varios han dejado de enviar resultados. El mensaje es claro: «Hosts: revisad vuestros test runners, que no están bien».
La petición no es solo cosmética: se están actualizando los tests del core para recopilar datos específicos sobre Real Time Collaboration, la funcionalidad estrella de WordPress 7.0 que sigue en desarrollo activo y que probablemente sufra cambios arquitectónicos importantes en las próximas semanas, con más betas y RCs por llegar.
Lo que está en juego es la compatibilidad real de la colaboración en tiempo real en entornos de producción. Cuantos más hosts ejecuten los tests, más datos habrá sobre rendimiento y problemas antes del lanzamiento del 20 de mayo. Los hosts que necesiten ayuda pueden recurrir al canal hosting en Slack o abrir un issue en el repositorio del PHPUnit Test Runner.
El equipo de Comunidad recuperó el Community Booth en WordCamp Asia 2026, ese stand que había desaparecido de los últimos flagships: ni en WordCamp US 2025 ni en la propia WordCamp Asia hasta ahora.
La retrospectiva que han publicado cuenta una historia a medias: por un lado, funcionó, ya que se firmaron mentores, se arrancaron meetups en Tanzania, Indore y Delhi, se conectó gente con Campus Connect y Polyglots… pero por otro, las condiciones no ayudaron nada. El stand era un mostrador con una silla, colocado en una esquina, sin cartel de horarios, sin swag, sin materiales impresos y con huecos sin personal. La gente se acercaba por curiosidad y no sabía qué hacer allí.
En WordCamp Europe 2025 ya habían demostrado que la fórmula funciona con otra disposición: mesa compartida, zona central, swag exclusivo del stand. Así que la lección es clara: el Community Booth vale la pena, pero necesita intención, con un espacio abierto, dos personas mínimo por turno, cartel con temas y horarios, y aunque sean cuatro stickers de Wapuus.
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.
Esta semana no hay muchas noticias aunque hay cosas que decir, y comentamos un nuevo proyecto sobre Arquitectura de la Información.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
Matt Mullenweg ha lanzado una crítica extensa y autocrítica sobre el estado del proyecto WordPress, cuestionando una cultura de proceso que, según él, paraliza la toma de decisiones, eclipsa a los contribuidores individuales frente a las empresas, y ha convertido Five for the Future en un programa con datos inútiles.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
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 13 al 19 de abril de 2026.
En la WordCamp Asia celebrada en Mumbai, una pregunta aparentemente rutinaria en el turno de preguntas y respuestas del cierre desencadenó el debate interno más intenso que ha vivido la comunidad WordPress en mucho tiempo. Un asistente preguntó al panel cuál era la mejor forma en que una empresa podía contribuir al proyecto. Dos de los committers más activos del núcleo, Peter Wilson y Sergey Biryukov, dieron la misma respuesta: patrocinar a contribuidores a tiempo completo. Matt Mullenweg, que seguía el evento a distancia, discrepó públicamente y en tiempo real, transmitiendo su respuesta a través del equipo de comunicación de Automattic. Lo que vino después ha sido una semana de crítica y autocrítica que ha puesto sobre la mesa preguntas que llevan años sin respuesta.
El primer hilo arrancó en Make Core, donde Matt publicó una reflexión sobre la foto de una acreditación del evento que vio circular en redes. En ella aparecía en letras grandes la etiqueta «SELF EMPLOYED». Eso le llevó a cuestionar en qué momento el proyecto había empezado a poner el nombre de la empresa por encima de cualquier dato personal del contribuidor, y si ese cambio de énfasis era sano. Su propuesta concreta: que las acreditaciones muestren el nombre de usuario en WordPress.org, el lugar de origen y el sitio web, no el empleador.
Pero fue en el canal core-committers de Slack donde la crítica se volvió más extensa y más dura. El detonante fue un ticket de Trac relacionado con la pantalla de Conectores de WordPress 7.0, creado por un empleado de Automattic tras una conversación privada con otro compañero, fusionado durante la fase de Release Candidate sin discusión pública. Un contribuidor externo lo había señalado y le había enviado una notificación a Mullenweg. Cuando este lo revisó a su vuelta de la WordCamp, lo describió como un microcosmos de todos los problemas que arrastra el proyecto.
El diagnóstico de Matt fue directo: WordPress no está siendo superado por la competencia, sino que se está haciendo daño a sí mismo. Diecinueve años de crecimiento sostenido frente a críticos que predecían su fracaso, y ahora, según él, el proyecto lleva años deshaciendo todo lo que lo hizo exitoso. Apuntó al exceso de proceso como causa principal: las normas de participación que garantizan discusión pública, consenso amplio y accesibilidad global en los horarios de reuniones, todas ellas razonables por separado, han creado en conjunto una cultura que hace funcionalmente imposible resolver asuntos menores sin semanas de hilo en Slack y docenas de participantes. La acumulación de más de 8.000 tickets abiertos en Trac, que el proyecto había optado por ocultar detrás de una consulta personalizada en lugar de abordar, le pareció un ejemplo perfecto de esa dinámica.
Fue también crítico con el estado de WordPress.org, señalando páginas con cabeceras enormes y contenido escaso, una página About que no refleja el cambio de MySQL a MariaDB, y una navegación inconsistente entre secciones. Y criticó la pantalla de Conectores de IA que él mismo había impulsado para WordPress 7.0: tardó demasiado en llegar y, cuando llegó, mostraba pantallas de error. Comparó el tiempo invertido con el ritmo al que Cloudflare había construido su propio CMS, EmDash, en dos meses.
En paralelo, en el canal five-for-the-future de Slack, Matt ha sido igual de directo con el programa que él mismo lanzó en 2014 para que las empresas dedicaran el cinco por ciento de su capacidad a contribuir al proyecto. El problema no es el concepto sino la ejecución: el programa fue diseñado para incentivar compromisos que nunca se verifican y que no tienen en cuenta si la actividad resultante está alineada con los objetivos del proyecto. Los datos que genera son, en sus propias palabras, «peores que inútiles tal y como hemos estructurado el programa».
Identificó cuatro problemas concretos: que la presencia corporativa ha eclipsado a voluntarios, estudiantes y contribuidores que trabajan en su tiempo libre; que los compromisos se tratan como un fin en sí mismos en lugar de un primer paso; que no existe seguimiento de la actividad real después de hacer un pledge; y que los equipos de Make han perdido de vista su propósito en favor de objetivos intermedios y dinámicas de proceso.
Las respuestas dentro del proyecto fueron variadas. Anne McCarthy, de Automattic, reconoció que el péndulo había oscilado demasiado hacia el reconocimiento corporativo y abrió una propuesta para diseñar una plantilla de acreditación estándar que todas las WordCamp pudieran adoptar. También se sumó a la idea de recuperar la figura de los Lead Developers, cuya desaparición considera que ha dejado vacíos de responsabilidad y toma de decisiones que se manifiestan en cada ciclo de lanzamiento. Amber Hinds señaló que medir horas brutas favorece estructuralmente a las grandes empresas, y propuso medir la proporción de horas disponibles dedicadas al proyecto, donde un individuo que contribuye la mitad de su tiempo está dando proporcionalmente mucho más que una empresa cuyas cientos de horas representan solo el cinco por ciento de su capacidad total.
Courtney Robertson planteó una pregunta que lleva rondando la comunidad desde 2024: quién es el propietario real de la infraestructura del proyecto. WordPress.org pertenece personalmente a Mullenweg, y Robertson pidió que lo dijera claramente y por escrito para que los contribuidores entiendan que trabajar en esa infraestructura es contribuir al proyecto y no enriquecer a una persona privada.
Fuera del Slack, el diagnóstico de Matt encontró bastante acuerdo en la comunidad general, aunque no así la forma en que lo expresó. Varios referentes del ecosistema señalaron que el tono y el estilo de intervención responden a un patrón conocido: largos períodos de ausencia de un tema seguidos de una intervención extensa y cargada que hace difícil la respuesta constructiva. El término «Matt Bomb», acuñado hace más de una década, volvió a circular.
Mullenweg cerró sus intervenciones del martes con una reflexión sobre Joost de Valk, cofundador de Yoast, con quien mantiene un conflicto público desde 2024 y a quien se prohibió el acceso a WordPress.org tras pedir públicamente el fin de su liderazgo como «dictador benevolente de por vida». Escribió que desearía haber apoyado más sus intentos de impulsar cambios en el proyecto cuando tuvo la oportunidad de hacerlo. De Valk, que seguía la conversación en el Slack de la comunidad PostStatus, respondió con un emoji de encogimiento de hombros.
Uno de los problemas más recurrentes en los Contributor Days de las WordCamp es que los asistentes pasan toda la sesión intentando configurar su entorno local y nunca llegan a contribuir.
Para resolver esto, el equipo ha publicado el WordPress Core Dev Environment Toolkit, una aplicación de escritorio disponible para macOS, Windows y Linux que monta un entorno completo de desarrollo de WordPress Core sin ningún prerrequisito. El proceso se reduce a instalar la app, elegir un directorio, hacer clic, y tener listo un repositorio clonado de wordpress-develop con un servidor de desarrollo en marcha y la capacidad de hacer cambios y generar un parche listo para adjuntar en Trac.
La herramienta está pensada especialmente para el contexto de los Contributor Days, donde el objetivo es que alguien pueda pasar de asistente a primer parche en una sola tarde. Los organizadores pueden compartir el enlace de descarga con los participantes antes del evento para que lo instalen en casa con buena conexión, ya que la descarga es algo más pesada.
En línea directa con las críticas que lanzó la semana anterior sobre el exceso de procesos manuales en el proyecto, Matt Mullenweg publicó en Meta una convocatoria abierta: que cualquier contribuidor proponga procesos de WordPress.org que podrían automatizarse.
Las respuestas de la comunidad dibujan bien dónde están los cuellos de botella más evidentes. La revisión de plugins es la más mencionada: con más de 500 envíos semanales y tiempos de espera que superan las dos semanas en la primera revisión, hay quien propone que la IA haga el primer pase y los revisores humanos se centren en casos límite, apelaciones y reportes de seguridad.
Otras propuestas cubren la aprobación de eventos de la comunidad, donde el proceso también puede alargarse semanas; una primera respuesta automática en los foros de soporte; el triage de tickets de Trac, que incluiría detectar duplicados, pedir información faltante y archivar tickets inactivos; la generación automática de resúmenes semanales de los equipos a partir de los registros de Slack y GitHub; y la revisión automatizada completa de temas para el directorio, sin intervención humana.
La respuesta de Mullenweg fue escueta pero clara: «preparaos, vamos a tener muchos Wapuus corriendo por todas partes».
El equipo de Comunidad ha anunciado los patrocinadores globales del programa de eventos para el periodo que va del segundo trimestre de 2026 al segundo trimestre de 2027. Son tres organizaciones: Automattic, con sus marcas Jetpack y WordPress.com, y Hostinger como Global Leaders, y Woo como Regional Powerhouse.
Su apoyo cubre los costes operativos que hacen posibles las WordCamp y las Meetup a lo largo del año: alquiler de espacios, catering, equipos audiovisuales, las licencias para más de 685 grupos activos en todo el mundo y los seguros de los eventos. Los organizadores de eventos de 2026 deben incluir los logos de estos socios en sus sitios web y pueden contactar con cada empresa para confirmar qué marca concreta les representará en su evento.
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.
Cada vez más el riesgo de que tu sitio se infecte por malware crecen, en un lado debido a las IA, por otro, por la dejadez de los responsables del sitio.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
El equipo de Formación de WordPress ha propuesto una serie de herramientas y prompts para estandarizar la creación de material formativo sobre WordPress.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
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 6 al 12 de abril de 2026.
Gutenberg 22.9 ha llegado con dos novedades principales.
La primera es el soporte de gradientes de fondo en el bloque Group, que ahora pueden combinarse con imágenes de fondo sin conflictos. Aparece un selector de gradiente en el panel de Fondo que funciona de forma independiente a los controles de color existentes, lo que permite crear efectos de superposición sobre imágenes o combinar varios fondos a la vez. Este nuevo soporte background gradient también está disponible para desarrolladores de bloques y sienta las bases para una eventual unificación del sistema de fondos en todos los bloques.
La segunda es una mejora experimental en la paleta de comandos, que ahora organiza las acciones en secciones: comandos recientes y sugerencias basadas en el contexto actual, en lugar de mostrar solo un campo de búsqueda vacío. Para probarlo hay que activar el experimento «Workflow Palette» en los ajustes de Gutenberg.
Entre las novedades adicionales destaca la llegada de un componente EmptyState al paquete wordpress ui, que estandariza cómo se muestran los estados vacíos en la interfaz. La colaboración en tiempo real recibe varias correcciones de estabilidad: las notas de revisión ya se sincronizan correctamente entre editores sin necesidad de recargar la página, el botón de la lista de posts vuelve a mostrar «Editar» cuando expira el bloqueo de colaboración, y se han corregido errores que en sesiones largas podían acumular problemas en memoria. El bloque Forms experimental incorpora ahora campos de tipo hidden, visibles en el editor como bloques seleccionables pero invisibles en el frontend.
El plugin AI ha lanzado su versión 0.7.0, con novedades centradas en flujos de trabajo editoriales y accesibilidad de medios.
Las dos novedades más destacadas son dos nuevos experimentos. El primero es la Clasificación de Contenido, que sugiere categorías y etiquetas basándose en el título, el resumen y el contenido del post, limitando las sugerencias a los términos ya existentes en el sitio para mantener la coherencia del árbol de categorías. El segundo es la Generación de Meta Descripciones, que permite crear descripciones para SEO directamente desde el editor sin salir de la pantalla de edición.
En el apartado de accesibilidad, se puede ahora generar texto alternativo para varias imágenes a la vez desde la Biblioteca de Medios, con una acción de procesamiento en lote. Además, el algoritmo de generación de texto alternativo se ha ajustado para seguir mejor las directrices del árbol de decisión del W3C.
El Explorador de Habilidades, la interfaz que muestra todas las capacidades de IA disponibles, también ha recibido mejoras de organización con soporte para filtrar por categoría, lo que es útil cuando el número de habilidades registradas empieza a ser grande.
El equipo de Formación ha publicado un conjunto de herramientas de IA para facilitar la creación de materiales de aprendizaje estandarizados. Son prompts diseñados para cualquier plataforma de IA, más un plugin específico para Claude, y cubren tres tareas concretas: redactar o revisar lecciones para Learn WordPress, crear guías de facilitación para talleres de dos o tres días, y generar diapositivas para acompañar esos talleres.
La clave del enfoque es la estandarización. Las herramientas no generan contenido genérico sino que siguen la estructura y el estilo ya establecidos, tomando como referencia los materiales existentes. El objetivo es que cualquier colaborador, aunque sea nuevo, pueda producir materiales coherentes con lo que ya existe en la plataforma.
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.
Los certificados TLS que se renovaban anualmente, desde hace unos días lo hacen cada 6 meses, y llegarán a los 47 días máximo.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
Hace una semana parecía que todo el lanzamiento de WordPress 7.0 iba por un buen camino, pero parece que tras el lanzamiento de las versiones candidatas se han replanteado algunas situaciones.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
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 30 de marzo al 5 de abril de 2026.
WordPress 7.0 no saldrá el 9 de abril como estaba previsto. El 31 de marzo se publicó un anuncio que pocas veces se ha visto en el historial del proyecto: el lanzamiento se retrasa después de haber entrado ya en fase de Release Candidate. Es una decisión inusual, y merece explicarse con detalle.
La raíz del problema es la base de datos de la colaboración en tiempo real.
La colaboración en tiempo real es una de las funciones más ambiciosas de WordPress 7.0. Para que varios usuarios puedan editar el mismo post simultáneamente, el sistema necesita almacenar dos tipos de información: los cambios en el contenido del documento, y los datos de presencia, es decir, quién está editando y dónde tiene el cursor cada persona.
Desde el principio del ciclo se debatió si era necesaria una tabla específica en la base de datos para gestionar esta información. La propuesta existía, pero se pausó antes de que llegara la fase RC por falta de tiempo y porque el diseño no estaba suficientemente maduro. En su lugar se optó por una solución provisional: guardar los cambios en postmeta y la información de presencia en transients, con un manejo especial para evitar invalidaciones de caché excesivas.
Esa solución funcionaba técnicamente, pero Matt Mullenweg expresó su preferencia por tomarse el tiempo necesario para diseñar bien la tabla personalizada desde el principio, en lugar de lanzar con una solución de compromiso que luego sería difícil de cambiar. Su argumento es que la arquitectura de datos de una función tan central como la colaboración en tiempo real tiene que aguantar el paso del tiempo, y que merece más reflexión de la que hubo.
Además, en las últimas semanas surgió una consideración adicional: más allá de la colaboración entre usuarios humanos, el sistema de sincronización podría necesitar dar soporte a casos de uso más amplios, como la sincronización entre un agente de IA y el editor, o entre distintos contextos de edición. Eso amplía el alcance del problema y refuerza la necesidad de diseñar bien las primitivas desde el principio.
El equipo de lanzamiento publicó una nueva entrada explicando las implicaciones concretas de la pausa, con algunos puntos a destacar.
La rama de desarrollo para la versión 7.1 de WordPress queda cerrada a nuevos commits hasta nuevo aviso, para evitar conflictos durante el trabajo en la rama 7.0. Cualquier cambio que se aplique a la rama 7.0 requiere la aprobación de dos committers distintos, con un proceso más riguroso que el habitual. Las únicas excepciones permitidas son correcciones de errores introducidos en el ciclo actual, mejoras en las herramientas de construcción y tests, y cambios específicos relacionados con la estabilidad de la colaboración en tiempo real y la pantalla de Conectores de IA.
Las nuevas versiones de prerelease quedan en pausa hasta el 17 de abril. El nuevo calendario completo se publicará a más tardar el 22 de abril. En términos de versiones, el equipo ha decidido que las próximas versiones se llamarán RC3, RC4, etcétera, aunque técnicamente el proyecto esté en una fase más parecida a una beta. Cambiar a betas crearía problemas con la función version_compare de PHP, que no reconocería la beta 7 como más reciente que la release candidate 2, lo que podría romper las actualizaciones automáticas.
Durante la pausa, el equipo recomienda usar las versiones nocturnas generadas desde la rama 7.0 para seguir probando.
Además, también se anunció un tema que afectará a muchos desarrolladores de plugins durante el período de transición. Los plugins que usan meta boxes clásicos, aquellos que envían datos al guardar el post mediante el hook save_post, no son compatibles con la colaboración en tiempo real. Cuando WordPress detecta meta boxes en un post, desactiva la colaboración para ese post completo.
La razón es que los meta boxes funcionan fuera del sistema de datos de Gutenberg, por lo que no pueden participar en la sincronización de cambios entre colaboradores. El período de 7.0 es una ventana de tiempo para que los desarrolladores de esos plugins migren a APIs más modernas del editor de bloques.
Así que el retraso de WordPress 7.0 es una decisión deliberada y fundamentada para no comprometer la arquitectura de una función que tiene el potencial de cambiar de forma sustancial cómo se trabaja en WordPress a nivel profesional. Pero no sabremos nada hasta el 22 de abril.
El equipo de Core ha lanzado documentación para los que quieran ir más allá de la configuración por defecto de la colaboración en tiempo real en WordPress 7.0.
Por defecto, la sincronización entre colaboradores funciona mediante sondeo HTTP: el editor consulta al servidor cada cierto tiempo para ver si hay cambios. Es una solución que funciona en cualquier instalación de WordPress sin requerir infraestructura adicional, pero tiene sus limitaciones en latencia y carga del servidor cuando hay muchos colaboradores activos.
WordPress 7.0 permite sustituir ese mecanismo por uno propio mediante el filtro sync.providers en el lado del cliente. Esto abre la puerta a usar WebSockets u otros transportes de tiempo real que ofrezcan actualizaciones instantáneas y solo consuman recursos cuando hay cambios reales.
El equipo de Formación ha lanzado el Programa de Formación de Facilitadores, una iniciativa gratuita y abierta para preparar a personas que quieran enseñar WordPress a otros. No hay proceso de solicitud ni credenciales previas requeridas. Está pensado para educadores universitarios, organizadores de comunidades, freelancers, desarrolladores o cualquier persona que conozca WordPress y quiera compartir ese conocimiento de forma estructurada.
El programa tiene tres componentes: cursos autoguiados en Learn WordPress, guías de facilitación con agendas detalladas para talleres de dos o tres días, y un manual general que orienta a los facilitadores sobre cómo aprovechar el programa. El primer curso ya está disponible y cubre los programas educativos de WordPress: WordPress Credits, Campus Connect y los Student Clubs, con 9 módulos y 41 lecciones.
La idea detrás del programa es crear una red distribuida de facilitadores que puedan llevar la formación en WordPress a sus comunidades de forma independiente, sin depender de un equipo central. A medida que el ecosistema de credenciales de WordPress crezca, los facilitadores que completen los cursos relevantes podrán acreditar esa experiencia de forma reconocida profesionalmente.
El equipo de Comunidad ha publicado una propuesta para explorar la organización de un nuevo Community Summit en 2027 o 2028, aprovechando una de las WordCamp principales. El último que se celebró fue en 2023 en Estados Unidos, y la idea es que el próximo tenga lugar en Asia o Europa para dar más representación a esas regiones.
El Community Summit es un espacio de trabajo más íntimo y enfocado, donde contribuidores de diferentes equipos se reúnen para debatir en profundidad los temas que afectan al proyecto, tomar decisiones y alinear esfuerzos. Las ediciones anteriores de 2012, 2014, 2017 y 2023 demuestran que este tipo de encuentro tiene un impacto real en la dirección del proyecto.
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.
¿Cuántas veces te has enfrentado a una máquina en un contacto de soporte? Quizá debas apagar y volver a encender…
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
From the publisher's feed

24 Listeners

402 Listeners

65 Listeners

8 Listeners

16 Listeners

57 Listeners