WordPress 7.1 Beta 3: como probarla sin romper tu sitio

Actualizado el 26/07/2026: WordPress 7.1 Beta 3 ya está disponible, pero el equipo de desarrollo confirmó que el soporte Unicode para correos electrónicos —una de las funciones más esperadas del ciclo— queda postergado. Al mismo tiempo, se conoció que la versión 7.0.2 corrigió una vulnerabilidad crítica pre-auth RCE descubierta con ayuda de inteligencia artificial.

En pocas palabras: WordPress 7.1 Beta 3 se publicó el 22 de julio de 2026 y ya está disponible para testear gratis. Se prueba con el plugin WordPress Beta Tester, con el comando wp core update --version=7.1-beta3 o en WordPress Playground. No la instales en sitios en producción. La versión final está agendada para el 19 de agosto de 2026.

WordPress 7.1 Beta 3 salió el 22 de julio de 2026 y ya se puede descargar para testear. Es una versión de desarrollo: el propio proyecto pide de forma explícita no instalarla en sitios en producción. Se prueba de tres maneras: con el plugin Beta Tester, con WP-CLI o en el navegador con Playground.

WordPress 7.1 Beta 3 es la tercera versión beta del ciclo de desarrollo de WordPress 7.1, publicada por WordPress.org el 22 de julio de 2026. Sirve para que desarrolladores, agencias y autores de plugins prueben el software antes del lanzamiento final del 19 de agosto de 2026 y reporten errores. No es una versión estable, no tiene soporte y no está pensada para sitios con tráfico real. La descarga es gratuita.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto, desarrollado inicialmente por Matt Mullenweg y actualmente mantenido por la comunidad y la empresa Automattic, utilizado para crear y administrar sitios web.

WordPress es un sistema de gestión de contenidos de código abierto creado por Matt Mullenweg en 2003, desarrollado por Automattic y la comunidad global de WordPress, utilizado para crear y administrar sitios web, blogs y plataformas en línea.

¿Qué vulnerabilidad crítica corrigió WordPress 7.0.2?

WordPress 7.0.2 corrigió una vulnerabilidad de ejecución remota de código pre-autenticación (pre-auth RCE), una de las fallas más graves detectadas en el CMS en los últimos años. El bug, conocida como wp2shell, permitía a un atacante ejecutar comandos en el servidor sin necesidad de estar autenticado, tomando control total del sitio vulnerable.

Lo llamativo del caso no es solo la gravedad —que ya es mucha—, sino cómo se descubrió. La vulnerabilidad fue identificada con asistencia de OpenAI Sol Ultra GPT-5.6, un modelo de lenguaje aplicado a tareas de análisis de seguridad sobre el codebase de WordPress. El hallazgo desencadenó un operativo coordinado entre el equipo de seguridad de WordPress, proveedores de hosting y redes de distribución de contenido (CDNs) para desplegar parches y reglas de firewall antes de que la falla se explotara masivamente. Complementá con actualizar sin problemas tu instalación.

El esfuerzo coordinado es lo que evitó un desastre mayor. Cuando una vulnerabilidad pre-auth RCE afecta a un CMS que corre en más del 40% de la web, la ventana entre la divulgación y la explotación masiva se mide en horas. Los hosts y CDNs aplicaron reglas de mitigación a nivel de red mientras el parche oficial llegaba a los sitios mediante actualizaciones automáticas. Si tu sitio tiene actualizaciones automáticas activadas, ya recibió la corrección en 7.0.2. Si no, la pregunta no es si deberías actualizar, sino por qué todavía no lo hiciste.

La participación de un modelo de IA en la detección también abre un debate interesante. Que una herramienta como GPT-5.6 haya encontrado un vector de ataque que pasó desapercibido en revisiones humanas previas dice algo sobre hacia dónde va la auditoría de seguridad en proyectos open source. No reemplaza a los investigadores humanos, pero acelera la parte más tediosa: revisar miles de líneas de código buscando patrones que un ojo entrenado reconoce, pero que una máquina encuentra en segundos.

¿Qué es el soporte Unicode en WordPress y por qué se retrasó en 7.1?

