Flujo de trabajo moderno de desarrollo de WordPress con Roots Stack

WordPress existe desde hace mucho tiempo, al menos según los estándares de Internet, y su filosofía siempre ha sido preservar la compatibilidad con versiones anteriores. Este enfoque en la compatibilidad es comprensible dada la gran cantidad de sitios web de WordPress en línea en la actualidad. Sin embargo, si bien esto puede ayudar a aquellos que aún usan entornos heredados con versiones antiguas de PHP y MySQL (que es un riesgo de seguridad en sí mismo, pero este no es el tema del artículo de hoy), también provocó que las versiones más nuevas de WordPress no hicieran un uso completo de las últimas capacidades de PHP.

Esto también ha provocado que muchos desarrolladores de WordPress vivan en una burbuja de WordPress, sin incentivos para aprender tecnologías de desarrollo front-end nuevas y modernas y, a veces, se quedan atascados en la "buena manera" de hacer las cosas.

¿Puede adoptar un flujo de trabajo de desarrollo moderno para WordPress?

Ciertamente puede, y la pila de raíces de WordPress está aquí para ayudarlo a desarrollarse como si fuera 2019, con tres herramientas increíbles:

• Sage como tema de inicio,
• Bedrock como un modelo moderno de WordPress,
• Trellis para administrar la implementación y el aprovisionamiento en diferentes entornos.

El equipo de Roots también tiene dos herramientas adicionales en desarrollo: Acorn, un marco de construcción de complementos, y Clover, un modelo de complemento. Debido al hecho de que ambos están en alfa, no están incluidos en este artículo, pero definitivamente deberías vigilarlos.

¿Qué es exactamente la pila de raíces?

Originalmente conocido como el tema Roots, era un tema de inicio HTML5 sólido como una roca destinado a proporcionar un punto de partida más limpio para los nuevos sitios web de WordPress. Con el tiempo, evolucionó hasta convertirse en un conjunto completo de herramientas, pasando por todas las principales tecnologías y estándares web modernos (desde Grunt hasta Gulp y Webpack, LESS y SCSS, NPM e Yarn, Bootstrap, estándares de codificación PSR-2 y el principio DRY), obligando así a los desarrolladores de WordPress que lo adoptaron a aprender continuamente y mantenerse actualizados con lo que las tecnologías modernas de desarrollo front-end tienen para ofrecer.

Hoy, Roots se convirtió en un conjunto completo de herramientas en expansión continua, con el objetivo de ayudarlo a crear mejores sitios de WordPress siguiendo el ciclo completo, desde el desarrollo hasta la puesta en escena y la producción, y convirtiéndolo en un mejor desarrollador al obligarlo a salir de la comodidad. zona proporcionada por la llamada burbuja de WordPress.

Pero echemos un vistazo a las tres herramientas principales que ofrecen, qué son y por qué debería considerar usarlas.

Raíces de salvia 9

Roots Sage 9 es la última iteración de un tema de inicio de WordPress mantenido profesionalmente, lanzado originalmente como solo Roots en 2011. Durante su vida, ha pasado por muchos cambios, mejoras y reconsideraciones de las mejores prácticas, para finalmente convertirse en lo que hoy es un excelente punto de partida para presentar un flujo de trabajo de desarrollo front-end moderno para el desarrollo de WordPress.

Lo que Sage está tratando de hacer es adoptar un patrón MVC (Modelo-Vista-Controlador) donde las Vistas y el Controlador están completamente separados; esto nos permite reutilizar Vistas, que no necesariamente necesitan "saber" de dónde provienen los datos, sino que simplemente esperan a que un Controlador les proporcione algunos datos para mostrar.

El controlador incluido con Sage 9 no es el controlador real con el que quizás ya esté familiarizado en otros marcos como Laravel, la principal diferencia es que Sage 9 Controller utiliza un enrutamiento basado en plantillas en lugar de un enrutamiento basado en URL. Básicamente, dejas que WordPress maneje el enrutamiento de URL y escribes controladores para archivos de plantilla.

