Cómo abordar el desarrollo moderno de WordPress (Parte 1)

No es ningún secreto que el código base de WordPress es un desastre. Personalmente, cada vez que paso por eso, lo único que quiero es acurrucarme y llorar. Por otro lado, WordPress está muy por delante de su competencia. Un CMS potente y fácil de usar es una empresa enorme, y WordPress sigue siendo popular porque ofrece esto.

Entonces, ¿por qué deberíamos preocuparnos por la calidad del código en el núcleo de WordPress? Funciona, ¿verdad?

Sí, funciona, y es poco probable que el código base de 15 años sea completamente refactorizado por sus mantenedores voluntarios. Desafortunadamente, esto significa que también funciona como un ejemplo de codificación "a la manera de WordPress", lo que excusa a numerosos desarrolladores por no seguir las mejores prácticas y técnicas de desarrollo modernas. Tantos complementos y temas de WordPress tienen un código infamemente malo, y seguir ciegamente las prácticas heredadas solo continúa la tendencia.

Pero, ¿a quién le importa el código malo que todavía hace su trabajo? Pues nada es gratis, y alguien paga por un trabajo mal hecho. Con el propio código base de WordPress, sus mantenedores pagan con su tiempo, afortunadamente. Pero con tu propio código, es tu cliente quien paga.

Para cualquier sistema moderadamente complejo, el costo del desarrollo inicial es insignificante en comparación con el costo de mantenimiento, y el mantenimiento también significa agregar nuevas funciones. Contratar a un desarrollador para que arregle un software mal diseñado e implementado costará varias veces más que desarrollarlo correctamente desde el principio.

Las soluciones baratas son siempre las más caras a largo plazo. O se abandonan después de quedarse sin presupuesto. De hecho, ahorramos dinero a los clientes cuando seguimos prácticas y principios de diseño de software probados. Estos métodos no son una moda exagerada, ni el cambio por cambiar. La sabiduría aquí nace de la experiencia colectiva de los desarrolladores, y seguirla realmente vale la pena.

Obviamente, esto no se aplica a tareas verdaderamente simples como agregar algunas líneas de CSS o un par de publicaciones personalizadas y reescrituras. Pero unir algunos complementos (o más comúnmente varias docenas de complementos) o producir un sitio impulsado por Visual Composer no es ingeniería de software, de todos modos.

Eso no es algo malo en sí mismo : el hecho de que algunas soluciones sean tan simples es la razón por la que WordPress es tan popular. Pero en esta serie hablaré sobre el desarrollo real de WordPress: escribir código PHP, HTML, CSS y JavaScript significativo. Comenzaré con el flujo de trabajo general y luego me centraré en el desarrollo front-end de WordPress en este artículo.

Flujo de trabajo moderno de desarrollo de WordPress

En general, el código de calidad es:

• Legible. Es fácil entender qué hace el código y por qué.
• Modular. Los pequeños bloques de código con un propósito claro son fáciles de entender, desarrollar y probar.
• Reutilizable. Reutilizar módulos ya desarrollados para resolver problemas similares acelera significativamente el desarrollo.
• Mantenible. Modificar la funcionalidad antigua o introducir nuevas características es fácil.

Los resultados principales (menor costo de desarrollo y propiedad) tienen muchos beneficios indirectos que no abordaré aquí.

En cambio, me centraré en qué técnicas de desarrollo y mejores prácticas pueden ayudarlo a producir código de calidad. Comencemos con el control de versiones.

Usar control de versiones

Esto significa usar Git. Lamentablemente, la "codificación de vaqueros" en la producción a través de FTP sigue siendo una cosa. Hace poco trabajé para una agencia con sede en el Reino Unido y tenían archivos con nombres como estos en todo su código base:

• functions copy.php
• functions copy 2.php
• functions test.php
• functions2.php
• functions test2.php

Lo primero que debe hacer al tomar un sitio de WordPress es ponerlo bajo control de versión. Tanking Servers es una divertida retrospectiva de los errores de desarrollo de WordPress. Habría sido muy fácil corregir esos, y percances similares que probablemente le han sucedido a todos, usando Git.

