Creación de múltiples sitios de WordPress localmente con DevKinsta

Este artículo ha sido amablemente apoyado por nuestros queridos amigos de DevKinsta que ayudan a tantos desarrolladores, diseñadores web y autónomos a diseñar, desarrollar e implementar sus sitios web de WordPress de todo el mundo. ¡Gracias!

Al crear temas y complementos para WordPress, debemos asegurarnos de que funcionen bien en todos los diferentes entornos donde se instalarán. A veces podemos controlar este entorno cuando creamos un tema para nuestros propios sitios web, pero otras veces no podemos, como cuando distribuimos nuestros complementos a través del repositorio público de WordPress para que cualquiera pueda descargarlo e instalarlo.

Con respecto a WordPress, las posibles combinaciones de entornos de las que debemos preocuparnos incluyen:

• Diferentes versiones de PHP,
• Diferentes versiones de WordPress,
• Diferentes versiones del editor de WordPress (también conocido como el editor de bloques),
• HTTPS activado/desactivado,
• Multisitio habilitado/deshabilitado.

Veamos cómo es este el caso. PHP 8.0, que es la última versión de PHP, ha introducido cambios importantes con respecto a las versiones anteriores. Dado que WordPress aún admite oficialmente PHP 5.6, es posible que nuestro complemento deba admitir 7 versiones de PHP: PHP 5.6, más PHP 7.0 a 7.4, más PHP 8.0. Si el complemento requiere alguna característica específica de PHP, como propiedades escritas (introducidas en PHP 7.4), entonces deberá ser compatible con esa versión de PHP en adelante (en este caso, PHP 7.4 y PHP 8.0).

Con respecto al control de versiones en WordPress, este software en sí mismo puede ocasionalmente introducir cambios importantes, como la actualización a una versión más nueva de jQuery en WordPress 5.6. Además, cada versión importante de WordPress presenta nuevas funciones (como el nuevo editor Gutenberg, introducido en la versión 5.0), que podrían ser necesarias para nuestros productos.

El editor de bloques no es una excepción. Si nuestros temas y complementos contienen bloques personalizados, es imperativo probarlos para todas las versiones diferentes. Como mínimo, debemos preocuparnos por dos versiones de Gutenberg: la que se envía en el núcleo de WordPress y la que está disponible como complemento independiente.

Con respecto a HTTPS y multisitio, nuestros temas y complementos podrían comportarse de manera diferente dependiendo de si están habilitados o no. Por ejemplo, es posible que deseemos deshabilitar el acceso a un punto final REST cuando no se usa HTTPS o proporcionar capacidades extendidas al superadministrador desde el multisitio.

Esto significa que hay muchos entornos posibles de los que debemos preocuparnos. ¿Cómo lo manejamos?

Averiguar los entornos

Todo lo que se pueda automatizar, se debe automatizar. Por ejemplo, para probar la lógica de nuestros temas y complementos, podemos crear un proceso de integración continua que ejecute un conjunto de pruebas en múltiples entornos. La automatización elimina una gran parte del dolor.

Sin embargo, no podemos confiar en que las máquinas hagan todo el trabajo por nosotros. También necesitaremos acceder a algún sitio de prueba de WordPress para visualizar si, después de alguna actualización de software, nuestros temas aún se ven como se esperaba. Por ejemplo, si Gutenberg actualiza su sistema de estilos globales o cómo se comporta un bloque central, queremos verificar que nuestros productos no se hayan visto afectados por el cambio.

¿Cuántos entornos diferentes necesitamos soportar? Digamos que apuntamos a 4 versiones de PHP (7.2 a 8.0), 5 versiones de WordPress (5.3 a 5.7), 2 versiones de Gutenberg (núcleo/complemento), HTTPS activado/desactivado y multisitio activado/desactivado. Todo asciende a un total de 160 entornos posibles. Eso es demasiado para manejar.

Para simplificar las cosas, en lugar de producir un sitio para cada combinación posible, podemos reducirlo a un puñado de entornos que, en general, comprenden todas las diferentes propiedades.

Por ejemplo, podemos producir estos cinco entornos:

1. PHP 7.2 + WP 5.3 + núcleo de Gutenberg + HTTPS + multisitio
2. PHP 7.3 + WP 5.4 + complemento de Gutenberg + HTTPS + multisitio
3. PHP 7.4 + WP 5.5 + complemento de Gutenberg + sin HTTPS + sin multisitio
4. PHP 8.0 + WP 5.6 + Gutenberg core + HTTPS + sin multisitio
5. PHP 8.0 + WP 5.7 + Gutenberg core + sin HTTPS + sin multisitio

