WordPress 7.1 ya está aquí: qué cambió, por qué importa y cómo probarlo gratis con LocalWP

WordPress acaba de dar otro paso importante en la evolución de su editor.

El 19 de agosto de 2026 se publicó oficialmente WordPress 7.1 “Mary Lou”, la segunda versión mayor de WordPress de este año. Más de 800 personas participaron en el lanzamiento y, según la información oficial recopilada para esta versión, el release reúne más de 1.500 mejoras y correcciones.

Pero reducir WordPress 7.1 a una cifra de cambios sería perderse la parte más interesante de esta actualización.

Durante años, construir determinados comportamientos en WordPress significaba recurrir a CSS personalizado, instalar otro plugin o utilizar un page builder como Elementor o Bricks.

Responsive avanzado, estados hover, determinados componentes de interfaz, sistemas de iconos, procesamiento de medios o incluso ciertas herramientas de colaboración se resolvían muchas veces alrededor de WordPress, no directamente dentro de WordPress.

7.1 empieza a cambiar esa relación.

No convierte Gutenberg en un sustituto completo de Elementor. Tampoco elimina la necesidad de plugins.

Lo que sí hace es trasladar hacia el Core varias capacidades que antes dependían mucho más del ecosistema externo.

Y esa dirección puede ser más importante que cualquiera de las funciones individuales de esta actualización.

¿Qué es WordPress 7.1 “Mary Lou”?

WordPress 7.1 fue lanzado el 19 de agosto de 2026 y recibe el nombre “Mary Lou” en homenaje a la pianista, compositora y arreglista de jazz Mary Lou Williams. El calendario oficial confirma que el lanzamiento llegó después de varias betas, tres Release Candidates, un ensayo final y un congelamiento del código antes de la versión estable.

No se trató de una actualización improvisada ni de una versión creada específicamente para solucionar una vulnerabilidad.

El roadmap de WordPress 7.1 llevaba meses señalando varias prioridades: mejorar el diseño responsive, incorporar estados interactivos, fortalecer el trabajo con medios, continuar desarrollando las herramientas de colaboración y hacer más estructuradas las APIs sobre las que pueden construir plugins, automatizaciones y otras herramientas.

La Field Guide final reúne más de 310 tickets de WordPress Core, entre ellos más de 100 mejoras o solicitudes de funcionalidades y más de 180 correcciones de errores.

Por eso 7.1 no tiene una única “función estrella” que transforme WordPress de un día para otro.

Es más interesante verlo como una colección de piezas que empiezan a apuntar hacia la misma dirección.

¿Por qué WordPress hizo esta actualización?

Hay una tensión histórica dentro de WordPress.

El CMS es extremadamente extensible, y precisamente por eso existen miles de themes, plugins y builders capaces de llevarlo mucho más lejos que su instalación base.

Pero esa misma flexibilidad también ha significado que tareas relativamente comunes puedan terminar necesitando software adicional.

Un sitio puede empezar con WordPress y terminar dependiendo de:

Elementor o Bricks para layout, otro addon para componentes, otro plugin para Tabs, CSS personalizado para responsive, un paquete de iconos, una herramienta para optimizar imágenes y varios plugins adicionales para ampliar el editor.

WordPress 7.1 no elimina ese ecosistema. Lo que hace es elevar el punto de partida del Core.

El propio roadmap identifica el diseño responsive y el manejo de pseudoestados como dos áreas sobre las que la comunidad llevaba tiempo dando feedback. La intención explícita era permitir hacer más directamente desde el Site Editor sin recurrir constantemente a CSS.

Ese detalle explica buena parte de esta actualización.

Responsive nativo: probablemente el cambio más importante de WordPress 7.1

Esta es una de las novedades más relevantes para diseñadores y desarrolladores.

WordPress 7.1 incorpora estilos responsive para bloques.