¿Cometió un error en su código y todo el sitio se cayó? git reset hace que todo vuelva a ser como era. ¿La actualización de la nueva versión rompió todo? git reset funciona como una máquina del tiempo. ¿Algún código malicioso apareció de la nada? git status muestra los archivos nuevos, los archivos eliminados o los cambios en los archivos rastreados. Luego, simplemente git checkout y restaura los originales.

Cuidado con exponer la carpeta .git

OK, es claramente importante usar Git. Pero cuando lo haga, es igual de importante evitar exponer su repositorio de Git a ser pirateado. El problema surge cuando tiene carpetas .git expuestas y almacena sus credenciales en ellas.

Una instalación estándar de WordPress vive completamente en una carpeta web pública, y es muy probable que la carpeta .git también esté allí. Obviamente, no se deben almacenar credenciales de inicio de sesión en el repositorio de Git, pero sucede que la mayoría de los repositorios contienen información confidencial que no se debe filtrar al exterior.

Por lo tanto, se debe bloquear el acceso público a la carpeta .git . Si está utilizando Apache, agregar el fragmento de código a continuación en la parte superior del archivo .htaccess bloqueará el acceso a la carpeta .git y también a los archivos de registro. Los archivos de registro a menudo contienen información confidencial, por lo que es aconsejable que tampoco estén disponibles. Para diferentes configuraciones de servidores web, solicite ayuda a su experto en DevOps.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Usar entornos separados

No haga desarrollo en sitios en vivo: esta es una receta para el tiempo de inactividad y los clientes insatisfechos. Bien, pero ¿cómo deberías configurarlo?

Idealmente, debería haber tres entornos de desarrollo, con el código siempre yendo en una dirección: local → puesta en escena → producción. Este es un método probado para evitar colisiones. Todas las actualizaciones de núcleo, complementos y temas se realizan primero localmente, luego se prueban en la etapa de preparación y finalmente se implementan en producción.

Por ejemplo, la configuración específica del servidor podría almacenarse en un archivo separado. Puede crear un wp-config-local.php para cada entorno local y de ensayo. (¡No olvide agregarlo a su archivo .gitignore !) Luego agregue el siguiente fragmento a wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

A menudo, la mejor manera de configurar diferentes entornos es utilizando variables de entorno. Si no está familiarizado con este concepto, le recomendaría utilizar una solución moderna completa como Roots.

Usar WP-CLI

La interfaz de línea de comandos de WordPress (WP-CLI) es una herramienta extremadamente útil para administrar las instalaciones de WordPress. Tener acceso a WP-CLI significa tener la capacidad de ejecutar prácticamente cualquier función API de WordPress. Por ejemplo, puede agregar, eliminar y editar usuarios y sus contraseñas con WP-CLI. Útil si acaba de heredar un sitio y el propietario se ha bloqueado.

Otro ejemplo es que la implementación inicial es muy sencilla con WP-CLI. Estos se pueden lograr con algunos comandos:

• Descarga de núcleo, temas y complementos
• Buscar y reemplazar en la base de datos
• Adición de un usuario administrador

Además, estas acciones pueden programarse y automatizarse.

Usar opciones de implementación avanzadas

Hablando de automatización, vale la pena aprender algunas tecnologías y procesos de implementación como:

• Integración continua/implementación/entrega continua (CI/CD)
• Estibador
• Pruebas automatizadas (incluidas las pruebas de regresión de front-end)

De acuerdo, pasar de no usar el control de versiones a lidiar con Docker es un gran salto y probablemente será abrumador para un proyecto típico de WordPress de una sola persona. Es posible que algunas opciones ni siquiera sean posibles dependiendo de su proveedor de alojamiento. Pero la implementación avanzada es imprescindible para equipos y proyectos más grandes.

Usar pelusa

Sin embargo, para proyectos de cualquier tamaño, el linting es una bendición para la mayoría de los desarrolladores. Linting significa verificar automáticamente su código en busca de errores. Un IDE con todas las funciones como PHPStorm ya lo hace listo para usar; sin embargo, los editores más simples como VSCode o Sublime Text necesitan un programa dedicado llamado linter. Una forma de configurar esto es configurar su editor para ejecutar un linter cada vez que guarde un archivo.

PHP_CodeSniffer es el filtro de facto para PHP. Además de verificar errores de sintaxis, también puede verificar si su código sigue pautas de estilo como PSR-2. Esto simplifica enormemente los siguientes estándares de codificación.

