Resumen del código de WordPress para reutilizar con otros CMS: Conceptos (Parte 1)

Hacer código que sea independiente del CMS o el marco tiene varios beneficios. Por ejemplo, a través de su nuevo editor de contenido Gutenberg, WordPress permite codificar componentes que también se pueden usar para otros CMS y marcos, como Drupal y Laravel . Sin embargo, el énfasis de Gutenberg en la reutilización del código se centra en el código del componente del lado del cliente (JavaScript y CSS); con respecto al código de back-end del componente (como la provisión de API que alimentan datos al componente) no hay una consideración preestablecida.

Dado que estos CMS y frameworks (WordPress, Drupal, Laravel) se ejecutan todos en PHP, hacer que su código PHP también sea reutilizable hará que sea más fácil ejecutar nuestros componentes en todas estas plataformas diferentes. Como otro ejemplo, si alguna vez decidimos reemplazar nuestro CMS con otro (como ha sucedido recientemente que muchas personas denunciaron a WordPress después de su introducción de Gutenberg), hacer que el código de la aplicación sea independiente del CMS simplifica las cosas: cuanto más CMS-agnóstico sea nuestro el código de la aplicación es, se requerirá menos esfuerzo para portarlo a otras plataformas.

Comenzando con el código de aplicación creado para un CMS específico, el proceso de transformarlo en independiente de CMS es lo que, en este artículo, llamaré «código de resumen». Cuanto más abstracto es el código, más se puede reutilizar para trabajar con cualquier CMS.

Sin embargo, hacer que la aplicación sea completamente independiente de CMS es muy difícil, incluso posiblemente imposible, ya que tarde o temprano tendrá que depender de la opinión específica del CMS. Luego, en lugar de intentar alcanzar el 100% de reutilización del código, nuestro objetivo debe ser simplemente maximizar la cantidad de código que sea independiente de CMS para que sea reutilizable en diferentes CMS o marcos (para el contexto de este artículo, estos 2 términos serán usado indistintamente). Luego, migrar la aplicación a un marco diferente no será fácil, pero al menos será lo menos doloroso posible.

La solución a este desafío se refiere a la arquitectura de nuestra aplicación: debemos mantener el núcleo de la aplicación desacoplado de los detalles del marco subyacente, al codificar contra interfaces en lugar de implementaciones. Hacerlo otorgará beneficios adicionales a nuestra base de código: entonces podemos centrar nuestra atención casi exclusivamente en la lógica de negocios (que es la esencia y el propósito real de la aplicación), lo que hace que el código sea más comprensible y menos confuso con las limitaciones impuestas por El CMS particular.

Este artículo se compone de 2 partes: en esta primera parte conceptualizaremos y diseñaremos la solución para abstraer el código de un sitio de WordPress, y en la segunda parte lo implementaremos. El objetivo será mantener el código listo para usar con los componentes de Symfony , el framework Laravel y el CMS de octubre.

Código Contra Interfaces, Confíe En El Compositor, Benefíciese De La Inyección De Dependencia

El diseño de nuestra arquitectura se basará en los siguientes pilares:

1. Código contra interfaces, no implementaciones.
2. Cree paquetes, distribúyalos a través de Composer.
3. Inyección de dependencia para pegar todas las partes.

Analicemos uno por uno.

CÓDIGO CONTRA INTERFACES, NO IMPLEMENTACIONES

La codificación contra interfaces es la práctica de interactuar con cierto código a través de un contrato. Un contrato, que se configura a través de una interfaz desde nuestro lenguaje de programación (PHP en nuestro caso ya que estamos tratando con WordPress), establece la intención de cierta funcionalidad, al establecer explícitamente qué funciones están disponibles, qué entradas se esperan para cada función, y qué devolverá cada función, y no le preocupa cómo debe implementarse la funcionalidad. Luego, nuestra aplicación se puede desacoplar limpiamente de una implementación específica, sin necesidad de saber cómo funcionan sus componentes internos y poder cambiar a otra implementación en cualquier momento sin tener que cambiar drásticamente el código. Por ejemplo, nuestra aplicación puede almacenar datos interactuando con una interfaz llamadaDataStoreInterfaceen lugar de cualquiera de sus implementaciones, como instancias de clases DatabaseDataStoreo FilesystemDataStore.

En el contexto de WordPress, esto implica que, al final de la abstracción, no se hará referencia directa a ningún código de WordPress, y WordPress será simplemente un proveedor de servicios para todas las funciones que nuestra aplicación necesita. Como consecuencia, debemos considerar WordPress como una dependencia de la aplicación, y no como la aplicación en sí.