Ahora el sistema contempla estilos base, Tablet y Mobile, tanto desde Global Styles como en instancias individuales de bloques que utilizan los controles compatibles de WordPress.

Pensemos en un ejemplo sencillo.

Supongamos que una sección tiene:

Escritorio: 64 px de padding.
Tablet: 32 px.
Móvil: 16 px.

Tradicionalmente, dependiendo del theme y del editor utilizado, esto podía terminar en una media query:

Un builder como Elementor también permite resolverlo visualmente desde hace tiempo.

La diferencia es que ahora WordPress Core empieza a incorporar esa lógica dentro de su propio sistema de estilos.

Los valores responsive pueden utilizar propiedades soportadas por Core relacionadas con tipografía, color, fondos, bordes, dimensiones, espaciado y layout. WordPress genera después el CSS necesario para esos valores.

WordPress también permite definir los breakpoints

Por defecto, WordPress establece actualmente estos rangos:

• Mobile: hasta 480 px.
• Tablet: superior a 480 px y hasta 782 px.
• El estilo base funciona como escritorio.

Pero un theme puede modificar esos puntos de corte mediante theme.json, utilizando valores en px, em o rem.

Para un desarrollador esto es particularmente interesante porque empieza a permitir que el sistema responsive forme parte del propio sistema de diseño del theme.

No simplemente de CSS adicional repartido por el proyecto.

Hover, focus y active empiezan a entrar al editor

WordPress 7.1 también incorpora controles para estados de interacción como:

hover
focus
focus-visible
active

Estos estados pueden definirse desde Global Styles y, en determinados casos, para bloques individuales.

Por ejemplo, un botón puede tener fondo verde normalmente y cambiar a otro color cuando el usuario pasa el cursor.

Es algo completamente normal en desarrollo web.

La novedad es que WordPress empieza a proporcionar una interfaz visual para configurarlo sin necesidad de escribir el selector:

Pero hay una limitación importante

No significa que todos los bloques tengan ahora un editor completo de pseudoestados.

En WordPress 7.1 la interfaz está limitada principalmente a Button y Navigation Link.

Es importante hacer esta distinción porque decir que “WordPress ya permite hacer todos los hover sin CSS” sería exagerar lo que realmente llegó.

La infraestructura está ahí.

La implementación todavía está comenzando.

Tabs llega al Core de WordPress

Otro cambio representativo es el bloque Tabs.

Las interfaces por pestañas existen en páginas web desde hace décadas, pero históricamente WordPress necesitaba un theme, shortcode, plugin de bloques, addon de Elementor o desarrollo personalizado para implementarlas.

WordPress 7.1 empieza a incorporar este tipo de componentes directamente dentro de Core. La actualización también incluye un bloque Playlist para organizar contenido multimedia.

Tabs puede parecer una función pequeña.

Estratégicamente, sin embargo, representa perfectamente lo que está ocurriendo:

una funcionalidad común que antes necesitaba algo externo pasa a formar parte de la plataforma base.

Entonces, ¿WordPress 7.1 reemplaza Elementor?

No.

Elementor, Bricks y otros page builders siguen teniendo una profundidad de herramientas visuales mucho mayor.

Ofrecen sistemas de layout avanzados, widgets, responsive detallado, componentes, condiciones, animaciones, templates, integraciones y ecosistemas que Gutenberg todavía no replica completamente.

El cambio interesante es otro.

Cada vez que WordPress incorpora al Core:

responsive, estados interactivos, Tabs, mejores estilos globales, sistemas de iconos o nuevos bloques,

se reduce ligeramente el conjunto de razones por las que un proyecto necesita instalar un builder para resolver tareas relativamente básicas.

No significa:

“Gutenberg acaba de matar Elementor”.

La lectura más precisa sería:

WordPress está elevando progresivamente lo que puedes construir sin depender de un page builder.

Ese proceso probablemente sea mucho más relevante a medio plazo que cualquier comparación puntual entre Gutenberg y Elementor.

