WordPress 7.1 Beta 3: como probarla sin romper tu sitio

Actualizado el 23/07/2026: WordPress 7.1 Beta 3 quedó publicada el 22 de julio de 2026 y el calendario oficial del ciclo fija el lanzamiento final para el 19 de agosto de 2026. Sumamos abajo el detalle de las características que llegan en esta versión: estilos responsivos en el Site Editor y notas colaborativas.

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 el proyecto 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 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.

WordPress es un sistema de gestión de contenidos de código abierto creado por Matt Mullenweg y desarrollado por la comunidad. Permite crear, publicar y administrar contenido en sitios web.

¿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.

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.

Í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
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.

¿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.

¿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.

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, que también figura en ese calendario. 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.

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

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.

Por qué importa: los estilos responsivos son el cambio que más trabajo diario ahorra si manejás sitios de clientes, y también el que más riesgo de incompatibilidad trae para tus plugins, porque cambia cómo se generan los estilos de bloque. Se testea en una tarde.

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 (esa parte, la verdad, es de las mejores cosas que sumó el proyecto en años).

Fuentes

• 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.
• WordPress Beta Tester – plugin oficial para recibir builds beta y RC.