nuevo zinnector
Genere la estructura de un sitio, un complemento o un tema de bloques que se inicie de inmediato. Sin archivos de marcador de posición, sin TODOs: el complemento se activa y el tema se puede seleccionar en cuanto se crea.
Zinnector®
Zinnector® compila WordPress localmente sin nada instalado excepto Node —sin Docker, sin MAMP—, luego compara lo que ha creado con la ranura de alojamiento donde va a desplegar y le indica qué no coincidirá, antes de hacer push. Instálelo con npm install -g zinnector. Es gratuito, con licencia MIT y creado sobre la misma API pública que todo lo demás aquí.
La mayoría de las CLI de alojamiento comienzan en el despliegue. Zinnector® comienza antes: construye el sitio con usted y, a continuación, comprueba su trabajo en comparación con la máquina a la que está a punto de enviarlo. La brecha entre «funcionaba en mi portátil» y «funciona en el servidor» es donde se pierden las tardes, y esa brecha es medible.
Genere la estructura de un sitio, un complemento o un tema de bloques que se inicie de inmediato. Sin archivos de marcador de posición, sin TODOs: el complemento se activa y el tema se puede seleccionar en cuanto se crea.
Un WordPress real en su equipo en cuestión de segundos, que sirve sus propios plugins y temas, sin Docker y sin PHP en su PATH. Elija cualquier PHP desde la versión 5.2 hasta la 8.5 para desarrollar.
La comprobación previa. Compara lo que ha creado con la ranura en la que va a realizar la implementación y nombra cada discrepancia —y cada comprobación que no pudo realizar— antes de hacer push.
Realice la comprobación previa, envíe sus confirmaciones, active el despliegue y sígalo hasta su finalización. Si falla, el registro de compilación está a solo un comando de distancia.
Pregunte al asistente desde el terminal, utilizando su proyecto y su sitio como contexto. Se ejecuta en la plataforma con su propia cuenta, por lo que nunca se almacena ninguna clave de modelo en su equipo.
Seis comandos, en orden, y el aspecto del resultado correcto en cada uno. Todo aquí se ejecuta en su propia máquina; solo se necesita una clave de API cuando llegue a un espacio de alojamiento.
Ejecute npm install -g zinnector en Node 24 o superior. Si npm muestra EBADENGINE, su Node es anterior a 24 — instale la versión LTS actual desde nodejs.org y ejecute la instalación de nuevo.
zinnector --version muestra un número de versión como 0.1.2. En una versión de Node anterior a la 24, muestra un mensaje indicando que se requiere Node 24 o posterior y se cierra.
zinnector --help enumera cada comando a continuación con una descripción de una línea de su propósito. Cada comando también admite su propia opción --help.
zinnector new my-site crea un proyecto que se inicia inmediatamente —un zinnector.json, un árbol wp-content y un README— y muestra los siguientes comandos que debe ejecutar.
cd my-site, luego zinnector dev. La primera ejecución solicita una vez descargar el entorno de ejecución de WordPress (aproximadamente 570 MB, guardado en la propia caché de la CLI, nunca en su proyecto). El éxito se muestra como «running at http://127.0.0.1:9400».
http://127.0.0.1:9400 es un sitio de WordPress nuevo; /wp-admin abre el panel de control con la sesión ya iniciada. Coloque un plugin en wp-content/plugins y estará allí en la próxima recarga.
zinnector login, zinnector link, zinnector check, zinnector push: verifique previamente lo que ha creado contra la ranura, luego despliegue y observe cómo finaliza.
Usted creó en PHP 8.3. El espacio ejecuta 8.1. Nada le avisa hasta que el sitio se queda en blanco. Ese es el problema por el cual existe este comando, y es el que el propietario de esta plataforma solicitó por su nombre. Zinnector® lee ambos entornos y los coloca lado a lado; luego le permite implementar de todos modos, porque usted podría tener una razón para ello.
Una discrepancia de versión principal se marca como alta porque daña un sitio con seguridad; una discrepancia menor se marca como inferior. Calificar todo como crítico solo enseña a las personas a ignorar la advertencia.
Un árbol de WordPress consta de decenas de miles de archivos pequeños, y un sitio web puede agotar su asignación de inode situándose muy por debajo de su límite de disco. Ambos se comprueban en función de lo que realmente queda en la ranura, no del plan.
Una comprobación que no puede ver su objeto informa como no comprobada, nunca como superada. Una ejecución limpia indica cuántos elementos no pudo verificar, ya que nadie revisa dos veces una falsa alarma de todo correcto.
Cada hallazgo se puede anular con --force, y el resumen así lo indica. En CI, el código de salida actúa como puerta de control, por lo que una canalización puede ser estricta mientras una persona mantiene el control.
WordPress Playground es la opción predeterminada: PHP compilado a WebAssembly, ejecutándose dentro de Node, por lo que una computadora portátil que solo tenga instalado Node pasa de la nada a un WordPress en funcionamiento aproximadamente en el tiempo que lleva leer esta oración.
Cuando necesite un PHP nativo —una extensión como imagick, un MySQL real— pase --runtime docker y obtenga contenedores php-fpm y MariaDB en su lugar. Ambos sirven los mismos archivos del mismo proyecto, por lo que cambiar entre ellos modifica el motor y nada más.
Zinnector® está desarrollado sobre la misma API pública que el panel de control, por lo que todo lo que puede hacer el panel, también lo puede hacer él — y cada comando es una operación documentada en la especificación de OpenAPI en lugar de un endpoint privado.
Enumere sitios, lea todo lo que la plataforma sabe sobre uno, vuelva a desplegar y lea el historial de despliegues y los registros de compilación.
Enumere dominios, lea y modifique registros DNS mostrándose el registro antes de escribirse y lea sus servicios de correo.
Cambie las versiones de PHP, consulte el uso de disco y de inodos en relación con lo que permite su plan, obtenga enlaces de un solo uso para phpMyAdmin y monitorice los registros de acceso y errores en tiempo real.
Ejecute comandos de WP-CLI incluidos en la lista de permitidos en un sitio, y vacíe cachés o inicie análisis de malware en toda una selección en una sola llamada en lugar de una por sitio.
La lista completa, una línea por cada uno. La referencia completa —cada indicador, un ejemplo ejecutable y lo que imprime cada comando— se genera a partir de la propia CLI y se encuentra en la documentación para desarrolladores y en la base de conocimientos, por lo que no puede desfasarse de la herramienta que tiene instalada.
Genere la estructura de un proyecto de WordPress que pueda ejecutar de inmediato.
Ejecute este proyecto localmente: no se requiere Docker.
Inicie sesión con una clave de API de Zinn Digital®.
Olvidar una clave de API guardada.
Mostrar como quién está autenticada esta CLI.
Enumere los sitios que esta clave puede ver.
Todo lo que la plataforma sabe sobre un sitio.
Dé acceso a una persona a un solo sitio —un desarrollador, un diseñador, un cliente— con un rol y un motivo.
Vea a quién se le ha concedido acceso a un sitio, su rol y si ya lo ha aceptado.
Revocar el acceso de una persona, por correo electrónico o identificador de concesión.
Las invitaciones que le están esperando, y acepte una.
Apunte este proyecto a una ranura de alojamiento (y conecte su repositorio).
Descargue los archivos de un sitio alojado en este proyecto para el desarrollo local y vuelva a ejecutarlo para resincronizar. Utiliza la ruta rápida cuando el sitio se sincroniza con su propio repositorio; de lo contrario, funciona a partir de la copia de seguridad más reciente.
Sincronización bidireccional entre los archivos en vivo de un sitio alojado y su repositorio: consulte su estado, actívela, confirme los cambios del sitio o elija qué lado prevalece.
Un puente al servidor MCP de Zinn Digital® para Claude Desktop y otros clientes de AI que solo inician servidores locales.
Cree un proyecto local a partir de un sitio alojado en un solo paso: clone su repositorio o descargue sus archivos, escriba el archivo de proyecto y quede listo para ejecutar zinnector dev.
Compare este proyecto con la ranura en la que está a punto de implementar.
Realice la comprobación previa, envíe sus confirmaciones e impleméntelo.
Vuelva a implementar lo que la plataforma ya tiene, sin hacer push.
Historial de despliegues de un sitio.
Muestre o cambie la versión de PHP de un sitio.
Uso de disco, archivos y base de datos con respecto a lo que permite el plan.
Tamaño de la base de datos y enlaces de un solo uso a phpMyAdmin y al administrador de archivos.
Siga en tiempo real los registros de acceso y de errores de un sitio.
Ejecute un comando de WP-CLI permitido en un sitio.
Listar y realizar copias de seguridad del sitio. Subcomandos: list, now.
Enumere los dominios que esta clave puede ver.
Lea y modifique los registros DNS. Subcomandos: list, add, rm.
Listar servicios de correo.
Ejecute una operación en varios sitios (cache_purge, malware_scan, sitemap, block_ip).
Pregunte al asistente de Zinn Digital®, con este proyecto como contexto.
No. `zinnector new` y `zinnector dev` no necesitan ninguna cuenta: genere la estructura de un plugin, un tema o un sitio completo y ejecútelo localmente, gratis, para siempre. Solo se necesita una clave de API para los comandos que se comunican con su alojamiento.
No para el entorno de ejecución predeterminado. WordPress Playground compila PHP a WebAssembly y se ejecuta dentro de Node, por lo que `zinnector dev` arranca un WordPress real en segundos sin necesidad de instalar nada más. Si necesita un PHP nativo —para probar una extensión como imagick o ionCube—, `--runtime docker` le proporciona contenedores de php-fpm y MariaDB en su lugar. Ambos son compatibles; ninguno es una solución de respaldo.
Su versión local de PHP frente a la del slot, si el slot puede incluso cambiar a la versión sobre la que desarrolló, si el PHP del slot ha superado el fin de su vida útil y si la máquina realmente lo ha aplicado, el tamaño y el recuento de archivos de su proyecto frente al espacio libre restante de disco e inodos, las versiones de WordPress en cada lado, si el slot ha finalizado el aprovisionamiento y si hay un repositorio de git conectado desde el que desplegar. Cualquier elemento que no se haya podido comprobar se notifica como no comprobado en lugar de contabilizarse como aprobado.
No, y eso es deliberado. La comprobación previa advierte y le permite continuar; `--force` implementa ignorando cualquier hallazgo. Usted sabe cosas sobre su propio sitio que un comprobador desconoce, y una herramienta que se niega a implementar es una herramienta que la gente desinstala.
La clave nunca se lee desde la línea de comandos —solo desde una solicitud o stdin canalizado—, por lo que no puede terminar en el historial de su shell ni en una lista de procesos. Se almacena en su propio directorio de configuración con el modo de archivo 600, y Zinnector® vuelve a aplicar esos permisos cada vez que escribe.
Sí. Configure `ZINNECTOR_TOKEN`, y cada comando aceptará `--json`. La salida legible por humanos va a stderr y los datos a stdout, por lo que las tuberías se mantienen limpias. `zinnector check` finaliza con un código distinto de cero cuando encuentra algo, por lo que funciona como una puerta de enlace de canalización, y `--strict` también falla cuando no se pudo realizar una comparación.
Ejecute npm install -g zinnector o pruébelo una vez con npx zinnector new my-site. Gratuito, con licencia MIT y basado en la API pública. Genere la estructura de un proyecto, ejecútelo localmente sin Docker y verifíquelo antes de implementarlo.
Leer la documentación