Una de las mejores novedades está escondida: WordPress ahora puede procesar imágenes en tu navegador

Aquí aparece uno de los cambios técnicamente más interesantes de WordPress 7.1.

Tradicionalmente, cuando alguien sube una imagen a WordPress ocurre algo similar a esto:

Imagen → servidor → PHP → GD/Imagick → diferentes tamaños → almacenamiento

El servidor recibe la fotografía y utiliza recursos de CPU y memoria para redimensionarla, generar thumbnails, corregir orientación, convertir formatos y realizar otras operaciones.

Esto puede convertirse en un problema especialmente con imágenes grandes o servidores limitados.

WordPress 7.1 incorpora procesamiento multimedia del lado del cliente.

Eso significa que determinados trabajos pueden hacerse directamente dentro del navegador utilizando WebAssembly y wasm-vips, basado en la biblioteca libvips.

El flujo puede parecerse ahora más a:

Imagen → navegador → procesamiento → archivos optimizados → servidor

Entre las operaciones que WordPress puede ejecutar en el navegador están compresión, resize, crop, conversión de formatos, rotación y generación de thumbnails.

¿Qué ventajas tiene?

La primera es evidente: menos trabajo para el servidor.

Al trasladar parte del procesamiento al dispositivo del usuario, WordPress puede reducir el consumo de CPU y memoria PHP.

También evita determinados errores relacionados con límites de memoria cuando se procesan fotografías muy grandes.

Hay además un beneficio directamente relacionado con performance: WordPress indica que la implementación basada en libvips puede producir JPEG aproximadamente un 15 % más pequeños que determinados procesos tradicionales con GD o Imagick.

Y la actualización mejora situaciones como fotografías HEIC provenientes de iPhone y archivos AVIF en servidores que no tienen soporte completo para esos formatos.

¿El procesamiento de imágenes funciona en cualquier navegador?

No exactamente.

Esta es otra limitación que merece explicación.

La pipeline completa depende actualmente de características disponibles principalmente en navegadores basados en Chromium.

La documentación de WordPress señala soporte completo desde Chrome 137+ y Edge 137+. Firefox y Safari utilizan automáticamente el procesamiento tradicional del servidor cuando las capacidades necesarias no están disponibles.

WordPress también comprueba aspectos como memoria disponible, número de núcleos del procesador y determinadas condiciones de red antes de activar el procesamiento local.

Si el dispositivo no cumple los requisitos, WordPress hace fallback automáticamente al servidor.

Por eso no debería interpretarse como:

“A partir de 7.1 todas las imágenes siempre se procesan en tu computador”.

La afirmación correcta es:

WordPress 7.1 puede procesarlas localmente cuando el navegador y el dispositivo lo permiten.

Las cargas también se vuelven más resistentes

Hay otro detalle interesante dentro de este nuevo sistema.

Las diferentes versiones de una imagen pueden enviarse mediante solicitudes independientes. Si ocurre una interrupción temporal de conexión, WordPress puede reintentar solicitudes e incluso pausar cargas cuando el dispositivo queda offline y reanudarlas cuando vuelve la conexión.

Es una mejora menos visible que un nuevo botón dentro de Gutenberg, pero arquitectónicamente bastante importante.

WordPress 7.1 también mejora la edición multimedia

No todo ocurre detrás de escena.

La experiencia de edición de imágenes también fue replanteada para reunir operaciones como crop libre, proporciones, rotación y otros controles dentro de una interfaz dedicada. El trabajo multimedia era una de las áreas expresamente señaladas en el roadmap de 7.1.

Para usuarios no técnicos, probablemente este tipo de mejoras termine siendo más perceptible que muchas de las APIs internas que incorpora la actualización.

Colaboración: mejor, pero todavía no es Google Docs

WordPress continúa trabajando en la tercera gran fase histórica del proyecto Gutenberg: colaboración. La hoja de ruta general de WordPress sigue situando la coautoría como una de las etapas centrales del proyecto.

