01
Más rápido que un plugin personalizado.
Una app DesignSetGo es un paquete estático y un manifest. Sin boilerplate PHP. Sin scaffold de plugin. Sin canal de actualización que escribir tú mismo.
DesignSetGo Apps te ofrece una unidad más pequeña que un plugin completo: distribuye un único paquete a N clientes con un comando CLI, actualízalos todos de la misma manera. Los despliegues multisite y la marca blanca están en el plan Studio.
El ciclo de la agencia
Es el mismo bucle init, login, deploy que usan los desarrolladores, solo repetido por cliente. Construye la aplicación una vez, luego ejecuta designsetgo apps login --site y designsetgo apps deploy --site contra el nombre de host de cada cliente. Cada instalación lee los datos de WordPress de ese cliente.
Consulta la página de desarrolladores para ver el tutorial completo de CLI. El bucle init, login, deploy →
Entregar a muchos sitios
Sin gestor de flota personalizado. El CLI toma un único --site por llamada; las agencias lo integran en la orquestación que ya tienen, un shell loop, una matriz CI, una tarea Ansible.
# Build once. npm run build # Ship the same dist/ to every client. for site in client-1.com client-2.com client-3.com; do designsetgo apps deploy --site "$site" --no-build done
En CI, el mismo loop se convierte en un paso matrix en GitHub Actions, con secretos por sitio. Hay un deploy-action starter que envuelve el CLI.
Por qué las agencias adoptan esto
01
Una app DesignSetGo es un paquete estático y un manifest. Sin boilerplate PHP. Sin scaffold de plugin. Sin canal de actualización que escribir tú mismo.
02
Un bug en un plugin snippet rompe el sitio. Un bug en una app DesignSetGo rompe la app. El sandbox hace que "enviar a todos los clientes el viernes" sea una idea aceptable.
03
"La suite de reservas" o "el portal de clientes" es ahora un SKU. Un paquete, N clientes, tarifa mensual. Lo mantienes una vez, no N veces.
Etiqueta blanca
La página de DSGo Apps en wp-admin, la pantalla de instalación, los estados vacíos, todo puede llevar el nombre y logo de tu agencia en lugar del nuestro. Los clientes ven tu marca ejecutando sus herramientas de sitio, no un plugin de terceros que revendes.
01
Establece plugin_name y logo_url en la configuración de etiqueta blanca. Cada superficie de admin los detecta: elemento de menú, pantalla de instalación, tarjetas de aplicación.
02
Reemplaza nuestra documentación y enlaces de soporte con los tuyos. Los clientes te preguntan cuando necesitan una respuesta, no en el foro de código abierto.
03
Entrega un único zip que instala el plugin, aplica tu marca y preinstala tu portal o paquete de reservas. La incorporación de nuevos clientes pasa de una lista de verificación de configuración a una carga.
La marca blanca está incluida en el plan Studio. Pro puede ejecutar despliegues CLI multisite pero se distribuye bajo el nombre DesignSetGo Apps. Ver precios →
Registro de plantillas privadas
Aloja tus propios paquetes en cualquier URL HTTPS que controles. Tu equipo genera nuevos proyectos de clientes desde tu biblioteca, no desde el inicio público.
01
Ejecuta designsetgo apps registry add acme https://acme.example/registry.json --token xxx una vez. Después de eso, cada apps init puede descargar de tu biblioteca por alias.
02
Fija una versión específica de plantilla (--template booking-widget@1.4.0) o toma la más reciente. Verificación de integridad SHA-256 en cada descarga, por lo que un tarball manipulado se niega a instalar.
03
Una vez configurado en un sitio, el constructor Riff en admin enumera tus plantillas privadas junto con las públicas, con un botón de un clic "Copiar comando CLI" para tus desarrolladores.
designsetgo apps registry add acme https://acme.example/registry.json --token xxx designsetgo apps init clients/new-site --template booking-widget --registry acme
Tú proporcionas los bytes (GitHub Pages, S3, tu propio sitio WP, CDN interno); DesignSetGo proporciona la especificación y la infraestructura CLI. Disponible en el plan Studio. Ver precios →
Modelo de confianza
La mayoría de las apps de agencia se revisan internamente. El modo inline es la opción predeterminada correcta: páginas reales de WordPress, SEO nativo, montable en raíz. El modo iframe es la opción correcta para paquetes suministrados por el cliente que no escribiste tú mismo.
La app se renderiza como una página real de WordPress. Rastreable, indexable, compatible con el tema, limpio para SEO. CSP y la desinfección de HTML se ejecutan en cada solicitud. El paquete es tu propio código, por lo que el modelo de confianza es "plugin de confianza que distribuyes".
"isolation": "inline" Sandbox reforzado por el navegador con un origen opaco. Úsalo cuando un cliente te entrega un paquete HTML de su freelancer o un artefacto Claude guardado. El puente sigue funcionando; la página no comparte origen con el resto del sitio.
"isolation": "iframe" Referencia de CLI
Incluyendo --site, --sites, --from-artifact y la deploy-action para CI.
$ designsetgo apps init booking-pack --astro $ designsetgo apps login --site client-1.com $ designsetgo apps login --site client-2.com $ for s in client-1.com client-2.com; do > designsetgo apps deploy --site "$s" > done ✓ deployed to 2 sites └ same app id, atomic per site