Al agregar algunos grados de complejidad a todo el proceso de desarrollo, es posible que Sage 9 no sea la mejor opción para principiantes, ya que tendrás que aprender bastante para dominarlo y poder usarlo en producción: gestión de dependencias y activos, control de versiones de código, una nueva estructura de proyecto, un nuevo motor de plantillas derivado de Laravel, el principio DRY (Don't Repeat Yourself), y tendrá que ceñirse a estrictos estándares de codificación que son un poco diferentes de lo que WordPress recomienda; pero si es un desarrollador experimentado, puede ser una gran ventaja.

Si quiere apostar todo con Sage, tenga en cuenta este consejo de Ben Word, uno de los desarrolladores del equipo de Roots:

Sage no es un marco temático, es un tema de inicio. Rara vez debería necesitar actualizarlo y, por lo general, no debería crear temas secundarios a partir de él. Al ser un tema de inicio, Sage está destinado a usarse como punto de partida en un nuevo proyecto.

Pero también:

Si Underscores es una ventaja inicial de 1000 horas, Sage es una ventaja inicial de 10 000 horas.

Estructura de archivos y carpetas con Sage

La estructura de archivos y carpetas de Sage es un poco diferente a lo que estamos acostumbrados a ver en otros temas de inicio como guiones bajos, o incluso en la versión principal anterior de Sage 8.

Esto es lo que encontrarás justo después de instalar Sage:

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

Además, algunos otros archivos utilizados por editores de código e IDE, como .editorconfig, .eslintrc.js, .stylelintrc.js, phpcs.xml, etc.

Aquí hay una descripción general rápida de los requisitos básicos de Sage 9:

• WordPress >= 4.7
• PHP >= 7.1.3 (con php-mbstring habilitado)
• Compositor
• Nodo.js >= 8.0.0
• Hilo

Base

¡Bedrock es como WordPress con esteroides!

Si Sage mejora el desarrollo de su tema, Bedrock mejora toda la instalación de WordPress. Lo hace al proporcionar un modelo de proyecto moderno , con una estructura de carpetas y seguridad mejoradas (por ejemplo, al no tener sus archivos de configuración en la raíz del sitio web), archivos de configuración y ENV, y una gestión de dependencia adecuada (sí, incluidos los complementos y temas de WordPress) .

Para describirlo en una sola frase, podríamos decir que Bedrock es un proyecto de WordPress autónomo que automatiza la instalación de los archivos principales y los complementos necesarios.

Estructura de archivos y carpetas

Si observa una instalación básica de Bedrock, es posible que se sienta perdido al principio. Bedrock separa los archivos web, de configuración y de dependencia en sus propias carpetas. Así es como se ve la estructura ósea desnuda:

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

Además de algunos otros archivos menos importantes.

Los requisitos del lecho rocoso son:

• PHP >= 7.1
• Compositor

Conducción

Trellis es una pila LEMP moderna para administrar sus servidores de desarrollo, preparación y producción sin problemas, con el objetivo de mantenerlos lo más similares posible ("paridad de desarrollo y producción"). Esto significa que si su sitio personalizado de WordPress funciona en su entorno de desarrollo, es seguro asumir que también funcionará en producción y que puede implementarlo con confianza.

Para el desarrollo local, Trellis hace uso de Vagrant, con un simple vagrant up tendrá una máquina virtual que ejecuta un entorno moderno adecuado.

El aprovisionamiento y la implementación en sus entornos de ensayo y producción se administran con libros de jugadas de Ansible, que son archivos YAML que le indican a Ansible qué hacer.

Estructura de carpetas sugerida por Trellis

Trellis tiene una estructura de carpetas sugerida compuesta de solo dos subcarpetas:

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

Recomendaría dejarlo como está, pero se puede personalizar según sus gustos y necesidades.

Requisitos del enrejado

• Compositor
• Caja virtual >= 4.3.10
• Vagabundo >= 2.1.0

Por qué debería usarlo

Si WordPress ya funciona como está, ¿por qué debería cambiar a una pila más compleja y dedicar una cantidad considerable de tiempo a dominarla? Porque hay ventajas obvias y otras menos obvias. Intentemos ver cuáles son.

Un tema de inicio agnóstico de Framework

Demasiados temas de inicio de WordPress lo obligan a usar un marco CSS específico que puede gustarle o no o incluso conocerlo, pero Sage es completamente independiente del marco. Durante la instalación, tendrá la opción de incluir automáticamente Bootstrap 4, Bulma, Foundation, Tachyons, Tailwind CSS o ningún marco si desea comenzar desde cero o usar algo más (PISTA: últimamente me está empezando a gustar Tailwind CSS mucho).

SUGERENCIA PROFESIONAL: en una máquina Windows, es posible que reciba el mensaje "El modo TTY no es compatible con la plataforma Windows" durante la instalación y no podrá elegir un marco ni configurar Sage. Deberá ejecutar estos tres comandos manualmente desde la carpeta del tema si desea aprovechar la configuración automática:

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

Un proceso de construcción moderno

Con Webpack, incluido en Sage, no tendrá que pensar más en compilar activos, concatenar y minimizar código JavaScript y CSS, optimizar imágenes, verificar errores de estilo y JavaScript y administrar bibliotecas externas. El proceso de compilación se encargará de todo eso con una compilación de yarn build simple (o yarn build:production si desea que sus activos estén optimizados para uso en producción), produciendo todos los archivos estáticos en su carpeta de tema /dist/ .

PHP moderno y requisitos

La versión mínima de PHP en la que puede ejecutar WordPress es PHP 5.2.4, esto garantizará la compatibilidad con versiones anteriores para todos aquellos usuarios que ejecutan sus sitios web en un entorno heredado, pero las versiones antiguas de PHP (<= 7.0) han llegado oficialmente al final de Life, por lo que ya no son compatibles y pueden exponer su sitio a vulnerabilidades de seguridad y problemas de rendimiento.

Tanto Sage como Bedrock requieren una versión sana de PHP 7.1 (aunque si tiene la opción de elegir 7.3, hágalo).

Sage 9 también adopta completamente los estándares de codificación PSR-2 (la codificación más utilizada y aceptada).

estándares utilizados en la comunidad PHP), que son un poco diferentes de los estándares de codificación de WordPress, pero le permiten tener un código más limpio y fácil de mantener, especialmente si trabaja en equipo o tiene que compartir su código con otros.