WordPress 7.1 mejora Notes y las herramientas de feedback asíncrono.

Pero hay una aclaración importante:

la colaboración en tiempo real no llegó finalmente a WordPress 7.1.

La propia Field Guide la incluye entre las funcionalidades que quedaron fuera del release final.

Por tanto, todavía no estamos ante una experiencia exactamente equivalente a tener varias personas escribiendo simultáneamente un Google Doc.

WordPress sigue avanzando hacia ese escenario, pero no está ahí todavía.

Los cambios para developers pueden ser incluso más importantes

Algunas de las novedades de 7.1 prácticamente no serán visibles para un usuario normal.

Pero pueden tener más impacto para el ecosistema a largo plazo.

Abilities API

WordPress continúa evolucionando la Abilities API, una estructura para que diferentes sistemas puedan descubrir de una forma más consistente qué puede hacer una instalación de WordPress.

Por ejemplo:

crear contenido, obtener información, modificar una configuración o ejecutar determinada acción.

La Field Guide de 7.1 incorpora nuevas mejoras relacionadas con consulta, filtrado, exposición y ejecución de abilities.

Esto tiene implicaciones interesantes para automatización e inteligencia artificial.

No significa que:

“WordPress 7.1 ya tenga agentes de IA”.

No los tiene por el simple hecho de incorporar esta API.

Pero sí ayuda a construir una infraestructura donde una herramienta externa pueda interactuar con WordPress mediante capacidades más estructuradas y controladas.

SVG Icon API

WordPress también continúa desarrollando su sistema de iconos.

Themes y plugins pueden trabajar con colecciones registradas de iconos, acercando Core a una lógica más coherente de sistemas de diseño. El roadmap incluso plantea colecciones que agencias y fabricantes de productos puedan proporcionar como conjuntos propios.

Para una web pequeña puede parecer irrelevante.

Para una organización con un design system compartido entre múltiples productos, es una pieza mucho más interesante.

WordPress 7.1 tampoco es solamente buenas noticias

Una actualización mayor de WordPress siempre implica una cuestión adicional:

compatibilidad.

WordPress puede funcionar correctamente y aun así un sitio presentar errores después de actualizar.

¿Por qué?

Porque una instalación real no contiene únicamente WordPress Core.

Normalmente contiene:

Core + theme + plugins + código personalizado + integraciones + servidor.

Cambiar una pieza puede revelar incompatibilidades en las demás.

Y WordPress 7.1 ya dejó un ejemplo interesante apenas un día después de su lanzamiento.

El caso WP Rocket demuestra por qué no conviene actualizar a ciegas

Después de la publicación de WordPress 7.1 aparecieron reportes de un Fatal Type Error en determinadas configuraciones con WP Rocket.

WP Rocket publicó el 20 de agosto una corrección específica para el problema. La investigación completa del release documenta el caso y la respuesta del proveedor.

Esto no significa que:

“WordPress 7.1 rompe WP Rocket”.

Mucho menos que WordPress 7.1 sea un lanzamiento inestable.

Significa que apareció una incompatibilidad específica en determinadas configuraciones y que el proveedor publicó rápidamente una corrección.

Es un excelente ejemplo de por qué staging sigue siendo necesario.

¿Deberías actualizar inmediatamente a WordPress 7.1?

Depende del sitio.

En una web sencilla, con plugins mantenidos, theme actualizado, backup reciente y poca complejidad, probar la actualización puede ser relativamente directo.

En una web que genera ingresos o soporta procesos importantes —por ejemplo un ecommerce, reservas, membresías, formularios de leads o integraciones empresariales— la decisión debería ser diferente.

Antes de pasar a producción conviene revisar realmente:

navegación, responsive, formularios, recepción efectiva de leads, login, checkout, pagos, correos transaccionales, buscadores, filtros, bloques personalizados, page builder, subida de archivos, popups, analytics e integraciones.