El soporte Unicode para correos electrónicos es la capacidad de WordPress de enviar y procesar direcciones de correo que contengan caracteres no ASCII: acentos, eñes, diéresis, caracteres cirílicos, chinos, árabes o emojis. Hoy, si un usuario se registra con una dirección como maría@año.com, WordPress puede rechazarla o procesarla de forma inconsistente según la configuración del servidor. La función prometía normalizar ese comportamiento.

El impacto es concreto para sitios fuera del mundo angloparlante. En Argentina, en España, en México, en Brasil, en Alemania —cualquier país donde los nombres de dominio y las direcciones de correo usen caracteres con acentos o especiales— el soporte Unicode en notificaciones, registros y recuperación de contraseñas es una necesidad real, no un capricho cosmético.

Según The Repository, el equipo de desarrollo confirmó que la función se retrasó por problemas técnicos de integración. No se trata de que la funcionalidad no funcione en absoluto, sino de que los casos límite —interacción con plugins de formularios, conflictos con servidores SMTP que no soportan UTF-8 en el encabezado del mensaje, y la retrocompatibilidad con instalaciones antiguas de WordPress— resultaron más complejos de lo previsto en la etapa de planificación.

El retraso es frustrante, pero también es señal de un equipo que prefiere postergar antes que largar una feature a medio cocinar. El historial reciente de WordPress tiene varios ejemplos de funciones que entraron verdes y después requirieron tres versiones para estabilizarse. Postergar Unicode para un ciclo futuro, con más tiempo de prueba, es una decisión conservadora y probablemente acertada.

Lo que no está claro es si la función entra en WordPress 7.2 o si queda sin fecha. El comunicado oficial no da un timeline nuevo, así que los usuarios que dependen de direcciones con caracteres especiales tendrán que seguir usando soluciones alternativas —plugins de terceros o configuraciones manuales de SMTP— por un tiempo indefinido. En probar estos cambios en un entorno staging profundizamos sobre esto.

¿Qué dijo Matt Mullenweg sobre los cambios recientes?

Según The Repository, Matt Mullenweg, cofundador de WordPress, fue quien pidió retirar el soporte Unicode para correos electrónicos de la versión 7.1 por preocupaciones de seguridad.

¿Cómo descargar y probar WordPress 7.1 Beta 3?

Hay tres caminos oficiales, todos gratuitos, y el anuncio de WordPress.org del 22 de julio de 2026 los lista en ese orden. El más rápido no requiere instalar nada: Playground corre WordPress dentro del navegador. El más cómodo si ya tenés un entorno de pruebas armado es el plugin. El más directo, si vivís en la terminal, es WP-CLI.

• Plugin WordPress Beta Tester: instalás y activás el plugin oficial en una instalación de prueba, elegís el canal «Bleeding edge» y el stream «Beta/RC Only», y actualizás desde el panel como siempre. Ideal si querés probar con tu tema y tus plugins puestos.
• WP-CLI: un solo comando, wp core update --version=7.1-beta3. Es el método de agencias y de cualquiera que tenga staging scriptado.
• WordPress Playground: el anuncio linkea una instancia de 7.1 Beta 3 lista para usar. Cero setup, cero riesgo, cero contacto con tu sitio (y también cero de tus datos adentro, ojo con eso).

El momento de testear importa. La guía de testing del equipo de Test apunta a que los reportes útiles son los que llegan antes del Release Candidate. Después del RC, el foco se corre a bugs bloqueantes y lo demás se pospone al ciclo siguiente. Si vas a dedicarle una tarde a esto, que sea esta semana.

Método	Para quién	Setup	Riesgo para tu sitio
Playground	Curioso, autor de contenido, alguien que quiere ver el editor nuevo	Ninguno, es un click	Nulo
Plugin Beta Tester	Dueño de sitio con staging o instalación local	Instalar plugin, elegir canal	Alto si lo hacés en producción
WP-CLI	Desarrollador, agencia, hosting	Acceso SSH y WP-CLI instalado	Alto si apuntás al sitio equivocado

¿Qué características nuevas tiene WordPress 7.1?