Para JavaScript, ESLint es un linter popular. Tiene un extenso conjunto de reglas y admite configuraciones personalizadas para todos los tipos y marcos de JavaScript que existen.

Un caso de uso poderoso aquí es la incorporación de linting en una canalización de compilación de CI/CD para que todo el código se valide automáticamente antes de implementarse.

Técnicas modernas de desarrollo front-end de WordPress

Con un flujo de trabajo adecuado ahora configurado para su proyecto general de WordPress, profundicemos en las mejores prácticas para el front-end.

Utilice herramientas modernas: Sass y ES6+

El mundo del desarrollo front-end está en constante cambio y siempre en movimiento. Una vez pensamos que Sass era la mejor herramienta para escribir CSS, y para el desarrollo de WordPress anterior a Gutenberg, todavía lo es, pero luego todos comenzaron a hablar sobre CSS-in-JS y componentes con estilo.

Incluso WordPress no pudo resistirse y recogió algunas de esas nuevas tecnologías. Gutenberg, el nuevo editor de bloques, se basa en React y una API REST.

Definitivamente deberías ponerte al día con estas tecnologías front-end básicas:

• ES6+. La documentación de WordPress lo llama ESNext e incluso recomienda usarlo.
• Hablar con descaro a. Utilizado por WooCommerce y la mejor manera de escribir CSS si aún no te gusta el CSS-in-JS.
• paquete web. Incluso el núcleo de WordPress usa Webpack y Babel ahora.

ES6 y Sass son JavaScript y CSS modernos, respectivamente, y Webpack es una herramienta que permite usar todas estas funciones modernas sin preocuparse por la compatibilidad con versiones anteriores. Webpack puede llamarse un compilador de aplicaciones front-end que genera archivos para usar en un navegador.

Transición de jQuery a Vue.js o React

El núcleo de WordPress y casi todos los complementos de WordPress dependen de jQuery, por lo que no puede dejar de usarlo. En realidad, no tiene sentido dejar de usarlo para tareas simples, como ocultar un par de <div> o realizar una solicitud AJAX única cuando está acostumbrado a hacerlo de esa manera. jQuery se cargará de todos modos, y es simple y fácil de usar.

Las aplicaciones complejas son donde jQuery lucha: lógica difícil de seguir, infierno de devolución de llamada, variables globales y sin plantillas HTML. Esto claramente requiere una forma diferente de organizar la aplicación de front-end.

Las bibliotecas front-end modernas, como React, utilizan principios de programación orientada a objetos (OOP) y organizan la arquitectura de la aplicación front-end en componentes modulares y reutilizables. Un componente contiene todo el código, el marcado y el "estado del componente" (variables) para un elemento en particular. Un elemento podría ser casi cualquier cosa: un botón, un campo de entrada, un formulario de usuario o un widget que muestre publicaciones recientes del back-end de la API REST de WordPress. Los componentes pueden contener otros componentes, formando una relación jerárquica.

Con la complejidad de las páginas web hoy en día, organizar una aplicación en componentes es una forma comprobada de crear aplicaciones web rápidas y mantenibles de cualquier complejidad. Los componentes son "ladrillos" altamente reutilizables, aislados y, por lo tanto, fáciles de probar, por lo que realmente vale la pena aprender este concepto.

Hay dos bibliotecas basadas en componentes que son tendencia en este momento: Vue.js y React. React sería una opción obvia porque Gutenberg ya lo usa. Sin embargo, para alguien nuevo en JavaScript moderno, Vue.js podría ser mejor para empezar.

React lo lleva al extremo profundo al usar las funciones, las clases, la sintaxis JSX propietaria y la canalización de compilación de Webpack de ES6 de inmediato. La curva de aprendizaje es bastante empinada.

Vue.js, por otro lado, es mucho más fácil de usar para principiantes y se puede usar simplemente colocando una etiqueta <script> . Vue.js utiliza JavaScript simple (ES5), HTML y CSS. La introducción a nuevos conceptos es mucho más gradual.

Después de trabajar en algunos proyectos de Vue.js, estará mejor preparado para profundizar en React. No es que siempre sea necesario, pero el desarrollo de Gutenberg, por ejemplo, lo requiere.

Utilice la API REST de WordPress