Y existe una forma bastante sencilla de hacerlo sin tocar tu página real:

Local.

También conocido comúnmente como LocalWP.

¿Qué es LocalWP y para qué sirve?

Local es una aplicación de escritorio diseñada para ejecutar WordPress dentro de tu propio computador.

En lugar de comprar un hosting, configurar un dominio, instalar PHP, crear manualmente una base de datos y configurar un servidor web, Local prepara ese entorno por ti.

La aplicación puede manejar servicios como PHP, MySQL y NGINX o Apache directamente en tu sistema.

Esto permite tener algo como:

mi-proyecto.local

y abrirlo desde Chrome como si fuera cualquier otra página web.

Pero esa página no está publicada en internet.

Está corriendo en tu computador.

¿Cómo funciona realmente?

Cuando visitas una web normal ocurre, de forma simplificada:

Tu navegador → Internet → servidor del hosting → WordPress → base de datos

Con Local:

Tu navegador → servidor local de tu computador → WordPress → base de datos local

Local dispone además de un router que traduce un dominio legible, por ejemplo ejemplo.local, hacia el puerto interno donde está ejecutándose el sitio.

Por eso puedes experimentar prácticamente como si estuvieras trabajando en un hosting real sin que el proyecto sea públicamente accesible.

¿Para qué puedes utilizar Local?

Es especialmente útil para desarrollar una web desde cero, probar plugins, experimentar con themes, revisar actualizaciones antes de producción, importar una página existente, desarrollar código, crear demos o aprender WordPress sin pagar hosting.

También puedes crear Blueprints, que son configuraciones reutilizables con themes, plugins, páginas y ajustes preinstalados. Eso permite levantar rápidamente nuevos proyectos con una estructura base.

Para una agencia o desarrollador que crea muchos sitios WordPress similares, esto puede ahorrar bastante tiempo.

Cómo instalar LocalWP paso a paso

Local está disponible para macOS, Windows y distribuciones Linux compatibles. La documentación actual indica como referencia mínima 4 GB de RAM y aproximadamente 1,5 GB de espacio, aunque naturalmente los proyectos grandes necesitarán más almacenamiento. En macOS la versión actual requiere oficialmente Monterey 12 o superior, mientras que en Windows son compatibles Windows 10 de 64 bits y Windows 11.

El proceso completo es el siguiente:

1. Entra a la página oficial de Local y descarga la aplicación. Selecciona la versión correspondiente a macOS, Windows o Linux. Descargar Local
2. Instala Local. En macOS abre el archivo .dmg y mueve Local a la carpeta Applications. En Windows abre el instalador y sigue el asistente. Windows puede mostrar avisos de Defender la primera vez que Local levanta sus servicios; la documentación oficial indica permitir el acceso necesario para que sus componentes puedan comunicarse.
3. Abre Local y crea un sitio nuevo. Pulsa el botón + y selecciona Create a new site.
4. Asigna un nombre al proyecto. Puede ser, por ejemplo, wordpress-71-pruebas. Local utilizará ese nombre para organizar el sitio y generar su dominio local.
5. Selecciona el entorno. Para una prueba sencilla puedes utilizar Preferred, que utiliza la configuración predeterminada de Local. Si quieres reproducir de forma más precisa las condiciones de un hosting específico, selecciona Custom y define versiones de PHP, servidor web y base de datos. Local permite trabajar con NGINX o Apache y distintas versiones disponibles de PHP y MySQL.
6. Crea las credenciales de WordPress. Define el nombre de usuario administrador, una contraseña y un correo. Estas credenciales son las que utilizarás para iniciar sesión posteriormente en wp-admin.
7. Pulsa Create Site. Local prepara WordPress, crea la base de datos, configura PHP, genera el dominio local y levanta los servicios necesarios.
8. Comprueba que el sitio esté iniciado. Si aparece detenido, utiliza Start Site.
9. Abre la página. Con Open Site puedes ver el frontend y con WP Admin entrar directamente al panel de administración.
10. Comprueba la versión de WordPress. Dentro de Escritorio → Actualizaciones, verifica que el sitio esté utilizando WordPress 7.1. Si la instalación creada no está todavía en 7.1, actualízala desde ahí antes de comenzar las pruebas.
11. Instala el theme y los plugins que quieras comprobar. Si tu objetivo es evaluar una actualización real, intenta reproducir lo más posible la combinación utilizada en producción.
12. Empieza a probar WordPress 7.1. Ya puedes experimentar con responsive, estados interactivos, bloques, medios o incluso romper completamente el sitio sin afectar la página pública.