Los contratos y sus implementaciones se pueden agregar a paquetes distribuidos a través de Composer y pegados a la aplicación mediante inyección de dependencia, que son los elementos que analizaremos a continuación.

CREAR PAQUETES, DISTRIBUIRLOS A TRAVÉS DE COMPOSER

Recuerda esto: ¡ Composer es tu amigo! Esta herramienta, un administrador de paquetes para PHP, permite a cualquier aplicación PHP recuperar fácilmente paquetes (es decir, código) de cualquier repositorio e instalarlos como dependencias.

Composer es en sí mismo independiente de CMS, por lo que puede usarse para construir cualquier aplicación PHP. Sin embargo, los paquetes distribuidos a través de Composer pueden ser independientes de CMS o no. Por lo tanto, nuestra aplicación debe depender de los paquetes independientes de CMS (que funcionarán para cualquier CMS) tanto como sea posible y, cuando no sea posible, depender del paquete correspondiente que funcione para nuestro CMS específico.

Esta estrategia se puede utilizar para codificar contra contratos, como se explicó anteriormente. Los paquetes para nuestra aplicación se pueden dividir en dos tipos: independientes de CMS y específicos de CMS. El paquete independiente de CMS contendrá todos los contratos y todo el código genérico, y la aplicación interactuará exclusivamente con estos paquetes. Para cada paquete independiente de CMS que contenga contratos, también debemos crear un paquete específico de CMS que contenga la implementación de los contratos para el CMS requerido, que se establece en la aplicación mediante inyección de dependencia (que analizaremos a continuación).

Por ejemplo, para implementar una API para recuperar publicaciones, creamos un paquete independiente de CMS llamado «Publicaciones», con PostAPIInterfaceuna función que contiene contratos getPosts, como esta:

interface PostAPIInterface
{
  public function getPosts($args);
}

Esta función se puede resolver para WordPress a través de un paquete llamado «Publicaciones para WordPress», que resuelve el contrato a través de una clase WPPostAPI, implementando la función getPosts para ejecutar simplemente la función get_posts de WordPress, como esta:

class WPPostAPI implements PostAPIInterface
{
  public function getPosts($args) {
    return get_posts($args);
  }
}

Si alguna vez necesitamos portar nuestra aplicación de WordPress a otro CMS, solo debemos implementar el paquete específico de CMS correspondiente para el nuevo CMS (por ejemplo, «Publicaciones para el CMS de octubre») y actualizar los contratos de coincidencia de configuración de inyección de dependencia para implementaciones, y eso es ¡eso!

Nota : es una buena práctica crear paquetes que solo definan contratos y nada más. De esta manera, es fácil para los implementadores saber exactamente qué se debe implementar.

INYECCIÓN DE DEPENDENCIA PARA UNIR TODAS LAS PARTES

La inyección de dependencia es una técnica que permite declarar qué objeto del paquete específico de CMS (también conocido como «proveedor de servicios») está implementando qué interfaz del paquete independiente de CMS (también conocido como «contrato»), pegando así todas las partes de la aplicación. de una manera flojamente acoplada.

Es posible que ya se envíen diferentes CMS o marcos con su propia implementación de un componente de inyección de dependencia. Por ejemplo, mientras que WordPress no tiene ninguno, tanto Symfony como Laravel tienen sus propias soluciones: el componente DependencyInjection y Service Container respectivamente.

Idealmente, deberíamos mantener nuestra aplicación libre de elegir una solución de inyección de dependencia específica y dejar que el CMS se encargue de esto. Sin embargo, la inyección de dependencia debe usarse también para unir contratos y servicios genéricos, y no solo aquellos que dependen del CMS (por ejemplo, un contrato DataStoreInterface, resuelto a través del proveedor de servicios FilesystemDataStore, puede no estar relacionado con el CMS subyacente). Además, una aplicación muy simple que no requiere un CMS subyacente aún se beneficiará de la inyección de dependencia. Por lo tanto, nos vemos obligados a elegir una solución específica para la inyección de dependencia.

Nota : Al elegir una herramienta o biblioteca, priorice aquellas que implementan la Recomendación de estándares PHP correspondiente (en nuestro caso, estamos interesados ​​en PSR-11 ), para que puedan reemplazarse sin afectar el código de la aplicación tanto como sea posible (en la práctica , es probable que cada solución tenga una inicialización personalizada, por lo que puede ser inevitable volver a escribir el código de la aplicación).