Automatiza el archivo de distribución de tus plugins y temas en WordPres

Hace un tiempo conté en la WordCamp Madrid cómo generar el ZIP de distribución de un plugin con WP-CLI, y lo dejé escrito en Crea el archivo de distribución de tu plugin con wp-cli. Ahí está la base: el comando wp dist-archive, el .distignore y por qué no deberías subir a producción un ZIP hecho a mano.

Bueno, pues el siguiente paso es no escribir el comando nunca más. Cuando mantienes cientos de plugins y temas, la parte tediosa no es el comando en sí, es acordarse de todo lo que va alrededor: entrar en la carpeta, quitar las dependencias de desarrollo de Composer, generar el ZIP con el nombre correcto, dejarlo en la carpeta compartida y volver a poner las dependencias para seguir trabajando. Son cinco pasos que siempre haces igual, así que se pueden meter en una función y olvidarte.

Lo que necesitas antes de empezar

Tres cosas, y las tres se instalan en un rato.

WP-CLI. Si aún no lo tienes, en Mac lo más cómodo es con Homebrew:

brew install wp-cli

El paquete dist-archive. No viene de serie en WP-CLI, hay que instalarlo aparte:

wp package install wp-cli/dist-archive-command

Composer. Solo lo vas a necesitar si tus plugins tienen dependencias, pero conviene tenerlo:

brew install composer

Para comprobar que todo está en su sitio:

wp --info
wp dist-archive --help
composer --version

¿Dónde meto la función? Depende de tu shell

Aquí es donde mucha gente se atasca, porque copia el código en el archivo equivocado y luego no le funciona nada. La cosa es sencilla: depende de qué shell uses.

Desde macOS Catalina, el shell por defecto es zsh. Antes era bash. Si llevas años con el mismo Mac arrastrando configuraciones, puedes tener las dos cosas a medias. Para salir de dudas:

echo $SHELL

Si te devuelve /bin/zsh, tu archivo es ~/.zshrc. Si te devuelve /bin/bash, es ~/.bash_profile.

Otra forma de verlo, que te dice el shell que está corriendo ahora mismo:

echo $0

Y si quieres ver qué archivos de configuración tienes ya creados en tu carpeta de usuario:

ls -la ~ | grep -E ".(zshrc|bashrc|bash_profile|zprofile)"

Un par de matices que ahorran disgustos:

• ~/.zshrc se carga en cada terminal interactiva de zsh. Es el sitio natural para alias y funciones.
• ~/.bash_profile se carga en shells de login de bash; ~/.bashrc, en las interactivas. En Mac lo habitual es usar .bash_profile y, si tienes .bashrc, cargarlo desde ahí con source ~/.bashrc.
• Si el archivo no existe, lo creas y ya está: touch ~/.zshrc.

Mi recomendación: si estás en un Mac moderno, olvídate de bash y trabaja con ~/.zshrc. Y si compartes configuración entre máquinas con bash y zsh, mete la función en un archivo aparte tipo ~/.wp-functions.sh y cárgalo desde los dos con source ~/.wp-functions.sh.

La función

Esta es la que uso a diario. Va tal cual en ~/.zshrc (o en ~/.bash_profile si sigues en bash):

# Distribution Plugin WordPress.
unalias wdis 2>/dev/null
function wdis {
        local dir="${1:-.}"
        local out_dir="$HOME/plugins"

        if [ -f "$dir/composer.json" ]; then
                composer install --no-dev --working-dir="$dir" && \
                wp dist-archive "$dir" "$out_dir" --filename-format={name}-{version} && \
                composer install --working-dir="$dir"
        else
                wp dist-archive "$dir" "$out_dir" --filename-format={name}-{version}
        fi
}

Vamos a explicarlo por partes, que hay más chicha de la que parece.

unalias wdis 2>/dev/null borra un posible alias antiguo con ese mismo nombre antes de declarar la función. Si alguna vez tuviste alias wdis=... en el archivo, el alias gana a la función y te vuelves loco buscando por qué no coge los cambios. El 2>/dev/null es para que no te grite si el alias no existe.

local dir="${1:-.}" coge el primer argumento que le pases y, si no le pasas ninguno, usa la carpeta actual. Es decir, puedes ejecutar wdis estando dentro del plugin, o wdis ~/proyectos/mi-plugin desde donde sea.

out_dir es la carpeta donde caen los ZIP. En mi caso, una carpeta de Google Drive que se sincroniza sola, así que en cuanto genero el archivo ya está disponible para el resto del equipo. Cámbiala por la tuya. Ojo con las comillas: la ruta tiene espacios y sin comillas se rompe.

El if comprueba si hay composer.json. Si lo hay, instala las dependencias sin las de desarrollo --no-dev), genera el ZIP y vuelve a instalarlas todas para que puedas seguir trabajando con PHPUnit, PHPCS y compañía. Los && encadenan: si algo falla por el camino, no sigue. Eso evita el escenario feo de generar un ZIP a medias.

--filename-format={name}-{version} deja el archivo como mi-plugin-1.4.2.zip, leyendo la versión de la cabecera del plugin. Para temas hace lo mismo pero leyendo el Version del style.css, así que la función te vale igual sin tocar nada.

Después de guardar, recarga la configuración:

source ~/.zshrc

Y a partir de ahí:

cd ~/proyectos/mi-plugin
wdis

O directamente desde cualquier sitio:

wdis ~/proyectos/mi-tema

Errores comunes

*wdis: command not found.** No has recargado la configuración. Ejecuta source ~/.zshrc o abre una terminal nueva. Si sigue igual, comprueba que has editado el archivo correcto con echo $SHELL.

*'dist-archive' is not a registered wp command.** Falta el paquete: wp package install wp-cli/dist-archive-command. Pasa a menudo cuando reinstalas WP-CLI, porque los paquetes no se arrastran.

El ZIP se genera pero le faltan archivos, o le sobran. Revisa el .distignore del proyecto. Sin .distignore, WP-CLI usa el .gitignore, y eso a veces excluye cosas que sí necesitas en producción, como el vendor de Composer.

Errores raros con la ruta de destino. Si la carpeta tiene espacios, tiene que ir entre comillas en todos los sitios. Y si no existe, créala antes: mkdir -p "$HOME/plugins".

Composer se queja de la versión de PHP. El composer install --no-dev usa el PHP de tu sistema, que puede no ser el mismo que el del servidor. Si te da problemas, añade --ignore-platform-reqs o configura platform en el composer.json del proyecto.

El archivo tarda en aparecer para los demás. Si guardas en Google Drive o Dropbox, la sincronización tiene su ritmo. No mandes el enlace hasta que el icono te diga que está subido.

Un apunte final

Para mí es la forma más segura de realizar un control de versiones de nuestro desarrollo en WordPress. Teniendo los diferentes plugins con sus versiones en un ZIP fácil de subir y reemplazar, garantiza la subida a producción y además va limpio de todos los archivos de desarrollo.

También si vendes dichos plugins, facilitar el zip con su versión facilita mucho al usuario para saber qué está instalando.

Si quieres con más detalle como creo los archivos .distignore para crear ZIP limpios, puedes verlo en la charla que comenté.