WordPress 7.1 trae estilos responsivos configurables desde el Site Editor, mejoras en la carga de medios —incluida la subida de imágenes HEIC en Safari— y un sistema de notas colaborativas dentro del editor. La hoja de ruta publicada por el equipo de Core ordena todo esto para el lanzamiento del 19 de agosto. El soporte Unicode, como ya vimos, quedó fuera de esta lista.

Vale la aclaración de siempre en un ciclo beta: entre la hoja de ruta y el Field Guide final hay margen. Algunas cosas se posponen sobre la hora, otras quedan detrás de un flag experimental. Tomá esta lista como el estado a Beta 3, no como el changelog definitivo. En cómo contribuir en la comunidad WordPress profundizamos sobre esto.

• Estilos responsivos interactivos: la función estrella del ciclo. Permite definir valores distintos de tipografía, color, padding o margen según el ancho de pantalla, desde la interfaz. Lo desarrollamos en detalle más abajo.
• Aplicar estilos locales de forma global, con revisión: Beta 3 dejó de tratarlo como un todo o nada. La opción del inspector de bloques abre un paso de revisión rápido para elegir qué estilos modificados se aplican globalmente y cuáles quedan como overrides locales.
• Cargas de medios más confiables: los GIF animados largos ya no cuelgan la subida, las imágenes rotadas con metadatos EXIF se procesan correctamente, y subir una imagen HEIC en Safari deja de crear dos entradas.
• Notas colaborativas: comentarios editoriales dentro del editor, sin pasar por un plugin ni por un documento aparte. En Beta 3 recibieron correcciones adicionales.

¿Cómo funcionan los estilos responsivos en WordPress 7.1?

Los estilos responsivos permiten asignar valores distintos a una misma propiedad CSS según el viewport, desde la interfaz del Site Editor. Elegís un bloque, seleccionás la vista de escritorio, tablet o móvil, y ajustás tamaño de fuente, color, padding o margen para esa vista en particular. WordPress genera el media query correspondiente. No hay que escribir CSS ni tocar el archivo del tema.

Hasta ahora esto se resolvía de tres formas, todas incómodas: CSS adicional en el personalizador, un page builder que trae su propio sistema de breakpoints, o clases utilitarias del tema. Las tres funcionan. Las tres te atan a algo — a un archivo que nadie más entiende, a un plugin del que después no salís, o a la documentación de un tema puntual.

• Breakpoints personalizados vía theme.json: los valores por defecto de escritorio, tablet y móvil se pueden redefinir desde el archivo del tema. Un tema con una grilla propia puede alinear sus breakpoints con los del editor en vez de pelearse con ellos.
• Sirve para diseño, no reemplaza CSS: resuelve ajustes de tipografía y espaciado, que es el 80% de los retoques responsivos del día a día. Un cambio de layout complejo — reordenar columnas, ocultar bloques enteros según el dispositivo — sigue pidiendo CSS.
• El cliente puede tocarlo: esto tiene dos caras. Un cliente que ajusta el tamaño del título en móvil sin llamar a la agencia es una llamada menos. Un cliente que descubre que puede cambiar padding por viewport y lo hace sin criterio es un sitio que se desalinea solo.

Para quien maneja varios sitios de clientes, el ahorro es concreto: los pedidos de «en el celular el título se ve gigante» dejan de ser un ticket con acceso al código y pasan a ser un ajuste de dos minutos en el editor. Habría que ver cómo se comporta con temas clásicos que no usan theme.json, porque ahí el soporte no está tan claro y es donde vive buena parte de la web instalada.

¿Cómo colaborar con otros editores en WordPress 7.1?

WordPress 7.1 suma notas colaborativas dentro del editor, que en Beta 3 recibieron correcciones adicionales. Las notas viven al costado del contenido y no modifican el texto. Es el modelo de comentarios de un documento compartido, aplicado al editor de bloques.

La comparación con Google Docs es inevitable y conviene hacerla con precisión: 7.1 cubre los comentarios editoriales adentro del editor, pero eso no es lo mismo que la edición simultánea. Dos personas en el mismo post al mismo tiempo siguen chocando con el bloqueo de post que WordPress viene usando hace años. Cubrimos ese tema en detalle en diseñar landing pages modernas.

Para una redacción chica, el valor real está en sacar la revisión editorial de Slack o del mail. El feedback queda adentro del post, atado al párrafo que lo motivó, y sigue ahí seis meses después cuando alguien pregunta por qué se escribió así.