Activar 5 sitios de WordPress es manejable, pero no es fácil, ya que implica desafíos técnicos, en particular, habilitar diferentes versiones de PHP y proporcionar certificados HTTPS.

Queremos hacer funcionar los sitios de WordPress fácilmente, incluso si tenemos un conocimiento limitado de los sistemas. Y queremos hacerlo rápido ya que tenemos que hacer nuestro trabajo de desarrollo y diseño. ¿Como podemos hacerlo?

Administrar sitios locales de WordPress con DevKinsta

Afortunadamente, hoy en día no es difícil hacer funcionar sitios locales de WordPress, ya que podemos evitar el trabajo manual y, en cambio, depender de una herramienta que automatice el proceso por nosotros.

DevKinsta es exactamente este tipo de herramienta. Permite lanzar un sitio local de WordPress con el mínimo esfuerzo, para cualquier configuración deseada. El sitio se creará en menos tiempo que se tarda en tomar una taza de café. Y ciertamente cuesta menos que una taza de café: DevKinsta es 100 % gratuito y está disponible para usuarios de Windows, macOS y Ubuntu .

Como sugiere su nombre, DevKinsta fue creado por Kinsta, uno de los principales proveedores de alojamiento en el espacio de WordPress. Su objetivo es simplificar el proceso de trabajo con proyectos de WordPress, ya sea para diseñadores o desarrolladores, autónomos o agencias. Cuanto más fácil podamos configurar nuestro entorno, cuanto más podamos centrarnos en nuestros propios temas y complementos, mejores serán nuestros productos.

La magia que impulsa a DevKinsta es Docker, el software que permite aislar una aplicación de su entorno a través de contenedores. Sin embargo, no estamos obligados a saber acerca de Docker o contenedores: DevKinsta oculta la complejidad subyacente, por lo que podemos iniciar el sitio de WordPress con solo presionar un botón.

En este artículo, exploraremos cómo usar DevKinsta para lanzar las 5 instancias locales diferentes de WordPress para probar un complemento y qué características interesantes tenemos a nuestra disposición.

Lanzar un sitio de WordPress con DevKinsta

Las imágenes de arriba muestran a DevKinsta al abrirlo por primera vez. Presenta 3 opciones para crear un nuevo sitio local de WordPress:

1. Nuevo sitio de WordPress
   Utiliza la configuración predeterminada, incluida la última versión de WordPress y PHP 8.
2. Importar desde Kinsta
   Clona la configuración de un sitio existente alojado en MyKinsta.
3. sitio personalizado
   Utiliza una configuración personalizada, proporcionada por usted.

Presionar la opción #1 literalmente producirá un sitio local de WordPress sin siquiera pensarlo. Podría explicar un poco más si pudiera; realmente no hay más que eso.

Si es un usuario de Kinsta, al presionar la opción n. ° 2, podrá importar directamente un sitio desde MyKinsta, incluido un volcado de su base de datos. (Por cierto, también funciona en la dirección opuesta: los cambios locales en DevKinsta se pueden enviar a un sitio de prueba en MyKinsta).

Finalmente, al presionar la opción #3, podemos especificar qué configuración personalizada usar para el sitio local de WordPress.

Presionemos el botón para la opción #3. La pantalla de configuración se verá así:

Algunas entradas son de solo lectura. Estas son opciones que actualmente están arregladas pero que se podrán configurar en algún momento en el futuro. Por ejemplo, el servidor web actualmente está configurado en Nginx, pero se está trabajando para agregar Apache.

Las opciones que podemos configurar actualmente son las siguientes:

• El nombre del sitio (a partir del cual se calcula la URL local),
• versión PHP,
• Nombre de la base de datos,
• HTTPS activado/desactivado,
• El título del sitio de WordPress,
• versión de WordPress,
• El correo electrónico, nombre de usuario y contraseña del administrador,
• Multisitio habilitado/deshabilitado.

Después de completar esta información para mi primer sitio local de WordPress, llamado "API GraphQL en PHP 80", y hacer clic en "Crear sitio", DevKinsta solo tardó 2 minutos en crear el sitio. Luego, se me presenta la pantalla de información para el sitio recién creado:

El nuevo sitio de WordPress está disponible bajo su propio dominio local graphql-api-on-php80.local . Al hacer clic en el botón "Abrir sitio", podemos visualizar nuestro nuevo sitio en el navegador:

Repetí este proceso para todos los diferentes entornos requeridos, y listo, mis 5 sitios locales de WordPress estuvieron listos y funcionando en muy poco tiempo. Ahora, la pantalla inicial de DevKinsta enumera todos mis sitios:

Usando WP-CLI

Desde la configuración requerida para mis entornos, hasta ahora he satisfecho todos los elementos excepto uno: instalar Gutenberg como complemento.