Preferred vs. Custom: ¿cuál deberías seleccionar?

Si estás aprendiendo WordPress o simplemente quieres conocer 7.1:

Preferred es suficiente.

Local seleccionará un stack recomendado y puedes empezar rápidamente.

Si estás haciendo una prueba de compatibilidad de un sitio real:

Custom suele ser más interesante.

Puedes intentar aproximarte a las versiones de PHP, base de datos y servidor utilizadas por producción.

Por ejemplo, si la web real utiliza una determinada versión de PHP, probar únicamente con otra completamente diferente puede ocultar o generar errores que no reflejen el entorno de producción.

Local precisamente permite cambiar entre versiones de PHP y trabajar con NGINX o Apache.

Cómo probar las nuevas funciones de WordPress 7.1 en LocalWP

Una vez tengas WordPress 7.1 funcionando, podemos convertir Local en nuestro pequeño laboratorio.

Prueba el nuevo responsive

Utiliza un block theme compatible y abre el Site Editor.

WordPress 7.1 permite cambiar entre estados responsive y definir valores específicos para tablet y móvil. Puedes comenzar con algo muy evidente, como modificar el padding o el tamaño tipográfico de un bloque.

Después abre el frontend y cambia el tamaño de la ventana para comprobar qué CSS termina generando WordPress.

Los breakpoints predeterminados son 480 px para Mobile y 782 px como límite superior de Tablet, aunque los themes pueden modificarlos.

Prueba hover, focus y active

Dentro de Site Editor puedes ir a:

Styles → Blocks → Button

y utilizar el selector de estados para modificar Hover, Focus o Active. WordPress publicó incluso instrucciones específicas de testing para comprobar tanto los estilos globales como los de un botón individual.

Cambia, por ejemplo, el fondo del botón al hacer hover y después visita el frontend para comprobar el resultado.

Prueba el procesamiento de imágenes

Abre WordPress desde una versión moderna de Chrome o Edge y sube una fotografía grande.

Si el navegador, dispositivo y conexión cumplen las condiciones requeridas, WordPress podrá utilizar el procesamiento local basado en WebAssembly.

En navegadores no compatibles, simplemente volverá al proceso tradicional del servidor.

Una prueba interesante sería comparar el comportamiento de una misma fotografía en Chrome y Firefox.

Instala tus plugins reales

Si administras una página que utiliza:

Elementor, Bricks, WooCommerce, ACF, WP Rocket, formularios, plugins SEO o integraciones personalizadas,

instálalos también en el entorno local.

El objetivo de staging no debería ser simplemente comprobar:

“WordPress abre”.

Hay que comprobar si el sistema completo sigue funcionando.

¿Puedo copiar mi web real a Local?

Sí.

Local dispone de herramientas para importar y exportar sitios, incluyendo archivos, base de datos y configuración.

Esto hace mucho más útil el entorno para probar actualizaciones porque no necesariamente tienes que reconstruir manualmente tu página.

Puedes llevar una copia del proyecto a Local y realizar allí las pruebas.

La regla importante es otra:

si vas a utilizar una copia de producción, recuerda que puede contener datos reales de usuarios, clientes o pedidos.