¿Qué está confirmado y qué todavía no?

A la fecha de Beta 3, hay cosas cerradas y cosas que dependen del Field Guide final. Esta es la separación honesta entre las dos, porque en la última semana de un ciclo beta todavía se mueven piezas. Tema relacionado: profundizar en las novedades de la comunidad.

Ítem	Estado	Detalle
Fecha de lanzamiento final	Confirmada	19 de agosto de 2026, según el calendario del ciclo
Release Candidate	Confirmado	Previsto en el calendario del ciclo, antes del lanzamiento final
Estilos responsivos	Confirmado en beta	Función estrella del ciclo, disponible para testear en Beta 3
Mejoras en la carga de medios	Confirmadas en beta	GIF animados largos, rotación por EXIF y HEIC en Safari
Notas colaborativas	Confirmado en beta	Con correcciones adicionales incluidas en Beta 3
Soporte Unicode en correos electrónicos	Postergado	Previsto originalmente para 7.1, retrasado por problemas de integración
Comportamiento exacto de cada API	Sin confirmar	Se cierra en el Field Guide del ciclo, publicado cerca del RC
Compatibilidad de tu stack de plugins	Sin confirmar	Depende de cada autor; solo lo sabés testeando

La regla práctica: las fechas de un ciclo beta se corren si aparece un bloqueante. El calendario del ciclo deja colchón entre el RC y el release del 19 de agosto, que es lo habitual para el estándar del proyecto. Pero si aparece un bug grave en el RC, la fecha se mueve y el anuncio sale por el blog oficial, no por los blogs que resumen el blog oficial.

WordPress 7.1 vs 7.0: diferencias clave

El salto de 7.0 a 7.1 no es solo un incremento de versión. Mientras que 7.0 se enfocó en estabilidad y correcciones —con el parche de seguridad 7.0.2 como punto más crítico del ciclo—, 7.1 retoma el camino de las features con cambios que se tocan en el día a día.

• Editor de bloques: 7.0 dejó el editor prácticamente como estaba. 7.1 suma estilos responsivos interactivos y notas colaborativas, dos funciones que cambian la experiencia de diseño y revisión.
• Rendimiento: 7.1 incluye optimizaciones en la carga de medios y en la generación de estilos de bloque que no estaban en 7.0.
• Seguridad: 7.0.2 parchó la vulnerabilidad wp2shell, una de las más graves en años. 7.1 hereda ese parche y suma las mejoras propias del ciclo.
• Soporte Unicode: estaba en los planes de 7.1 pero se postergó. 7.0 nunca lo incluyó, así que en este rubro las dos versiones quedan empatadas por ahora.

¿Es seguro instalar WordPress 7.1 Beta 3 en mi sitio en vivo?

No. El anuncio oficial lo dice sin vueltas: «Please do not install, run, or test this version of WordPress on production or mission-critical websites». En criollo: usá un entorno de prueba o un sitio local. Una beta cambia entre commits, puede romper el editor a mitad de un post y no tiene ninguna garantía de que el camino de vuelta sea limpio. Tema relacionado: contribuciones de la comunidad WordPress.

Ponele que tenés una tienda WooCommerce con 40 pedidos por día y decidís «probar rapidito» porque total el sitio es tuyo y lo bancás. Actualizás, todo parece andar, y tres días después descubrís que un plugin de checkout guardaba mal un meta field, que los pedidos de esos tres días quedaron con datos raros, que tu backup automático corrió igual y pisó la copia buena, y que ahora tenés que reconstruir a mano. Ese es el escenario real, no una advertencia teórica.

Las opciones sanas: un sitio local con Docker o con cualquier stack de desarrollo, un subdominio de staging, o Playground si solo querés mirar. Si tu hosting te da staging con un click, usalo. En un hosting WordPress de Donweb podés levantar una instalación aparte para estas pruebas sin tocar el sitio que factura.

¿Afectará WordPress 7.1 mis plugins y temas?

