Entorno local profesional para plugins: depurar rápido y romper menos
Configuras un entorno reproducible de WordPress para desarrollar plugins con seguridad: logs útiles, separación de entornos y un flujo que evita subir errores a producción.
Cuando un plugin da problemas en producción, casi siempre empezó con un entorno local mal planteado: sin logs, sin reglas y sin una forma clara de reproducir errores.
En esta lección montarás un flujo de trabajo de desarrollador, no de improvisación: local para construir, staging para validar y producción solo para publicar.
También vas a preparar `wp-config.php` para obtener señales útiles de error sin exponer información sensible a usuarios finales.
El resultado es simple: menos tiempo adivinando, más tiempo corrigiendo con evidencia.
- No existe una única herramienta, pero sí criterios claros para elegir.
- Si trabajas solo y quieres velocidad, herramientas como LocalWP son cómodas para levantar sitios en minutos. Si trabajas en equipo, suele compensar un setup versionable (por ejemplo Docker o wp-env) para que todos ejecuten el mismo entorno.
- Criterio práctico: cuanto más crítico sea el proyecto, más importante es que el entorno sea reproducible por comandos y no solo por clics.
- Para este curso, lo importante no es la herramienta exacta sino que tengas: PHP compatible, acceso a logs, base de datos aislada y posibilidad de resetear rápido.
- Equipo pequeño: local guiado (rápido para arrancar).
Qué stack local usar y por qué
No existe una única herramienta, pero sí criterios claros para elegir.
Si trabajas solo y quieres velocidad, herramientas como LocalWP son cómodas para levantar sitios en minutos. Si trabajas en equipo, suele compensar un setup versionable (por ejemplo Docker o wp-env) para que todos ejecuten el mismo entorno.
Criterio práctico: cuanto más crítico sea el proyecto, más importante es que el entorno sea reproducible por comandos y no solo por clics.
Para este curso, lo importante no es la herramienta exacta sino que tengas: PHP compatible, acceso a logs, base de datos aislada y posibilidad de resetear rápido.
- Equipo pequeño: local guiado (rápido para arrancar).
- Equipo con CI/CD: entorno declarativo y versionado.
- Siempre: logs accesibles y control de versiones del plugin.
Configura debug sin comprometer seguridad
Debugear bien no significa mostrar errores al usuario final.
En local conviene tener `WP_DEBUG` y `WP_DEBUG_LOG` activos, pero `WP_DEBUG_DISPLAY` desactivado para evitar ruido visual durante pruebas funcionales.
Con `SCRIPT_DEBUG` activo cargas versiones no minificadas de scripts y estilos, útil cuando trabajes con assets del plugin.
Regla clave: estos flags deben depender del entorno. Nunca dejes exposición de errores en producción.
Flujo sano: local -> staging -> producción
Publicar directo desde local a producción es el origen de muchos incidentes evitables.
Local sirve para construir y hacer pruebas rápidas; staging para validar comportamiento real con datos cercanos a producción; producción solo recibe versiones ya comprobadas.
Caso real: un plugin de avisos con query costosa funcionaba bien en local con pocos datos, pero en producción degradó tiempos de carga. En staging con copia real de datos se detectó y se corrigió antes de afectar usuarios.
Este flujo te protege de falsas sensaciones de estabilidad y te obliga a validar rendimiento y compatibilidad antes del release.
Observabilidad mínima para avanzar rápido
No basta con activar logs; debes saber qué buscar y dónde.
Revisa `wp-content/debug.log` como parte del flujo diario. Si aparece un warning nuevo tras un cambio, trátalo como deuda técnica inmediata.
Añade mensajes de log con contexto en puntos críticos del plugin (activación, guardado de ajustes, callbacks de render).
Usa WP-CLI para tareas repetitivas (activar plugin, limpiar caché, ejecutar acciones) y ahorrar tiempo operativo.
- Log útil: incluye módulo, acción y dato clave.
- Evita logs ruidosos en bucles o peticiones masivas.
- Documenta comandos frecuentes en un README del plugin.