Un entorno local sigue siendo un entorno que debes manejar con cuidado.

¿Local reemplaza un hosting?

No.

Local es principalmente un entorno de desarrollo.

Un sitio alojado ahí depende de que tu computador esté encendido y no está configurado como infraestructura pública de producción.

Un hosting está pensado para:

estar disponible 24/7, gestionar tráfico real, tener infraestructura de red pública, copias de seguridad, seguridad, recursos del servidor y disponibilidad.

Local resuelve otro problema:

permitirte construir y probar antes de publicar.

¿Necesitas internet para utilizar LocalWP?

Una vez que el entorno y los componentes necesarios están instalados, el sitio se ejecuta directamente en tu computador.

Sin embargo, determinadas acciones sí requieren conexión, por ejemplo descargar plugins, themes, actualizaciones, servicios adicionales o utilizar funciones conectadas a plataformas externas.

Local también consulta algunos servicios para descargar o actualizar componentes de su entorno.

¿Qué ocurre con la base de datos?

Local crea y administra una base de datos para cada instalación.

WordPress continúa funcionando conceptualmente igual que en un hosting:

los archivos del theme y los plugins están en el sistema de archivos, mientras que páginas, configuraciones, usuarios, opciones y otra información se almacenan en MySQL.

La diferencia es que todo está dentro de tu propio equipo.

Por eso Local es tan útil para aprender WordPress en profundidad: permite observar claramente que una instalación no es simplemente “un conjunto de páginas”, sino una aplicación que combina servidor web, PHP, archivos y base de datos.

LocalWP también puede ahorrar mucho tiempo en proyectos recurrentes

Una de sus herramientas más útiles son los Blueprints.

Imagina que cada proyecto nuevo normalmente comienza instalando:

un theme base, tus plugins habituales, ajustes de seguridad, herramientas SEO, analytics y determinadas configuraciones.

Puedes preparar una instalación con esa estructura y guardarla como Blueprint.

Cuando llegue otro proyecto, creas el nuevo sitio desde ese Blueprint y Local restaura themes, plugins, páginas y configuración preestablecida.

Para workflows repetitivos es bastante más eficiente que comenzar cada WordPress desde cero.

¿Qué significa realmente WordPress 7.1 para el futuro del CMS?

Probablemente esta sea la pregunta más interesante.

Ninguna de las funciones que hemos visto individualmente cambia por completo WordPress.

Responsive ya existía en Elementor.

Hover ya existía con CSS.

Tabs existía en cientos de plugins.

Optimización de imágenes ya existía con herramientas especializadas.

Los sistemas de iconos tampoco son nuevos.

Lo diferente es dónde están ocurriendo ahora esas cosas.

WordPress está incorporando progresivamente más capacidades dentro de su plataforma base.

Eso puede tener varias consecuencias.

Una instalación puede requerir menos dependencias para proyectos sencillos.

Los themes pueden construir sistemas de diseño más coherentes sobre APIs compartidas.

Los plugins pueden integrarse con una infraestructura más estandarizada.

El editor puede acercarse progresivamente a las capacidades visuales que durante años fueron territorio casi exclusivo de los builders.

Y nuevas APIs pueden facilitar la relación entre WordPress, automatizaciones y herramientas basadas en inteligencia artificial.

Esto no significa que debamos dejar de usar plugins

La conclusión tampoco debería irse al extremo contrario.

El ecosistema de plugins es precisamente uno de los mayores activos de WordPress.

Hay funcionalidades que no tiene sentido introducir en Core.

Un ecommerce avanzado seguirá necesitando software especializado.

Un constructor visual puede seguir siendo mejor para determinados proyectos.

Una integración de marketing requiere lógica que WordPress Core no necesita asumir.

El objetivo razonable no es:

“instalar cero plugins”.

Es:

utilizar plugins cuando aportan una capacidad real, no porque Core no pueda resolver una necesidad básica.

