Trabajar WordPress en Windows mejoró con WSL2, pero todavía es fácil acumular capas: Windows, Docker Desktop, otra máquina virtual, certificados, proxies y herramientas que abstraen partes distintas del entorno. A veces el entorno termina siendo más complejo que el sitio que queríamos levantar.
La idea de trabajar WordPress directamente sobre WSL2 parte de una pregunta bastante simple: ¿Cuántas capas hacen falta realmente para tener un entorno local confiable?
WSL2 ya es Linux
WSL2 no es solamente una terminal de Linux dentro de Windows. Corre un kernel de Linux real, tiene su propio sistema de archivos y permite ejecutar herramientas como Docker, PHP, MySQL, Node o WP-CLI en un entorno mucho más parecido al servidor donde probablemente termine viviendo el proyecto.
Eso cambia bastante el enfoque. En lugar de usar Windows como sistema principal y agregar Linux como una capa secundaria para determinadas tareas, se puede tratar WSL2 como el entorno de desarrollo y dejar Windows para lo que hace bien: navegador, editor, aplicaciones de escritorio y el resto del trabajo cotidiano.
El sistema de archivos importa
Uno de los errores más comunes es instalar todo correctamente en WSL2 pero mantener el proyecto dentro del sistema de archivos de Windows. Algo como:
/mnt/c/Users/...
Funciona, pero obliga a WSL2 a trabajar continuamente sobre archivos que viven del otro lado de la frontera entre Windows y Linux. En proyectos WordPress eso puede sentirse bastante rápido. Miles de archivos pequeños, Composer, npm, búsquedas dentro del proyecto, Git y operaciones sobre wp-content empiezan a pagar ese costo una y otra vez.
Mover los proyectos al sistema de archivos nativo de WSL2, por ejemplo:
~/projects/mi-sitio suele eliminar buena parte de esa fricción. No es un ajuste cosmético. Cambia dónde está ocurriendo realmente el trabajo.
Docker tampoco necesita tantas capas
Docker Desktop resuelve muchos problemas y para determinados equipos sigue siendo una excelente herramienta. Pero si el entorno ya está corriendo Linux mediante WSL2, también es posible ejecutar Docker directamente ahí. Eso elimina una capa de administración entre el proyecto y los contenedores.
El resultado puede ser un flujo bastante simple: WSL2 → Docker → WordPress No significa que Docker Desktop sea malo. Significa que no necesariamente tiene que formar parte de todos los entornos. Si una herramienta no está resolviendo un problema concreto, vale la pena preguntarse por qué está ahí.
HTTPS local debería ser aburrido
HTTPS en desarrollo local suele ser una de esas cosas que funcionan perfectamente hasta que dejan de hacerlo. Certificados autofirmados, warnings del navegador, excepciones manuales y dominios locales configurados de forma distinta en cada proyecto. Herramientas como mkcert permiten generar certificados confiables localmente y evitar buena parte de ese ruido.
Si además hay un proxy como Traefik encargado de enrutar los proyectos, cada sitio puede tener una dirección predecible:
https://mi-sitio.localhost y comportarse desde el principio de una forma mucho más parecida a producción. HTTPS deja de ser una tarea que hay que resolver por proyecto y pasa a ser parte del entorno.
WP-CLI debería usar el mismo mundo que WordPress
Otra fuente frecuente de problemas aparece cuando WordPress corre con una versión de PHP y WP-CLI con otra. El sitio funciona dentro de un contenedor con PHP 8.1, pero el comando que ejecutamos desde nuestra terminal está usando PHP 8.3 instalado en el sistema.
La diferencia puede pasar desapercibida hasta que un plugin, una dependencia o un script se comporta distinto. Un entorno predecible debería evitar ese tipo de desalineación. Si WordPress corre con una determinada versión de PHP, las herramientas que operan sobre ese WordPress deberían trabajar en el mismo contexto siempre que sea posible.
Menos combinaciones significa menos lugares donde buscar cuando algo falla.
Importar producción también forma parte del entorno
Levantar un WordPress vacío es fácil. El caso real suele ser otro. Tenemos un sitio de producción con años de contenido, uploads, plugins, opciones serializadas, cachés y referencias al dominio original. Y necesitamos tenerlo funcionando localmente.
Ahí es donde un buen entorno empieza a ahorrar tiempo. La guía sobre cómo importar WordPress sin romper datos serializados cubre ese proceso con más detalle. Una importación puede implicar:
- Restaurar una base de datos
- Copiar
uploads - Reemplazar el dominio
- Respetar datos serializados
- Limpiar cachés
- Regenerar archivos generados por algunos plugins
- Adaptar configuraciones que solamente tienen sentido en producción
Si cada desarrollador tiene una receta diferente para hacerlo, el entorno todavía depende demasiado de conocimiento manual.
Más opciones no siempre significan mejor herramienta
Hay herramientas excelentes que permiten configurar prácticamente cualquier escenario. Eso es valioso cuando realmente necesitamos esa flexibilidad. Pero también tiene un costo: cada opción nueva es otra decisión que alguien tiene que tomar, entender y mantener. Para un flujo específico puede ser mejor hacer lo contrario.
Se puede elegir una combinación concreta —WordPress, WSL2, Docker, HTTPS, WP-CLI y un proyecto por entorno— y optimizarla. No es la única forma correcta de desarrollar WordPress, pero limitar el problema permite automatizar mucho más.
El entorno local no debería ser un proyecto aparte
Un buen entorno de desarrollo desaparece mientras trabajamos. No debería requerir que pensemos diariamente en redes de Docker, certificados, versiones del runtime o configuraciones del proxy. Todo eso sigue existiendo, pero deja de ser el trabajo principal. El trabajo es modificar el sitio, probarlo y seguir.
Por eso reducir capas no es solamente una cuestión de performance. También reduce decisiones, diferencias entre proyectos y cantidad de cosas que pueden romperse. El objetivo no es minimizar componentes como ejercicio. Es que cada capa resuelva un problema reconocible y que el entorno deje de ocupar atención durante el trabajo diario. Ese criterio fue también el punto de partida de Docal.