Base de conocimientos
Desarrollo local con zinnector dev
Cómo zinnector dev ejecuta un WordPress real en su propia máquina: los dos entornos de ejecución (WebAssembly sin Docker, o PHP nativo en Docker), la elección de una versión de PHP y de WordPress, qué se sirve desde su proyecto, dónde reside el entorno de ejecución de 570 MB y qué ocurre en Node 26.
zinnector dev ejecuta un WordPress real en su propia máquina, sirviendo los complementos y temas de su proyecto, con la versión de PHP que elija. Este artículo explica los dos entornos de ejecución que puede utilizar, cómo seleccionar las versiones, qué se sirve desde dónde y dónde reside el entorno de ejecución en el disco, para que lo que pruebe localmente sea lo que despliegue.
Los dos entornos de ejecución, y por qué ambos son reales
Playground es el valor predeterminado. WordPress Playground compila PHP en WebAssembly y lo ejecuta dentro de Node, por lo que una computadora portátil sin nada instalado más que Node arranca un WordPress en segundos. Cualquier PHP desde 5.2 hasta 8.5 está disponible. Contiene un pequeño conjunto de extensiones de PHP (intl, redis, memcached según lo medido en la compilación actual), lo cual es suficiente para la mayoría del trabajo con complementos y temas.
Docker ejecuta contenedores nativos de php-fpm y MariaDB. Es más lento, necesita un demonio de Docker y alrededor de 1.2 GB de imágenes, y admite PHP de 7.4 a 8.5, pero ejecuta un PHP nativo con el conjunto completo de extensiones, incluidas imagick y gd. Es la respuesta honesta cuando lo que necesita probar es una extensión que la compilación de WebAssembly no incluye.
zinnector dev # playground
zinnector dev --runtime docker # php nativo + MariaDBA Docker nunca se recurre de forma silenciosa. A un desarrollador que cree que está en WebAssembly y en realidad está en Docker se le ha dado una respuesta incorrecta por parte de una herramienta que intenta ayudar, por lo que debe solicitarse por su nombre.
Elección de las versiones de PHP y WordPress
zinnector dev --php 8.1 --wp 6.7 # desarrollar con un par específico
zinnector dev --port 9401 # cuando el puerto 9400 está ocupado
zinnector dev --no-login # no iniciar sesión en wp-admin automáticamente
zinnector dev --verbose # mostrar la propia salida del entorno de ejecuciónLos valores predeterminados provienen de zinnector.json en el proyecto (php, wordpress, runtime y port), que zinnector new escribe y que usted debe confirmar en el control de versiones, para que todos en el proyecto ejecuten las mismas versiones. Un indicador en la línea de comandos prevalece sobre el archivo para esa ejecución.
La versión que declara y la versión que se ejecuta son hechos diferentes. zinnector dev --once arranca el entorno de ejecución, imprime lo que realmente informa (versión de PHP, versión de WordPress, extensiones cargadas) y se detiene. zinnector check --probe utiliza la misma medición cuando compara su proyecto con un espacio de alojamiento.
Qué se sirve desde su proyecto
El entorno de ejecución monta los directorios wp-content/plugins, wp-content/themes y wp-content/mu-plugins de su proyecto directamente, por lo que un archivo que guarde está activo en la próxima recarga. Los directorios que existen pero no contienen contenido real no se montan deliberadamente: un themes/ vacío montado sobre los propios temas del entorno de ejecución dejaría a WordPress sin ningún tema, lo cual da como resultado un error 500 en blanco en lugar de su sitio. Es por eso que el andamiaje mantiene los directorios vacíos con un archivo .gitkeep y por qué no eclipsan nada hasta que coloca un tema en ellos.
Dónde reside el entorno de ejecución
El entorno de ejecución de WordPress se descarga en el primer uso en lugar de enviarse con la CLI; el paquete que contiene cada compilación de PHP pesa unos 570 MB, y un desarrollador que solo lista sitios no debería pagar por ello. Se mantiene en la propia caché de Zinnector®, en ~/.cache/zinnector/runtimes/playground/<version> (o donde apunte ZINNECTOR_CACHE_DIR), nunca en su proyecto, por lo que no puede terminar en su repositorio ni en el árbol que mide zinnector push. La descarga la realiza su propio npm, ejecutado como node npm-cli.js, nunca a través de un shell.
La versión del entorno de ejecución está vinculada a la versión de la CLI, por lo que dos desarrolladores en un proyecto ejecutan las mismas compilaciones de PHP. zinnector dev --reset-runtime descarta el entorno de ejecución instalado y lo instala nuevamente, lo cual es la solución para un entorno de ejecución que se instaló pero no arranca.
En Node 26 o posterior
La CLI en sí misma se ejecuta en cualquier versión de Node a partir de la 24. El módulo nativo del entorno de ejecución, sin embargo, incluye binarios precompilados solo para Node 24 y 25 (a partir de septiembre de 2026). En lugar de compilar algo —lo que en Windows significa instalar Visual Studio—, Zinnector® obtiene un Node 24 únicamente para el entorno de ejecución, de unos 30 MB, verificado frente a las sumas de comprobación que publica nodejs.org, en la misma caché. El mensaje de instalación lo indica cuando se aplica. Nada sobre su propio Node cambia.
Relacionados
¿Sigues con dudas?
El soporte técnico está incluido en todos los planes y respondemos en tu propio idioma.
Contactar con soporte → Todos los artículos →