Mejor administración de dependencias y paquetes

La pila de Roots hace un gran uso de Composer para administrar todas las dependencias y paquetes, incluidos el núcleo, los complementos y los temas de WordPress. Esto podría ser un problema si usa herramientas de terceros para administrar las actualizaciones de WordPress (como ManageWP, MainWP o InfiniteWP), pero alguien podría argumentar que tener todo bajo el control de versiones le brinda más control y facilita la reversión a un trabajo anterior. versión si algo sale mal.

Además, Sage usa Yarn como administrador de paquetes y dependencias para el código de la aplicación y para iniciar el proceso de compilación.

Mejores archivos de plantilla

WordPress carece de un motor de plantillas real, así que para compensarlo, Sage adoptó Laravel's Blade y sigue el principio DRY: Don't Repeat Yourself.

Así es como se ve el archivo de plantilla predeterminado single.blade.php, solo 6 líneas de código:

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

El motor de plantillas Blade separa completamente las Vistas y los Controladores y su sintaxis es más elegante, concisa, legible y más fácil de escribir que las etiquetas de PHP. La regla general aquí es dejar todo el código PHP fuera de los archivos de plantilla (o al menos intentarlo).

Otro beneficio de usar Blade es la herencia de plantillas: una plantilla de diseño base (la predeterminada es /resources/views/layouts/app.blade.php ) define bloques que contienen los elementos comunes del sitio web, que luego son heredados por sus plantillas secundarias. La herencia de plantillas es excelente para eliminar el marcado repetido de plantillas individuales y mantener las cosas SECAS.