Esa diferencia puede producir sitios más sencillos de mantener.

¿Vale la pena actualizar a WordPress 7.1?

Sí, pero actualizar y actualizar inmediatamente en producción no son exactamente la misma decisión.

WordPress 7.1 representa un avance importante en edición responsive, procesamiento multimedia, sistemas visuales y APIs.

No existe evidencia actualmente de que sea un lanzamiento desastroso o que debamos evitarlo.

Pero acaba de ser publicado.

Y ya tenemos ejemplos que demuestran que algunos plugins han tenido que ajustar compatibilidad.

Por eso, para un proyecto importante, el flujo correcto sigue siendo:

backup → entorno de prueba → actualización → testing → producción.

Local puede encargarse precisamente de una parte de ese proceso.

La actualización más interesante no es una sola función

Después de revisar el release, el roadmap, la Field Guide y las notas técnicas de WordPress 7.1, hay una conclusión que resume bastante bien esta versión.

WordPress 7.1 no reinventa WordPress.

Hace algo posiblemente más importante:

empieza a llevar al Core muchas de las cosas que durante años tuvimos que resolver alrededor de WordPress.

Responsive.

Estados interactivos.

Componentes.

Medios.

Sistemas de diseño.

APIs.

Automatización.

Por separado parecen mejoras incrementales.

Juntas muestran con bastante claridad hacia dónde quiere avanzar WordPress.

Y para quienes desarrollamos sitios con esta plataforma, probablemente esa dirección sea mucho más importante que cualquiera de las 1.500 mejoras individuales que aparecen en el changelog.

Preguntas frecuentes

¿WordPress 7.1 reemplaza Elementor?

No. Elementor y otros builders siguen ofreciendo herramientas visuales mucho más extensas. WordPress 7.1 sí incorpora al Core algunas capacidades que anteriormente hacían más probable necesitar un builder o CSS adicional.

¿WordPress 7.1 permite diseño responsive sin CSS?

En determinados controles y bloques, sí. WordPress 7.1 incorpora estados Tablet y Mobile para propiedades soportadas por Core. No significa que cualquier diseño responsive avanzado pueda construirse completamente sin CSS.

¿WordPress 7.1 tiene hover?

Sí. Puede manejar estados Hover, Focus, Focus-visible y Active, aunque la interfaz inicial está limitada principalmente a Button y Navigation Link.

¿WordPress 7.1 tiene inteligencia artificial?

No sería correcto describirlo así. Existen APIs e infraestructura relacionadas con automatización y herramientas externas, pero WordPress 7.1 no incorpora simplemente “un agente de IA” que gestione tu sitio.

¿LocalWP es gratis?

Local ofrece gratuitamente su aplicación de escritorio para desarrollo local. La propia página oficial la presenta como una descarga gratuita.

¿Puedo instalar WordPress sin comprar hosting utilizando Local?

Sí. Local ejecuta WordPress en tu propio computador y configura servicios como PHP, MySQL y el servidor web necesarios para trabajar localmente.

¿Una página creada con Local está publicada en internet?

No por defecto. El sitio corre en tu computador. Local dispone de otras funciones para compartir o desplegar proyectos, pero una instalación local normal no equivale a un hosting público.

¿Local sirve para probar actualizaciones?

Sí. Es precisamente uno de sus usos más útiles: puedes crear o importar un sitio, actualizar WordPress, theme y plugins, probar el resultado y evitar que los experimentos afecten directamente a producción.

Fuentes verificadas

Este artículo se construyó a partir de la investigación técnica realizada sobre WordPress 7.1 y fue contrastado con documentación oficial de WordPress y Local.

WordPress 7.1 Field Guide — Make WordPress Core

Responsive block styles en WordPress 7.1

Pseudo y custom style states en WordPress 7.1

Client-Side Media Processing en WordPress 7.1

Instalación oficial de Local

Características de Local