No hay respuesta única, y justamente por eso existe el período de beta. La forma de saberlo es probar tu stack real en un entorno de prueba antes del 19 de agosto. Un plugin que anda con el core actual puede romperse si dependía de una función deprecada o de markup del editor que cambió. En 7.1 el foco de riesgo más claro es el sistema de estilos responsivos, que cambia cómo se generan los estilos de bloque. Sobre eso hablamos en probar betas en un ambiente seguro.

• Mirá «Probado hasta» en el repositorio: cada ficha de plugin en WordPress.org muestra hasta qué versión de WordPress lo probó el autor. No es garantía, pero un plugin sin actualizar hace dos años es una bandera roja. Seis meses sin releases ya amerita mirar el foro de soporte del plugin antes de confiar.
• Cloná tu sitio, no armes uno vacío: testear con una instalación limpia y el tema por defecto no prueba nada. El valor está en reproducir tu combinación de tema, builder y plugins.
• Activá WP_DEBUG y WP_DEBUG_LOG: los avisos de deprecación aparecen ahí antes de convertirse en un error fatal después del release.
• Prioridad a los que tocan el editor: plugins de SEO, de formularios, de membresías y page builders son los que más superficie tienen contra los cambios del editor y de los estilos. Empezá por esos.
• Bisectá cuando algo falla: desactivá todo, confirmá que el problema desaparece, y reactivá de a uno. Aburrido, pero es la única forma de saber a quién reportarle el bug.
• Avisale al autor del plugin: si encontrás la incompatibilidad ahora, tiene semanas para arreglarla. Si la encontrás el día del lanzamiento, la arregla con vos gritándole en el foro.

Cronograma de lanzamiento de WordPress 7.1

El calendario oficial del ciclo de desarrollo de WordPress 7.1 marca las siguientes fechas clave, de acuerdo con la hoja de ruta publicada por el equipo de Core:

• Beta 1: 8 de julio de 2026 — primera versión de prueba pública.
• Beta 2: 15 de julio de 2026 — correcciones iniciales.
• Beta 3: 22 de julio de 2026 — versión actual, con las features prácticamente cerradas.
• Release Candidate: fecha prevista en el calendario del ciclo, antes del lanzamiento final.
• Lanzamiento final: 19 de agosto de 2026 — versión estable para producción.

El retraso del soporte Unicode no debería afectar la fecha del lanzamiento final, ya que la decisión de postergarlo se tomó antes de Beta 3. Si apareciera un bug bloqueante en el RC, la fecha se corre y el anuncio sale por el blog oficial de WordPress. Seguilo directamente ahí, no en resúmenes de terceros.

¿Cómo actualizar a WordPress 7.1 sin romper mi sitio?

El orden que funciona es siempre el mismo: backup, staging, actualizar ahí, testear, y recién después producción. Cuando salga la versión final el 19 de agosto, este es el checklist. Ninguno de los pasos es opcional, y el que más se saltea — la copia a staging — es justo el que evita el desastre.

• Backup de base de datos y archivos: con WP-CLI, wp db export backup.sql más una copia de /wp-content/. Guardalo fuera del servidor. Un backup en la misma carpeta que el sitio no es un backup.
• Copiá el sitio a staging: con el staging de tu hosting o con un plugin de duplicación. La copia tiene que incluir la base, no solo los archivos.
• Verificá requisitos del servidor: revisá la versión de PHP y de la base de datos en Herramientas > Salud del sitio antes de tocar nada. Si tu hosting está atrasado en PHP, ese es el primer pedido que tenés que hacer.
• Desactivá cache y plugins de seguridad: los plugins de cache sirven archivos viejos después de una actualización y te hacen perseguir fantasmas. Los de seguridad a veces bloquean escrituras en el core.
• Actualizá y esperá: desde Escritorio > Actualizaciones. Dale cinco o diez minutos antes de sacar conclusiones; la migración de base y la regeneración de assets tardan.
• Reactivá plugins de a uno: uno, probás, seguís. Con veinte plugins es media hora tediosa, pero cuando algo se rompe sabés exactamente quién fue.
• Revisá lo que factura: home, un par de posts, los formularios, el buscador y el checkout si vendés. Después una prueba de velocidad para comparar contra el antes.
• Recién ahí, producción: con la lista de lo que rompió en staging ya resuelta, y en un horario de bajo tráfico.

