Mejores prácticas y complementos abstractos de WordPress

WordPress es un sistema de gestión de contenido antiguo, pero también es el que más se utiliza. Debido a que la historia ha admitido versiones obsoletas de PHP y código antiguo, las prácticas de codificación modernas aún no se han adoptado; un ejemplo es la abstracción de WordPress.

Por ejemplo, sería mucho mejor dividir el paquete de código del kernel de WordPress en paquetes administrados por Composer. O descargue automáticamente las categorías de WordPress desde la ruta del archivo.

Este artículo explica cómo abstraer manualmente el código de WordPress y utilizar las funciones abstractas de los complementos de WordPress.

Problema de integración de herramientas de WordPress y PHP

Debido a su antigua arquitectura, la integración de WordPress en medios de código PHP, como el analizador estático PHPStan, la biblioteca de pruebas unitarias PHPUnit y la biblioteca de alcance de espacio de nombres PHP Scoper, a veces causa problemas. Por ejemplo, considere la siguiente situación:

El código de WordPress en nuestro proyecto es solo una pequeña parte, el proyecto también incluye un código de empresa que no tiene nada que ver con el sistema de gestión de contenido subyacente. Sin embargo, con solo un pequeño código de WordPress, es posible que el proyecto no se integre correctamente en la herramienta.

Por lo tanto, puede tener sentido dividir el proyecto en varios paquetes, algunos de los cuales contienen código de WordPress, mientras que otros solo contienen código de empresa con PHP “vanilla” y no código de WordPress. De esta manera, los últimos problemas no se ven afectados por los problemas mencionados anteriormente, pero pueden integrarse completamente en la herramienta.

¿Qué es la adquisición de código?

La abstracción de código elimina las dependencias fijas del código, lo que permite que los paquetes interactúen entre sí a través de acuerdos. Luego, estos paquetes se pueden agregar a diferentes aplicaciones con diferentes pilas para maximizar su usabilidad. El resultado de la adquisición del código es una base de código completamente separada basada en los siguientes pilares:

1. Código de interfaz de usuario, no implementación.
2. Cree paquetes y compártalos a través de Composer.
3. Pegue todas las partes con spray colgante.

¿Quiere saber más sobre cómo tomar código de WordPress? Mejores prácticas recomendadas Extensiones recomendadas Todo lo que necesita saber está a un clic de distancia ⬇️Haga clic para twittear

Codificación de interfaces en lugar de implementación

Cuando se definen interfaces, se utilizan convenciones para permitir que los fragmentos de código interactúen entre sí. El contrato es solo una interfaz PHP (o algún otro lenguaje) que define las funciones disponibles y sus firmas, es decir, las entradas y salidas recibidas.

La interfaz de usuario indica el propósito de la función sin explicar cómo se implementa la función. Gracias a la característica fácil de usar de la interfaz, nuestras aplicaciones pueden confiar en segmentos de código independientes para lograr ciertos objetivos sin saber o preocuparse por su implementación. De esta forma, no es necesario personalizar la aplicación para pasar a otro fragmento de código que logre el mismo objetivo, por ejemplo, de un proveedor diferente.

Acuerdo de muestra

El siguiente código usa el acuerdo de Symfony CacheInterface Acuerdo de referencia estándar de PHP (PSR) CacheItemInterface Implementar el almacenamiento en caché:

use PsrCacheCacheItemInterface;
use SymfonyContractsCacheCacheInterface;

$value = $cache->get('my_cache_key', function (CacheItemInterface $item) 
    $item->expiresAfter(3600);
    return 'foobar';
);

$cache herramienta CacheInterfaceque define el método get Recupere el objeto de la caché. Al utilizar esta función a través del contrato, es posible que la aplicación no sepa dónde está el caché. Ya sea en memoria, disco duro, base de datos, red o en otro lugar. Sin embargo, debe cumplir este papel. CacheItemInterface Método de determinación expiresAfter Indique cuánto tiempo debe almacenarse en caché el elemento. Una aplicación puede llamar a este método sin preocuparse por el objeto en caché; solo le importa cuánto tiempo debe almacenarse en caché.

Para codificar la interfaz en WordPress

Debido a que abstraemos el código de WordPress, esto significa que la aplicación no se refiere directamente al código de WordPress, sino que siempre se refiere a él a través de la interfaz de usuario, por ejemplo, las funciones de WordPress. get_posts Tiene esta firma:

/**
 * @param array $args
 * @return WP_Post[]|int[] Array of post objects or post IDs.
 */
function get_posts( $args = null )