Hagamos esto a continuación. Podemos instalar un complemento de la forma habitual a través del administrador de WP, al que podemos acceder haciendo clic en el botón "Administrador de WP" desde la pantalla de información del sitio, como se ve en la imagen de arriba.

Aún mejor, DevKinsta viene con WP-CLI ya instalado, por lo que podemos interactuar con el sitio de WordPress a través de la interfaz de línea de comandos.

En este caso, necesitamos tener un conocimiento mínimo de Docker. La ejecución de un comando dentro de un contenedor se hace así:

 docker exec {containerName} /bin/bash -c '{command}'

Los parámetros necesarios son:

• El contenedor de DevKinsta se llama devkinsta_fpm .
• El comando WP-CLI para instalar y activar un complemento es wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
• La ruta al sitio de WordPress, dentro del contenedor, es /www/kinsta/public/{siteName} .

Poniendo todo junto, el comando para instalar y activar el complemento de Gutenberg en el sitio local de WordPress es este:

 docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'

Explorando funciones

Hay un par de funciones útiles disponibles para nuestros sitios locales de WordPress.

El primero es la integración con Adminer, una herramienta similar a phpMyAdmin, para gestionar la base de datos. Con esta herramienta, podemos obtener y editar directamente los datos a través de una consulta SQL personalizada. Al hacer clic en el botón "Administrador de base de datos", en la pantalla de información del sitio, se abrirá Adminer en una nueva pestaña del navegador:

La segunda característica a destacar es la integración con Mailhog, la popular herramienta de prueba de correo electrónico. Gracias a esta herramienta, cualquier correo electrónico enviado desde el sitio local de WordPress en realidad no se envía, sino que se captura y se muestra en la bandeja de entrada del correo electrónico:

Al hacer clic en un correo electrónico, podemos ver su contenido:

Acceso a los archivos de instalación local

Después de instalar el sitio local de WordPress, su carpeta que contiene todos sus archivos (incluido el núcleo de WordPress, los temas y complementos instalados y los elementos multimedia cargados) estará disponible públicamente:

• Mac y Linux: en /Users/{username}/DevKinsta/public/{siteName} .
• Windows: en C:\Users\{username}\DevKinsta\public\{siteName} .

(En otras palabras: se puede acceder a los archivos del sitio local de WordPress no solo a través del contenedor Docker, sino también a través del sistema de archivos en nuestro sistema operativo, como usar Mi PC en Windows, Finder en Mac o cualquier terminal).

Esto es muy conveniente ya que ofrece un atajo para instalar los temas y complementos que estamos desarrollando, acelerando nuestro trabajo.

Por ejemplo, para probar un cambio en un complemento en los 5 sitios locales, normalmente tendríamos que ir al administrador de WP en cada sitio y cargar la nueva versión del complemento (o, alternativamente, usar WP-CLI).

Sin embargo, al tener acceso a la carpeta del sitio, podemos simplemente clonar el complemento desde su repositorio, directamente en wp-content/plugins :

 $ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins $ git clone [email protected]:leoloso/MyAwesomePlugin.git

De esta manera, podemos simplemente git pull para actualizar nuestro complemento a su última versión, haciéndolo disponible de inmediato en el sitio local de WordPress:

 $ cd MyAwesomePlugin $ git pull

Si queremos probar el complemento en desarrollo en una rama diferente, podemos hacer una verificación de git checkout de manera similar:

 git checkout some-branch-with-new-feature

Dado que podemos tener varios sitios con diferentes entornos, podemos automatizar este procedimiento ejecutando un script bash, que itera los sitios locales de WordPress y, para cada uno, ejecuta un git pull para el complemento instalado dentro:

 #!/bin/bash iterateSitesAndGitPullPlugin(){ cd ~/DevKinsta/public/ for file in * do if [ -d "$file" ]; then cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin git pull fi done } iterateSitesAndGitPullPlugin

Conclusión

Al diseñar y desarrollar nuestros temas y complementos de WordPress, queremos poder concentrarnos en nuestro trabajo real, tanto como sea posible. Si podemos automatizar la configuración del entorno de trabajo, podemos invertir el tiempo y la energía adicionales en nuestro producto.

Esto es lo que DevKinsta hace posible. Podemos activar un sitio local de WordPress con solo presionar un botón y crear muchos sitios con diferentes entornos en solo unos minutos.

DevKinsta se está desarrollando y apoyando activamente. Si tiene algún problema o tiene alguna consulta, puede navegar por la documentación o dirigirse al foro de la comunidad, donde los creadores de DevKinsta lo ayudarán.

Todo esto, gratis. ¿Suena bien? Si es así, descargue DevKinsta y haga girar sus sitios locales de WordPress.