[Magazine] Arquitectura de la Información

Beschreibung

[Noticias] WordPress 7.0 en 3 semanas

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 [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], 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 [https://make.wordpress.org/core/2026/04/22/wordpress-7-0-release-party-updated-schedule/]: 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 [https://make.wordpress.org/core/2026/04/22/whats-new-in-gutenberg-23-0-22-april/]. 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 [https://make.wordpress.org/core/2026/04/22/roster-of-design-tools-per-block-wordpress-7-0/], 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 [https://make.wordpress.org/ai/2026/04/10/whats-new-in-ai-0-7-0-2/]: 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 [https://make.wordpress.org/ai/2026/04/24/whats-new-in-ai-0-8-0/]: 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 [https://make.wordpress.org/hosting/2026/04/22/attention-hosts-that-help-test/]: 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 [https://make.wordpress.org/community/2026/04/24/wordcamp-asia-2026-community-booth-a-retrospective/], 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 [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

28. Apr. 20260

[Noticias] Matt Mullenweg cuestiona el rumbo de WordPress

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 [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], 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 [https://make.wordpress.org/core/2026/04/11/elevating-individuals/] 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 [https://make.wordpress.org/core/2026/04/16/wordpress-core-dev-environment-toolkit-a-faster-path-to-your-first-core-contribution/], 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 [https://make.wordpress.org/meta/2026/04/14/requests-for-automation/]. 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 [https://make.wordpress.org/community/2026/04/15/%f0%9f%8e%89-announcing-our-2026-global-partners/] 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 [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

21. Apr. 202611 min

[Magazine] Arquitectura de la Información

Beschreibung

Kommentare

Kostenlos hören bei Podimo

Alle Folgen