Podemos usar el contrato en lugar de llamar a este método directamente OwnerMyAppContractsPostsAPIInterface:

namespace OwnerMyAppContracts;

interface PostAPIInterface
int[];

Preste atención a las características de WordPress get_posts Puede devolver artículos de clase WP_Postque es característico de WordPress. En las abstracciones de código, necesitamos eliminar este método de dependencia fija get_posts Devolver los tipos de objetos en el contrato. PostInterface, Puede hacer referencia a una categoría WP_Post La clase no tiene una descripción clara PostInterface Acceso a todos los métodos y funciones necesarios WP_Post:

namespace OwnerMyAppContracts;

interface PostInterface

  public function get_ID(): int;
  public function get_post_author(): string;
  public function get_post_date(): string;
  // ...

La implementación de esta estrategia puede cambiar nuestra comprensión de dónde encaja WordPress en nuestra pila. En lugar de pensar en WordPress como una aplicación en sí misma (en la que instalamos temas y complementos), simplemente podemos pensar en ello como otra dependencia de una aplicación que puede ser reemplazada como cualquier otro componente. (Si bien no reemplazamos WordPress en la práctica, es sí señor Desde un punto de vista conceptual, es intercambiable. )

Crea y comparte paquetes

Composer es un administrador de paquetes PHP. Permite a las aplicaciones PHP extraer paquetes (es decir, fragmentos de código) de un archivo e instalarlos como dependencias. Para distinguir una aplicación de WordPress, necesitamos dividir su código en dos tipos diferentes de paquetes: un paquete con código de WordPress y otro paquete con lógica empresarial (es decir, sin código de WordPress).

Finalmente, agregamos todos los paquetes a la aplicación como dependencias y los instalamos a través de Composer. Dado que las herramientas se aplican a los paquetes de códigos de empresa, deben contener la mayor parte del código de la aplicación; cuanto mayor sea el porcentaje, mejor. Dejar que controlen alrededor del 90% de todo el código es un buen objetivo.

Extraiga el código de WordPress en el paquete

El ejemplo anterior es un contrato. PostAPIInterface con PostInterface Se agregó al paquete con el código de la empresa y el segundo paquete incluye la implementación de WordPress de estos acuerdos. PostInterface, Creamos un PostWrapper La clase de la que se derivan todos los atributos. WP_Post Objetivo:

namespace OwnerMyAppForWPContractImplementations;

use OwnerMyAppContractsPostInterface;
use WP_Post;

class PostWrapper implements PostInterface

  private WP_Post $post;
  
  public function __construct(WP_Post $post)
  
    $this->post = $post;
  

  public function get_ID(): int
  
    return $this->post->ID;
  

  public function get_post_author(): string
  
    return $this->post->post_author;
  

  public function get_post_date(): string
  
    return $this->post->post_date;
  

  // ...

Durante la implementación PostAPI, Debido al método get_posts Regreso PostInterface[], Necesitamos un artículo WP_Post llegar PostWrapper:

namespace OwnerMyAppForWPContractImplementations;

use OwnerMyAppContractsPostAPIInterface;
use WP_Post;