¿Cómo vuelvo a la versión anterior si algo se rompe?

Con WP-CLI, el downgrade es un comando: wp core update --version=7.0 --force. El --force es el que permite bajar de versión. Después corré wp core update-db para que la base quede consistente. Si no tenés terminal, el plugin WP Rollback hace lo mismo desde el panel, y siempre queda el método manual por FTP reemplazando /wp-admin/ y /wp-includes/ con los de la versión estable.

Eso sí: el core baja, pero la base de datos no siempre. Si una beta corrió una migración de esquema, volver atrás puede dejarte con tablas que la versión vieja no entiende. Por eso el backup de la base antes de actualizar no es opcional, es literalmente el único plan de contingencia que funciona siempre. Con WP-CLI: wp db export backup-pre-beta.sql y guardá también /wp-content/. Lo explicamos a fondo en probar en un ambiente de staging.

¿Qué errores evitar al actualizar a WordPress 7.1?

• Probar la beta en producción «porque el sitio es chico»: el tamaño del sitio no cambia la estabilidad del código. Cambia cuánta gente se entera cuando se rompe.
• Actualizar sin backup: es el error del que no hay salida. Todos los demás tienen arreglo; este te deja reconstruyendo a mano.
• Testear con el tema por defecto y declarar victoria: si probaste Twenty Twenty y nada más, probaste que WordPress anda con WordPress. Tu combinación real es la que importa.
• Reactivar todos los plugins de golpe: si algo falla, tenés veinte sospechosos y ninguna pista. Uno por uno es lento y te da la respuesta.
• No verificar PHP y base de datos antes: descubrir en mitad de la actualización que el hosting está atrasado te deja el sitio a medio camino.
• Dejar el cache prendido: vas a estar viendo la versión vieja de tus propias páginas y reportando bugs que no existen.
• Cambiar el tema y actualizar el core el mismo día: si algo se rompe, no sabés cuál de las dos cosas fue. Una variable por vez.
• Reportar un bug sin pasos de reproducción: «no me anda el editor» no le sirve a nadie. Navegador, versión, plugins activos, qué hiciste, qué esperabas, qué pasó.
• Dejar la beta instalada y olvidarse: pasa el release final, sale la versión estable y quedás corriendo código de desarrollo por meses.

¿Cómo reporto un bug de WordPress 7.1 Beta 3?

Si encontrás un problema, el anuncio oficial pide compartirlo en el foro de soporte del proyecto (el área de Alpha/Beta). Si estás cómodo escribiendo un reporte reproducible, podés abrir el ticket directamente en Trac, el bug tracker del core. El propio anuncio marca que testear es una forma de contribuir aunque no tengas experiencia previa, y tiene razón: encontrar el bug es la parte difícil, describirlo bien es la parte que se aprende en diez minutos. Te puede servir nuestra cobertura de crear páginas de aterrizaje efectivas.

Preguntas Frecuentes

¿Cuándo sale la versión final de WordPress 7.1?

El 19 de agosto de 2026, según el calendario oficial del ciclo. Antes de eso queda el Release Candidate. Las fechas de un ciclo beta se corren si aparece un bug bloqueante, así que confirmá contra el blog oficial de WordPress.org y no contra un resumen de hace un mes.

¿Cuál es la característica principal de WordPress 7.1?

Los estilos responsivos interactivos: definir tipografía, color y espaciado distintos para escritorio, tablet y móvil desde el Site Editor, sin escribir CSS. Los breakpoints por defecto se pueden redefinir en theme.json. Resuelve los ajustes de tipografía y espaciado, no los cambios de layout complejos, que siguen pidiendo código. Esto se conecta con lo que analizamos en verificar enlaces después de actualizar.

¿Qué es el soporte Unicode para correos electrónicos y por qué se retrasó?

Es la capacidad de WordPress de procesar direcciones de correo con caracteres no ASCII: acentos, eñes, caracteres especiales y emojis. Estaba previsto para 7.1 pero se postergó por problemas técnicos de integración con servidores SMTP y retrocompatibilidad. No hay nueva fecha confirmada.

¿Qué vulnerabilidad corrigió WordPress 7.0.2?