La API REST de WordPress es solo una interfaz estandarizada para solicitar y modificar datos de WordPress de forma remota. Es más una cuestión de arquitectura de software que una forma completamente diferente de codificación. Los mismos fragmentos antiguos de jQuery AJAX podrían usarse con parámetros ligeramente diferentes.

¿El beneficio más importante? Dado que la API REST de WordPress estandariza la comunicación entre el back-end y el front-end, es un paso importante hacia la modularidad, la reutilización y la legibilidad de su código. Esas terribles plantillas con HTML y PHP mezclados y algo de SQL agregado a la mezcla tienen que desaparecer. Una vez que las plantillas son solo HTML con marcadores de posición para los datos pasados ​​como parámetros, no hay mayor diferencia entre pasar esos datos en PHP o mediante una API REST a una aplicación de front-end.

También puede consultar WPGraphQL. Puede que eventualmente reemplace o no la API REST de WordPress, pero está ganando terreno rápidamente.

Aprenda Gutenberg (los clientes lo requerirán pronto)

El objetivo final de Gutenberg es la personalización completa del sitio, entre otros planes.

Esto sienta las bases para un nuevo modelo para WordPress Core que, en última instancia, tendrá un impacto en toda la experiencia de publicación de la plataforma.

La página del proyecto WordPress Gutenberg en GitHub

Gutenberg recibió un gran rechazo de los desarrolladores de WordPress. Algunos de los argumentos en contra de fusionarlo con el núcleo de WordPress fueron:

• Una parte significativa de los usuarios finales no lo necesitan, por lo que debería ser un complemento opcional y no parte del núcleo.
• Rompió algunos sitios
• Simplemente no estaba listo y le vendría bien un mayor pulido y menos errores.

Sin embargo, para los escritores de contenido que usan WordPress como plataforma de blogs, Gutenberg ofrece claramente una mejor experiencia que el antiguo editor.

Se admitirá la desactivación de Gutenberg siempre que sea necesario, sí. Pero empezar ahora es una buena idea: cuando un cliente se te acerque y te pida que hagas el desarrollo de Gutenberg, estarás listo.

Es hora de ponerse al día: incluso el “estilo WordPress” está evolucionando

El argumento más común en contra del uso de todas las herramientas y técnicas descritas anteriormente en el desarrollo de WordPress es este: la "forma de WordPress" de hacer las cosas todavía funciona, y se supone que esa forma es mejor que todas estas cosas nuevas y brillantes.

Pero ahora ha visto que los desarrolladores principales de WordPress están al tanto de todos los últimos desarrollos. No solo eso, los usan tanto como sea posible en las partes más nuevas del núcleo debido a sus obvias ventajas. Lo único que nos detiene es el código heredado que nadie va a refactorizar.

Durante algún tiempo, WordPress y WooCommerce han seguido la práctica de desarrollar "complementos de funciones" que implementan y usan nuevas tecnologías. Cuando sea el momento adecuado, estos complementos se fusionarán en el núcleo, como lo hizo Gutenberg. WooCommerce también tiene su propio proyecto React. La API REST de WordPress también comenzó como un complemento separado y ahora es parte del núcleo de WordPress.

La pregunta no es si debemos aprender cosas nuevas y usarlas en mi trabajo diario, sino cómo . La respuesta es "gradualmente", un paso a la vez. O aprendes algo nuevo o haces algo que conoces bien de una manera nueva y diferente.

Por ejemplo, aprenda a usar Webpack con todos sus scripts antiguos. Webpack puede transpilar su nuevo código ES6+ a JavaScript "simple" compatible con navegadores más antiguos. También puede minimizar los scripts y agruparlos. Eso es algo nuevo. ¿Hecho? Luego reescriba su JavaScript aprovechando las características de ES6. Es una nueva forma de hacer lo que bien sabes.

El resultado: aprenderá Webpack y ES6. Como profesionales, debemos dar un paso adelante y no dar un paso atrás. Sigue aprendiendo siempre. Y comparte cuando lo hagas: Toptal mantiene una lista de las mejores prácticas de desarrollo de WordPress y agradece las contribuciones de la comunidad.

En la Parte 2 de nuestra serie, nos sumergiremos en la parte de PHP del moderno desarrollo back-end de WordPress.