class PostAPI implements PostAPIInterface
int[]
  
    // This var will contain WP_Post[] or int[]
    $wpPosts = get_posts($args);

    // Convert WP_Post[] to PostWrapper[]
    return array_map(
      function (WP_Post

Usa una inyección de adicción

Dependency Injection es una estructura que le permite pegar sin apretar todas las partes de la aplicación. Con la inyección de dependencia, las aplicaciones acceden a los servicios a través de sus contratos y las implementaciones de los contratos se “inyectan” en la aplicación a través de la configuración.

Podemos cambiar fácilmente de un proveedor por contrato a otro simplemente cambiando la configuración. Podemos seleccionar varias bibliotecas de inyección de dependencia. Le recomendamos que seleccione una biblioteca que cumpla con las recomendaciones del estándar PHP (a menudo "PSR") para que pueda reemplazarse fácilmente con otra biblioteca si es necesario. Para la inyección de adicciones, la biblioteca debe cumplir con PSR-11, que proporciona una especificación de "interfaz de contenedor". Las siguientes bibliotecas cumplen con PSR-11:

Puede acceder al servicio a través de un contenedor de servicios

La Biblioteca de inyección de adicciones proporciona un "contenedor de servicios" que resuelve el contrato al nivel de implementación correspondiente. La aplicación debe confiar en el contenedor de servicios para utilizar todas las funciones. Por ejemplo, aunque solemos llamar directamente a las funciones de WordPress:

$posts = get_posts();

... Con un tanque de servicio, primero debe recibir un servicio satisfactorio PostAPIInterface Y realizar funciones:

use OwnerMyAppContractsPostAPIInterface;

// Obtain the service container, as specified by the library we use
$serviceContainer = ContainerBuilderFactory::getInstance();

// The obtained service will be of class OwnerMyAppForWPContractImplementationsPostAPI
$postAPI = $serviceContainer->get(PostAPIInterface::class);

// Now we can invoke the WordPress functionality
$posts = $postAPI->get_posts();

Inyección de adicciones con sinfonía

El componente DependencyInjection de Symphony es actualmente la biblioteca de inyecciones de adicciones más popular. Le permite configurar el contenedor de servicios utilizando, por ejemplo, código PHP, YAML o XML para definir el acuerdo. PostAPIInterface Satisfecho con el curso PostAPI La composición de YAML se ve así:

services:
  OwnerMyAppContractsPostAPIInterface:
    class: OwnerMyAppForWPContractImplementationsPostAPI

DependencyInjection de Symphony también permite la inyección automática (o "cableado automático") de una única instancia de servicio en cualquier otro servicio que dependa de ella. Además, puede definir fácilmente una clase como una implementación de su propio servicio. Saludos Por ejemplo, tienes la siguiente configuración de YAML:

services:
  _defaults:
    public: true
    autowire: true

  GraphQLAPIGraphQLAPIRegistriesUserAuthorizationSchemeRegistryInterface:
    class: 'GraphQLAPIGraphQLAPIRegistriesUserAuthorizationSchemeRegistry'

  GraphQLAPIGraphQLAPISecurityUserAuthorizationInterface:
    class: 'GraphQLAPIGraphQLAPISecurityUserAuthorization'
    
  GraphQLAPIGraphQLAPISecurityUserAuthorizationSchemes:
    resource: '../src/Security/UserAuthorizationSchemes/*'

Esta configuración define lo siguiente:

• convenio UserAuthorizationSchemeRegistryInterface Satisfecho con el curso UserAuthorizationSchemeRegistry
• convenio UserAuthorizationInterface Satisfecho con el curso UserAuthorization
• Todas las categorías de la carpeta UserAuthorizationSchemes/ Tener su propia información
• Los servicios deben estar interconectados automáticamente (autowire: true)

Veamos cómo funciona la configuración automática - en clase UserAuthorization Según el servicio contratado UserAuthorizationSchemeRegistryInterface:

class UserAuthorization implements UserAuthorizationInterface

  public function __construct(
      protected UserAuthorizationSchemeRegistryInterface $userAuthorizationSchemeRegistry
  ) 
  

  // ...

gracias autowire: true, El componente DependencyInjection tiene servicio automáticamente UserAuthorization Obtenga las dependencias necesarias, este es un ejemplo UserAuthorizationSchemeRegistry.

Cuando abstracto

El código abstracto puede requiere mucho tiempo y esfuerzo, por lo que solo deberíamos hacer esto cuando los beneficios superen los costos. A continuación se ofrecen sugerencias sobre cuándo puede resultar útil la abstracción de código. Puede utilizar los fragmentos de código de este artículo o el complemento abstracto de WordPress que se sugiere a continuación para lograrlo.

Obtienes acceso a las herramientas

Como se mencionó anteriormente, PHP Scorer es difícil de usar en WordPress. Cuando descomprime el código de WordPress en diferentes paquetes, puede especificar el alcance del complemento de WordPress directamente.

Reducir el tiempo y los costos de procesamiento

El conjunto de pruebas PHPUnit tarda más en completarse cuando WordPress necesita inicializarse y ejecutarse que cuando no es necesario. Menos tiempo también puede significar menos dinero para ejecutar pruebas; por ejemplo, GitHub Actions cobra a los corredores alojados en GitHub en función de su tiempo de actividad.

No se necesitan reformas importantes

Los proyectos existentes pueden requerir mucha reconstrucción para implementar la arquitectura requerida (inyectar la dependencia, dividir el código en paquetes, etc.), lo que dificulta la extracción. Compacte el código a medida que construye su proyecto desde cero para que sea más fácil de administrar.

Genere código para múltiples plataformas

Al extraer el 90% del código en un paquete CMS independiente, podemos crear una versión de biblioteca que sea compatible con diferentes marcos o sistemas CMS, y solo necesitamos reemplazar el 10% de todo el código base.

Cambiar a otra plataforma

Si necesitamos mover un proyecto de Drupal a WordPress, de WordPress a Laravel, o alguna otra combinación, solo tenemos que reescribir el 10% del código, eso es un ahorro significativo.

Curso de acción recomendado

Al diseñar contratos como abstractos de nuestro código, podemos realizar algunas mejoras en la base del código.

Compatibilidad con PSR-12

Al definir la interfaz para usar métodos de WordPress, debemos seguir PSR-12. El propósito de esta nueva especificación es reducir la fricción cognitiva al escanear código de diferentes autores. La compatibilidad con PSR-12 significa que se cambiará el nombre de las funciones de WordPress.

Usando la función de título de WordPress Caparazón de serpiente, Utilizado durante PSR-12 Paquete de cigarrillos camelPor tanto, la función get_posts Estarán getPosts:

interface PostAPIInterface
int[];

…con:

class PostAPI implements PostAPIInterface

  public function getPosts(array $args = null): PostInterface[]

Método dividido

El método de la interfaz de usuario no tiene que ser una copia del método de WordPress. Podemos convertirlos si tiene sentido, por ejemplo, funciones de WordPress. get_user_by($field, $value) Aprenda a buscar en la base de datos usando parámetros $field, Acepta el valor "id", "ID", "slug", "email" o "login"Hay varios problemas con este diseño:

• Si pasamos la cadena incorrecta, no fallará en el momento de la compilación
• Ámbito de aplicación $value Tienes que aceptar todas las diferentes opciones, incluso si existen. "ID" Está esperando un intSi se salta "email" Solo puede recibir uno string

Podemos mejorar esta situación dividiendo la función en varias:

namespace OwnerMyAppContracts;

interface UserAPIInterface

  public function getUserById(int $id): ?UserInterface;
  public function getUserByEmail(string $email): ?UserInterface;
  public function getUserBySlug(string $slug): ?UserInterface;
  public function getUserByLogin(string $login): ?UserInterface;

El acuerdo de WordPress se resuelve de esta manera (si hemos creado UserWrapper con UserInterface, Como se ha mencionado más arriba):

namespace OwnerMyAppForWPContractImplementations;

use OwnerMyAppContractsUserAPIInterface;

class UserAPI implements UserAPIInterface
string $value): ?UserInterface
  
    if ($user = get_user_by($prop, $value)) 
      return new UserWrapper($user);
    
    return null;
  

Eliminar la información de implementación de la firma de la función

Las funciones de WordPress pueden proporcionar información sobre cómo se implementan en sus propias firmas. Al evaluar la funcionalidad desde una perspectiva abstracta, esta información se puede eliminar; por ejemplo, para obtener el apellido de un usuario en WordPress, llame get_the_author_meta, Lo que indica claramente que el apellido del usuario se almacena como un valor de "yuanes" (en la tabla) wp_usermeta):