sincronización del navegador

Al ejecutar yarn start , iniciará una sesión de Browsersync. Browsersync es un módulo para la prueba sincronizada del navegador durante el desarrollo. Observará los cambios realizados en sus activos front-end y, trabajando junto con Webpack, inyectará automáticamente los cambios en la sesión de su navegador.

Implementación de WordPress rápida, fácil y segura

Trellis ofrece implementaciones de WordPress sin tiempo de inactividad. Cuando inicie una implementación, Trellis clonará su repositorio, ejecutará composer install y luego actualizará el enlace simbólico a la versión actual para que nunca edite directamente los archivos que se sirven actualmente en producción.

Al usar Bedrock, Trellis también necesita muy poca configuración.

inconvenientes

El único inconveniente de usar la pila Roots completa (aparte de aprender cosas nuevas, que no debería considerarse un problema en absoluto) es que debe usar un proveedor de alojamiento compatible con Trellis como Kinsta, un droplet de DigitalOcean o cualquier otro host que admitir al menos SSH, Composer y WP-CLI, junto con la opción de actualizar la ruta raíz web.

Esto deja fuera del juego a la mayor parte del alojamiento compartido barato (ish) y es algo que usted y/o su cliente deben tener en cuenta antes de comenzar un nuevo proyecto.

Cómo empezar

Esto se puede considerar como una nueva versión de la famosa "Instalación de 5 minutos de WordPress", pero para los desarrolladores front-end modernos. Agrega algunos grados de complejidad para el desarrollo posterior, pero al final, los beneficios que puede obtener definitivamente valen la pena.

Nos centraremos en adoptar la pila completa (Sage, Bedrock y Trellis), pero puede usar solo uno o cualquier combinación de ellos. Sage se puede utilizar como punto de partida para un tema independiente en cualquier instalación de WordPress; Bedrock se puede usar con cualquier tema de WordPress que desee; y las implementaciones de Trellis están configuradas para sitios basados ​​en Bedrock y se encargan de todo lo necesario, pero con un poco de ajuste, se puede personalizar para casi cualquier necesidad.

Cómo crear un proyecto nuevo

Configurar un nuevo proyecto de WordPress con Trellis, Bedrock y Sage es bastante fácil, con solo unas pocas líneas de comando.

Instale Trellis en la carpeta que desee (p. ej., example.com ):

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

Instale Bedrock en la subcarpeta /site/ :

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Instalar y compilar Sage:

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

Desplegando

La implementación en escenarios o producción es aún más fácil si ha configurado todo correctamente de acuerdo con la documentación oficial. Está a solo una línea de comando de distancia (se ejecutó desde la carpeta example.com/trellis/ ):

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

También puede revertir fácilmente su implementación, simplemente ejecute:

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Sugerencias sobre la configuración de su entorno de desarrollo en Windows

Si busca en Google cómo instalar y usar la pila Roots, especialmente Trellis, encontrará muchos tutoriales enfocados en Linux o MacOS, pero hay muy poca información disponible para Windows donde encontrará dos problemas principales: Ansible no está disponible para Windows, y Vagrant suele ser extremadamente lento en máquinas con Windows.

Cuando originalmente pensé en este artículo, la documentación oficial de Trellis para Windows sugería ejecutar Ansible dentro de la máquina virtual Vagrant, pero esta era una forma un tanto extraña de hacer las cosas y no era muy confiable.

Desde entonces, han actualizado la documentación con las instrucciones adecuadas sobre cómo configurar todo con WSL (Subsistema de Windows para Linux), por lo que no es necesario reinventar la rueda y escribir un tutorial al respecto. Es bueno saber que hay tres páginas de instrucciones detalladas paso a paso que puede seguir antes de instalar Trellis: Configuración de Windows, Configuración de Windows: Sage y Configuración de Windows: Trellis.

¡Feliz codificación!