Una vulnerabilidad pre-auth RCE (ejecución remota de código sin autenticación), conocida como wp2shell, descubierta con asistencia de OpenAI Sol Ultra GPT-5.6. Fue una de las fallas más graves en años. El parche se desplegó de forma coordinada con hosts y CDNs para mitigar la explotación masiva antes de que el parche oficial llegara vía actualizaciones automáticas.

¿WordPress 7.1 tiene edición colaborativa en tiempo real?

No. 7.1 suma notas colaborativas dentro del editor, pero eso no es lo mismo que la edición simultánea tipo Google Docs. Dos personas editando el mismo post al mismo tiempo siguen topándose con el bloqueo de post de siempre.

¿Qué mejoras trae Beta 3 respecto de las betas anteriores?

Dos mejoras de estilos —entre ellas un paso de revisión para elegir qué cambios locales se aplican globalmente— y arreglos en la carga de medios: GIF animados largos que ya no cuelgan, imágenes rotadas por EXIF procesadas correctamente y HEIC en Safari sin duplicar entradas. También hay correcciones para las notas, el estilado responsivo y el CSS personalizado.

¿Puedo instalar WordPress 7.1 Beta 3 en mi sitio en vivo?

No. WordPress.org pide de forma explícita no instalar, ejecutar ni testear esta versión en sitios de producción o críticos. Usá un sitio local, un staging, o la instancia de Playground que linkea el anuncio. Para más detalles técnicos, mirá verificar enlaces rotos tras actualizar.

¿Qué comando de WP-CLI instala la Beta 3?

El comando es wp core update --version=7.1-beta3, tal como figura en el anuncio oficial. Corrélo solo sobre una instalación de prueba y verificá dos veces contra qué sitio está apuntando tu terminal.

¿Sirve de algo que yo teste una beta?

Sí, y el proyecto lo dice: probar es una forma real de contribuir tengas o no experiencia previa. Los reportes que más pesan son los que llegan antes del Release Candidate. Cada incompatibilidad detectada durante el período beta es un sitio menos roto el 19 de agosto, empezando por el tuyo.

Conclusión

Con Beta 3 publicada el 22 de julio, el ciclo de 7.1 entra en la etapa donde el código ya está bastante cerrado y lo que falta es que la comunidad lo rompa en escenarios que nadie previó. La foto quedó clara: estilos responsivos desde el editor, cargas de medios más confiables y notas colaborativas adentro.

Lo que cambió respecto al plan original es la baja del soporte Unicode para correos electrónicos. La función se posterga sin nueva fecha, y aunque es una pérdida para los usuarios que necesitan caracteres especiales en direcciones de correo, la decisión de no largarla a medio hacer es la correcta.

Mientras tanto, la corrección de la vulnerabilidad wp2shell en 7.0.2 dejó una enseñanza: el sistema de actualizaciones automáticas y la coordinación con hosts y CDNs funcionan cuando el riesgo es real. Que una IA haya ayudado a encontrar la falla es un dato de hacia dónde va la auditoría de seguridad en open source.

El calendario manda de acá en adelante. Tenés hasta el Release Candidate para que tu reporte llegue a tiempo, y hasta el 19 de agosto para tener tu stack verificado en staging. Levantá una copia de tu sitio, actualizá con Beta Tester o WP-CLI, prendé WP_DEBUG y revisá editor, formularios y checkout. Si solo querés espiar el editor nuevo sin comprometerte a nada, abrí Playground y listo.

Fuentes

• WordPress 7.1 Beta 3 released; Unicode email support delayed — The Repository – newsletter con el anuncio del lanzamiento de Beta 3, el retraso del soporte Unicode y la respuesta de Matt Mullenweg a la comunidad.
• WordPress 7.1 Beta 3 — WordPress News – anuncio oficial del 22 de julio de 2026 con métodos de testing y advertencias.
• Roadmap to 7.1 — Make WordPress Core – hoja de ruta del ciclo con features previstas y fechas del calendario.
• Help Test WordPress 7.1 — Make WordPress Test – guía oficial de qué testear y cómo reportar.
• WordPress 7.1 Beta 1 — WordPress News – primer anuncio del ciclo beta, con el detalle inicial de novedades.