$userLastname = get_the_author_meta("user_lastname", $user_id);

No es necesario que proporcione esta información en el contrato. La interfaz solo transmite qué, no cómo, por lo que un contrato puede tener un método getUserLastname, No contiene información de implementación:

interface UserAPIInterface

  public function getUserLastname(UserWrapper $userWrapper): string;
  ...

Tipos más estrictos

Algunas funciones de WordPress pueden recibir parámetros de diferentes formas, lo que genera ambigüedad, por ejemplo add_query_arg Puede recibir una clave y un valor:

$url = add_query_arg('id', 5, $url);

... o serie key => value:

$url = add_query_arg(['id' => 5], $url);

Nuestra interfaz puede definir intenciones más comprensibles al dividir estas funciones en varias funciones separadas, cada una de las cuales acepta una combinación única de ingresos:

public function addQueryArg(string $key, string $value, string $url);
public function addQueryArgs(array $keyValues, string $url);

Eliminar la deuda técnica

Funciones de WordPress get_posts Además del correo, devuelva todas las páginas o conjuntos de correo personalizados, y estas entidades no son intercambiables. Tanto el mensaje como la página son mensajes personalizados, pero la página no es ni un mensaje ni una página, así que ejecute get_posts Puede volver a la página. Este comportamiento es una diferencia conceptual.

Para hacerlo bien get_posts Significa get_customposts, Pero nunca se le cambió el nombre en el kernel de WordPress. Este es un problema común con la mayoría de los firmware y se conoce como un "código de deuda técnica", que es problemático pero nunca se soluciona porque causa cambios molestos.

Sin embargo, a la hora de redactar el contrato, tenemos la oportunidad de evitar este tipo de fallas técnicas, permitiéndonos crear una nueva interfaz. ModelAPIInterface Puede manejar diferentes tipos de entidades, hemos desarrollado varios métodos, cada uno de los cuales trata con diferentes tipos:

