Si administras WordPress para clientes o para tu propia pyme, marzo de 2026 viene cargado de avisos oficiales que no conviene mezclar: por un lado hay que actualizar ya por seguridad; por otro, el ciclo de WordPress 7.0 pide prudencia con los entornos de prueba; y encima el proyecto ha presentado my.WordPress.net, una forma distinta de usar el software en el navegador. Te resumo lo que dice WordPress.org y qué haría yo en tu lugar.
Seguridad primero: 6.9.2 y el seguimiento 6.9.3
El equipo publicó WordPress 6.9.2 corrigiendo diez problemas de seguridad. Eso ya de por sí justifica subir de versión en cuanto puedas. Pero enseguida aparecieron informes de sitios con el front en blanco tras el cambio: lo han atribuido a temas que cargan plantillas de un modo poco habitual, usando objetos “convertibles a cadena” en rutas donde WordPress esperaba una cadena simple en el filtro template_include. No es un patrón que el proyecto considere soportado, pero rompió sitios reales, así que sacaron 6.9.3 como corrección rápida.
La moraleja práctica la tienes en la propia nota de lanzamiento: mantente en la última versión para llevar los parches de seguridad de 6.9.2 y evitar el fallo que resuelve 6.9.3. Yo suelo programar la ventana de actualización en horario flojo, copia de base de datos y archivos hecha, y un vistazo rápido al front y al escritorio tras el cambio. Si usas temas muy personalizados conviene revisar también el log de errores PHP por si algo chirría.
WordPress 7.0 beta 4: calendario y pruebas
La gran versión 7.0 está prevista para el 9 de abril de 2026, según el anuncio enlazado desde la entrada de beta 4. Esa beta incluye los mismos diez parches de seguridad que 6.9.2 y más de cuarenta y nueve cambios respecto a la beta 3 (catorce en el editor y treinta y cinco en el núcleo). Además el ciclo incorpora una beta más de las previstas: en total cinco betas en lugar de cuatro, sin mover el calendario posterior.
Lo que no debes hacer, y aquí el proyecto lo deja claro, es instalar betas en producción o en sitios críticos. Reserva un staging, el plugin WordPress Beta Tester o Playground, y prueba flujos reales: edición en bloques, plugins imprescindibles, checkout si tienes tienda, y formularios. A veces el “todo funciona” en el escritorio es mentira piadosa hasta que un visitante intenta comprar.
my.WordPress.net: útil, pero no es tu hosting
En paralelo, WordPress.org anunció my.WordPress.net: WordPress que corre en el navegador, persistente, sin registro ni plan de alojamiento de por medio, apoyado en WordPress Playground. Por defecto es privado: no es un sitio público orientado a tráfico ni SEO. Sirve para pensar, borrador, aprender, probar plugins y temas con menos miedo a romper nada.
El propio artículo lista matices que mucha gente pasará por alto: almacenamiento inicial en torno a 100 MB, primera carga más lenta mientras se descarga e inicializa, datos que se quedan en el navegador (no se suben “a la nube” del proyecto), una instalación distinta por dispositivo y la recomendación de descargar copias de seguridad con regularidad. Es decir: es una herramienta potente para experimentar, no un sustituto automático del hosting que ya facturas a tus clientes.
Para desarrolladores, el blog para desarrolladores de marzo 2026 resume líneas de trabajo del ecosistema (bloques, APIs, herramientas). Yo lo uso como checklist de qué documentación releer antes de tocar código en un proyecto serio, sobre todo si vas a alinear temas o plugins con lo que traiga 7.0.
Conclusión
En resumen: actualiza a 6.9.3 por seguridad y por el arreglo del front en blanco, mantén las betas de 7.0 lejos de producción hasta el release estable, y entiende my.WordPress.net como laboratorio personal más que como publicación abierta. Con eso reduces sustos y sigues al día con lo que el proyecto comunica en abierto.