El desarrollo moderno de WordPress ha evolucionado más allá de las configuraciones manuales y los flujos de trabajo de despliegue inconsistentes. Radicle combina Roots y otras herramientas de desarrollo de WordPress, como Bedrock, Sage y Acorn, en un único stackde inicio.
Esta integración significa que puedes tener la experiencia de desarrollo de Laravel directamente en WordPress.
Además, instalar Radicle en Kinsta te proporciona un entorno de alojamiento que cumple los requisitos técnicos que exige este stack. Obtendrás acceso SSH, integración WP-CLI y la posibilidad de configurar el directorio raíz.
Esta guía describe el proceso de configuración y los pasos necesarios para que Radicle funcione en la infraestructura de Kinsta.
Radicle y sus componentes
Radicle combina tres proyectos distintos de Roots en un entorno de desarrollo integrado:
- Bedrock proporciona la base con su estructura de carpetas mejorada y la gestión de dependencias basada en Composer.
- Sage se encarga del desarrollo de temas con la integración de CSS de Tailwind y Vite para la creación de activos.
- Acorn tiende un puente entre WordPress y Laravel aportando plantillas Blade, migraciones, enrutamiento y mucho más a tus proyectos de WordPress.
Este tipo de entorno de desarrollo te permite trabajar directamente desde la raíz del proyecto, en lugar de dentro de los típicos directorios de temas. Tus plantillas se encuentran en resources/views/ en la raíz del proyecto, mientras que la configuración se realiza a través de archivos específicos del entorno en el directorio bedrock.
Composer gestiona el núcleo de WordPress, los plugins y las dependencias personalizadas a través de un único archivo composer.json. El stack requiere PHP 8.3 o superior, junto con extensiones específicas. También necesitas Composer para la gestión de dependencias y WP-CLI para las operaciones de línea de comandos.
Radicle vs a WordPress tradicional
Las instalaciones estándar de WordPress (es decir, poner todo dentro del directorio wp-content) pueden complicar el control de versiones y dificultar el mantenimiento de instalaciones coherentes en distintos entornos.
Sin embargo, Radicle reestructura esto para que puedas controlar la versión del código de tu aplicación sin rastrear los archivos del núcleo de WordPress ni los medios subidos:
- El núcleo de WordPress se encuentra en el directorio
public/wp, separado del código de tu aplicación. - El directorio
public/contentsustituye awp-content, y el código de tu tema personalizado vive en la raíz del proyecto.
La configuración al estilo Laravel utiliza un archivo .env en lugar de incrustar las credenciales de la base de datos y las claves de seguridad dentro de los archivos de configuración. Defines ajustes diferentes para los entornos de desarrollo, staging y de producción mediante archivos de configuración independientes en bedrock/environments/.
Tu estrategia de control de versiones se beneficia porque sólo realizas un seguimiento del código y la configuración de tu aplicación. Las actualizaciones del núcleo de WordPress se producen a través de Composer, los plugins sirven como dependencias y los cambios de tema se almacenan en tu repositorio.
Configurar Radicle para Kinsta
Cuando despliegues en Kinsta, necesitarás una clave de autenticación SSH, que está disponible a través del panel MyKinsta.
Localiza tus detalles de acceso SFTP/SSH en la sección Información del sitio y añade tu clave SSH pública si aún no lo has hecho.
La infraestructura de Kinsta se ajusta a los requisitos técnicos de Radicle. Ejecuta PHP 8.3, incluye Composer para la gestión de dependencias y tiene WP-CLI preinstalado, para que puedas gestionar WordPress directamente desde la línea de comandos.
A diferencia de una instalación tradicional de WordPress, Radicle utiliza una estructura de directorios basada en versiones. Cada despliegue crea una carpeta de versión con fecha y hora, y un enlace simbólico current apunta a la versión activa. La raíz web de tu aplicación debe establecerse en public/current/public.
A continuación, configura tus variables de entorno. Copia el archivo .env.example en la raíz de tu proyecto Radicle y cámbiale el nombre a .env. A continuación, añade los detalles de tu base de datos y la configuración del entorno:
DB_NAME='your_database_name'
DB_USER='your_database_user'
DB_PASSWORD='your_database_password'
DB_HOST='your_database_host'
WP_ENV='staging'
WP_HOME='https://{kinsta-staging-url}'
WP_SITEURL="${WP_HOME}/wp"
Radicle instala el núcleo de WordPress dentro de un subdirectorio /wp. Esto mantiene los archivos del núcleo separados del código de tu aplicación personalizada, favoreciendo una estructura más limpia y controlada por versiones.
Configuración del staging
Tu directorio de configuración se encuentra en la raíz de tu proyecto Radicle, junto a las carpetas public y resources. Abre bedrock/environments/staging.php para definir los ajustes específicos de tu entorno staging. Este archivo anula los valores de bedrock/application.php siempre que el archivo .env establezca WP_ENV en staging.
Establece la URL de tu sitio staging añadiendo las siguientes constantes en la parte superior de staging.php:
<?php
define('WP_HOME', 'https://staging-url');
define('WP_SITEURL', WP_HOME . '/wp');
La URL de staging sigue el patrón de la sección Entornos de tu sitio al seleccionar el entorno staging.
Tu ruta de despliegue determina dónde aterrizan los archivos en el servidor Kinsta. En MyKinsta, observa la ruta en Detalles del entorno. Esta ruta suele ser /www/sitename/public y representa tu destino de despliegue. Tu script de despliegue sincroniza los archivos aquí, creando una estructura como /www/sitename/public/releases/timestamp para cada despliegue, con /www/sitename/public/current como enlace simbólico a la versión activa.
También es una buena idea activar el modo de depuración para tu entorno de pruebas en bedrock/environments/staging.php. Además, copia y establece las credenciales de tu base de datos para el entorno de pruebas en tu archivo local .env (que no debe ser enviado al control de versiones). Alternativamente, configúralas como variables de entorno en tu servidor de despliegue. Kinsta generará credenciales únicas para cada entorno.
Configuración de producción
Una vez que cambies a tu entorno de producción desde el menú desplegable del panel de control de MyKinsta, el proceso de configuración será idéntico al del entorno staging, pero utilizando valores específicos de producción y ajustes de seguridad más estrictos.
Para ello, abre bedrock/environments/production.php en el directorio bedrock de la raíz de tu proyecto y modifica la URL de producción:
<?php
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', WP_HOME . '/wp');
El tratamiento de los errores de producción será distinto al de staging. La principal diferencia consiste en desactivar la visualización de depuración, manteniendo el registro de errores:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false); Además, copia las credenciales de la base de datos de producción de la sección Acceso a la base de datos de MyKinsta mientras estés en tu entorno en producción. Estas credenciales suelen diferir de las de staging. Sin embargo, las rutas de despliegue de producción siguen el mismo patrón que las de staging, pero apuntan al directorio de tu entorno en producción. La ruta dentro de los detalles del Entorno de MyKinsta probablemente tendrá una URL diferente (aunque similar). Tu script de despliegue apuntará a esta ruta para las versiones de producción.
Modificar las tareas de despliegue
El despliegue por defecto de Radicle asume un control del servidor que Kinsta no proporciona a través del alojamiento administrado. Por ello, debes eliminar cualquier tarea de despliegue que intente gestionar los servicios del servidor.
Si utilizas Trellis (la herramienta de despliegue por defecto de Radicle), edita trellis/roles/deploy/hooks/finalize-after.yml y elimina por completo la tarea Reload php-fpm. Kinsta gestiona automáticamente los reinicios de PHP-FPM cuando detecta cambios en los archivos.
Además, la limpieza de la caché se realiza a través de la API de Kinsta en lugar de mediante comandos del servidor, por lo que deberás sustituir cualquier limpieza de caché basada en el servidor por una solicitud HTTP al endpoint de limpieza de caché de Kinsta. Puedes añadir esta tarea a tu hook de finalización del despliegue una vez que hayas configurado una clave API:
- name: Clear Kinsta cache
uri:
url: "{{ site_env.wp_home }}/kinsta-clear-cache-endpoint/"
method: GET
Cada sitio tiene un endpoint único por seguridad, que puedes obtener del equipo de soporte de Kinsta.
La compilación de activos se ejecuta antes del Despliegue, no en el servidor. Tu máquina de desarrollo local o el pipeline de CI/CD ejecuta npm run build para compilar JavaScript y CSS en el directorio public/build. Estos activos compilados se implementarán junto con tus archivos PHP.
La instalación de dependencias de Composer se produce después de la sincronización de archivos mediante SSH para ejecutar lo siguiente:
cd /www/sitename/public/current
composer install --no-dev --optimize-autoloader --no-interaction
La bandera --no-dev excluye las dependencias de desarrollo, como los frameworks de pruebas y las herramientas de depuración. La bandera --optimize-autoloader construye mapas de clases para una carga automática más rápida, reduciendo la sobrecarga de localizar archivos de clases durante las peticiones.
Añadir el plugin Kinsta MU a Radicle
El plugin Kinsta MU permite el almacenamiento en caché de toda la página, la integración con CDN y la gestión del caché de tu sitio a través de MyKinsta. Debido a la estructura de directorios no estándar de Radicle, necesitarás establecer algunas constantes de configuración específicas, aunque puedes añadir el plugin Kinsta MU a Radicle a través de Composer. Puedes añadir estas constantes a tu archivo bedrock/application.php después de instalar el plugin:
/**
* Kinsta CDN fix for Radicle/Bedrock structure
*/
define('KINSTA_CDN_USERDIRS', 'app');
/**
* Fix Kinsta MU Plugins URL path with Radicle/Bedrock
*/
$mu_plugins_url = Config::get('WP_CONTENT_URL') . '/mu-plugins';
define('KINSTAMU_CUSTOM_MUPLUGIN_URL', "{$mu_plugins_url}/kinsta-mu-plugins");
La primera constante especifica tu directorio de subidas en la estructura app de Bedrock. La segunda corrige las rutas URL de los activos del plugin para que cargue correctamente los archivos JavaScript y CSS.
Una vez que hayas verificado la instalación del plugin, puedes probar la limpieza de la caché a través del panel de control de MyKinsta para confirmar que el plugin se comunica correctamente con la infraestructura de Kinsta.
Cómo configurar despliegues automatizados
GitHub Actions es una forma sencilla de automatizar los despliegues de Radicle en Kinsta. Por ejemplo, puedes crear un archivo de flujo de trabajo en tu repositorio en .github/workflows/deploy.yml. Este flujo de trabajo se activa al enviar a ramas específicas, que construyen activos y despliegan código en el entorno correspondiente.
Los secretos SSH almacenados en tu repositorio de GitHub permitirán conexiones seguras a los servidores de Kinsta. Para ello, añade secretos para tu clave privada SSH, host Kinsta, puerto SSH y nombre de usuario dentro de GitHub.
Un script de despliegue coordina el proceso de sincronización de archivos. Este script suele utilizar rsync para transferir archivos de forma eficiente, envía sólo los archivos modificados y mantiene los permisos adecuados. Sin embargo, debes excluir del despliegue archivos de desarrollo como node_modules, .git, y .env para mantener limpio tu entorno de producción.
Una vez que la sincronización de archivos se ha realizado correctamente, pueden ejecutarse las tareas de limpieza y limpieza del caché. El proceso implica que el script de despliegue haga una petición al endpoint de limpieza de caché de Kinsta, espere la confirmación y ejecute los comandos de limpieza necesarios.
Configuración de GitHub Actions
Puedes definir tu automatización del despliegue dentro de la raíz del repositorio creando un archivo .github/workflows/deploy.yml. Esto se encargará de la compilación de activos, la instalación de dependencias y la sincronización de archivos con Kinsta.
Aquí, comienza con disparadores específicos de rama que desplieguen la rama staging a tu entorno staging y la rama main a producción:
name: Deploy to Kinsta
on:
push:
branches:
- staging
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '22'
- name: Install dependencies and build assets
run: |
npm ci
npm run build
Las matrix strategies (estrategias de matriz) permiten gestionar varios entornos sin duplicar el código del flujo de trabajo. Las variables específicas de cada entorno que añadas pueden cambiar según la rama que haya activado el flujo:
strategy:
matrix:
include:
- branch: staging
ssh_host: ${{ secrets.KINSTA_STAGING_HOST }}
ssh_port: ${{ secrets.KINSTA_STAGING_PORT }}
ssh_user: ${{ secrets.KINSTA_STAGING_USER }}
deploy_path: /www/sitename_1/public
- branch: main
ssh_host: ${{ secrets.KINSTA_PRODUCTION_HOST }}
ssh_port: ${{ secrets.KINSTA_PRODUCTION_PORT }}
ssh_user: ${{ secrets.KINSTA_PRODUCTION_USER }}
deploy_path: /www/sitename_2/public
Los pasos de compilación de activos crean archivos JavaScript y CSS optimizados antes del despliegue. El flujo de trabajo utiliza npm ci en lugar de npm install para construcciones reproducibles basadas en tu archivo package-lock.json. El comando npm run build ejecuta tu script de compilación de producción definido en package.json, normalmente ejecutando Vite u otro bundler para compilar y minificar activos.
En este punto, puedes añadir la instalación de Composer después de los pasos de Node.js:
- name: Setup PHP
uses: server/setup-php@v2
with:
php-version: '8.3'
- name: Install Composer dependencies
run: composer install --no-dev --optimize-autoloader --no-interaction
El flujo de trabajo tiene ahora los activos compilados y las dependencias instaladas, listos para su despliegue en Kinsta.
Detalles del script de despliegue
La sincronización de archivos a través de rsync sólo transfiere los archivos modificados, minimizando el tiempo de despliegue. Para solucionar esto, añade este paso a tu flujo de trabajo de GitHub Actions después de compilar tus activos:
- name: Deploy to Kinsta via rsync
env:
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
run: |
mkdir -p ~/.ssh
echo "$SSH_PRIVATE_KEY" > ~/.ssh/deploy_key
chmod 600 ~/.ssh/deploy_key
rsync -avz --delete
--exclude='.git'
--exclude='node_modules'
--exclude='.env'
--exclude='trellis'
-e "ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no"
./ ${{ matrix.ssh_user }}@${{ matrix.ssh_host }}:${{ matrix.deploy_path }}/releases/$(date +%Y%m%d%H%M%S)/Las banderas rsync controlan el comportamiento de la transferencia:
-aactiva el modo de archivo preservando los permisos y las marcas de tiempo.-vproporciona una salida detallada para la depuración.-zcomprime los datos durante la transferencia.
La bandera --delete elimina del servidor los archivos que ya no existen en tu repositorio, lo que mantiene limpio tu despliegue.
Los patrones de exclusión evitan la transferencia de archivos innecesarios. Además, los metadatos Git, las dependencias de desarrollo, los archivos de entorno y las herramientas de despliegue permanecen fuera del servidor de producción. La estructura de directorios de lanzamiento crea directorios con fecha y hora para cada despliegue, para permitir una rápida reversión cambiando los enlaces simbólicos.
La gestión de enlaces simbólicos conecta tus datos persistentes a cada nueva versión. Tras sincronizar los archivos, puedes acceder por SSH al servidor y crear enlaces simbólicos:
- name: Create symlinks and update current
run: |
ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no
${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
cd ${{ matrix.deploy_path }}
# Link shared .env file
ln -nfs ${{ matrix.deploy_path }}/shared/.env
${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/.env
# Link uploads directory
ln -nfs ${{ matrix.deploy_path }}/shared/public/content/uploads
${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/public/content/uploads
# Update current symlink atomically
ln -nfs ${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)
${{ matrix.deploy_path }}/current
EOFEl archivo .env contiene la configuración específica de cada entorno y se mantiene entre despliegues.
Los archivos subidos que se almacenan fuera del directorio de la versión evitan la pérdida de contenido multimedia cuando se eliminan lanzamientos antiguos. La actualización atómica del symlink (ln -nfs) garantiza cero interrupciones, ya que las solicitudes nunca apuntan a una versión a medio desplegar.
La limpieza elimina las versiones antiguas después de un despliegue correcto para conservar sólo las cinco más recientes:
- name: Clean up old releases
run: |
ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no
${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
cd ${{ matrix.deploy_path }}/releases
ls -t | tail -n +6 | xargs rm -rf
EOFEsta estrategia de limpieza logra un equilibrio entre la utilización del espacio en disco y la capacidad de reversión. Cinco versiones proporcionan varios puntos de reversión a la vez que evitan un crecimiento indefinido del almacenamiento.
Resumen
Radicle transforma el desarrollo de WordPress al integrar la estructura mejorada de Bedrock, el moderno flujo de trabajo de temas de Sage y las funcionalidades de Laravel de Acorn en un solo stack.
El despliegue en Kinsta requiere una configuración más allá del alojamiento para WordPress estándar, pero ofrece ventajas en materia de seguridad, facilidad de mantenimiento y experiencia de desarrollo que justifican el esfuerzo de configuración.
Cuando estés listo para desplegar aplicaciones modernas de WordPress con confianza, explora el alojamiento administrado para WordPress de Kinsta y experimenta una infraestructura de alojamiento compatible con el flujo de trabajo de desarrollo personalizado que desees.