interface ModelAPIInterface

  public function getPosts(array $args): array;
  public function getPages(array $args): array;
  public function getCustomPosts(array $args): array;

De esta manera, la diferencia ya no es visible y verá los siguientes resultados:

• getPosts Devolver solo mensajes
• getPages Volver a la pagina
• getCustomPosts Volver a publicaciones y páginas

Los beneficios del código abstracto

Los principales beneficios de la abstracción del código de la aplicación son:

• Las herramientas que solo funcionan con paquetes que contienen código de empresa son más fáciles de instalar y requieren menos tiempo (y dinero).
• Podemos utilizar herramientas que no son compatibles con WordPress, como PHP Scoper, para determinar el alcance del complemento.
• Los paquetes que producimos pueden ser independientes y se pueden usar fácilmente en otras aplicaciones.
• Transferir aplicaciones a otras plataformas se ha vuelto más fácil.
• Podemos cambiar nuestra forma de pensar de WordPress a pensar en lógica empresarial.
• El acuerdo describe el propósito de la aplicación y facilita su comprensión.
• La aplicación está organizada en paquetes, creando una aplicación mínima y ajustada que se puede expandir gradualmente según sea necesario.
• Podemos limpiar las deudas técnicas.

Problema de código abstracto

Las desventajas del código de aplicación abstracto son:

• Al principio fue mucho trabajo.
• El código se vuelve más complejo; Se agregan capas de código adicionales para lograr el mismo resultado.
• Eventualmente, puede crear docenas de paquetes que deben administrarse y mantenerse.
• Es posible que necesite un repositorio mono para administrar todos sus paquetes juntos.
• En aplicaciones simples (reducción de rendimiento), la inyección adictiva puede ser excesiva.
• El código abstracto nunca estará completamente terminado porque la preferencia general generalmente está implícita en la arquitectura del CMS.

Opciones de complemento de WordPress condensadas

Si bien generalmente tiene más sentido decodificar el código en su entorno local antes de procesarlo, algunos complementos de WordPress pueden ayudarlo a lograr sus objetivos de abstracción. Éstas son nuestras mejores opciones.

1.WPide

El popular complemento WPide de WebFactory Ltd amplía significativamente la funcionalidad del editor de código estándar de WordPress. Como complemento abstracto de WordPress, le permite ver su código para que pueda visualizar mejor lo que necesita atención.

Extensión WPide.

WPide también tiene una función de búsqueda y reemplazo que le permite encontrar rápidamente código obsoleto u obsoleto y reemplazarlo con una copia revisada.

Lo más importante es que WPide tiene muchas características adicionales, como:

• Sintaxis y énfasis en bloques
• Copia de seguridad automática
• Creando archivos y carpetas
• Explorador de árbol de archivos completo
• Utilice la API del sistema de archivos de WordPress

2. Gestión final de la base de datos

El complemento Ultimate WP DB Manager de WPHobby le permite descargar rápidamente una base de datos completa para su extracción y reconstrucción.

La última extensión de gestión de bases de datos.

Por supuesto, los usuarios de Kinsta no necesitan tal extensión, ya que Kinsta brinda a todos los clientes acceso directo a la base de datos. Sin embargo, si su proveedor de alojamiento no tiene suficiente acceso a la base de datos, Ultimate DB Manager puede ser un útil complemento abstracto de WordPress.

3. Mi complemento de WordPress abstracto personalizado

Al final, la mejor opción de abstracción es siempre construir una extensión. Esto puede parecer una tarea desalentadora, pero si su capacidad para administrar archivos centrales de WordPress directamente es limitada, esto le proporcionará una solución abstracta y amigable.

Esto tiene ventajas obvias:

• Compactar la función del archivo de tema
• Conserve su código con cambios de diseño y actualizaciones de la base de datos

Consulte la Guía de desarrollo de complementos de WordPress para aprender a crear complementos abstractos de WordPress.

Esta guía detallada explica cómo abstraer manualmente su código y utilizar las funciones abstractas del complemento de WordPress 🚀⬇️Haga clic para twittear

Generalizar

¿Deberíamos condensar el código de la aplicación? Como ocurre con todo, no existe una “respuesta correcta” predefinida porque depende del proyecto. Los proyectos que toman mucho tiempo para analizar con PHPUnit o PHPStan pueden beneficiarse más, pero la implementación no siempre es rentable.

Ya sabe todo lo que necesita para iniciar la abstracción de código de WordPress.

¿Está planeando implementar esta estrategia en su proyecto? Si es así, ¿utilizaría el complemento abstracto de WordPress? ¡Deja tu comentario en la sección de reseñas!