No sobrediseñe la solución

Si proviene de un entorno orientado a objetos o intenta construir todas sus soluciones para WordPress utilizando técnicas orientadas a objetos, entonces habrá momentos en los que puede sentirse como si estuviera golpeando un clavo con un mazo.

Por ejemplo, supongamos que alguien se acerca a usted y necesita que se desarrolle un complemento personalizado que funcione con un complemento de terceros, pero solo necesita hacer una cosa.

¿Vale la pena tomarse el tiempo para crear una interfaz, implementar dicha interfaz en una clase concreta, configurar suscriptores, escribir pruebas unitarias, etc.?

Puedo ver el atractivo, pero generalmente digo que no. Si la esencia de lo que debe hacer tiene que incluir estilos o archivos JavaScript o ambos, ¿por qué no confiar en las API nativas de WordPress y la programación de procedimientos?

No sobrediseñe

Digamos que un cliente potencial viene a ti que:

• está trabajando con un presupuesto muy ajustado,
• tiene un complemento de terceros que no encaja bien con su tema,
• solo necesita un estilo ligero,
• y tiene los fondos para contratarlo para el trabajo.

Suponiendo que todo lo anterior sea cierto, entonces diría que trabajar en la solución parece bastante simple, ¿verdad? Necesitamos auditar el sitio para que podamos:

• determinar el esquema de color,
• encontrar los selectores necesarios para el CSS,
• luego comience a construir el complemento.

Ahora, cuando se trata de hacer esto, todavía trato de emplear un puñado de mejores prácticas. Aunque tiendo a la programación orientada a objetos, no siempre la uso ni siempre la recomiendo.

En cambio, creo que usar una función simple o un conjunto de funciones conectadas a la API de WordPress de manera procesal funciona bien. Sin embargo, eso no significa que no debamos intentar crear una estructura de organización de archivos sólida porque nunca se sabe cuándo tendrá que volver para mantener el proyecto.

Con ese fin, esto es lo que normalmente hago:

• crear un directorio de activos para hojas de estilo y JavaScript (para ambos o uno de los otros, lo que sea necesario),
• crear un directorio src para el código que será responsable de conectarse a WordPress,
• agregue la LICENCIA habitual , LÉAME y el archivo de arranque del complemento.

El directorio resultante puede verse así:

A partir de ahí, ni siquiera me molesto con un cargador automático. En su lugar, incluyo los archivos en el directorio de origen. Podría iterar a través de esos archivos en lugar de hacer algo como esto :

<?php
/**
 * Acme Plugin Example
 *
 * @author    Tom McFarlin <tom@pressware.co>
 * @license   GPL-3.0+
 * @link      https://pressware.co
 * @since     1.0.0
 * @copyright 2018 Tom McFarlin
 *
 * @wordpress-plugin
 * Plugin Name: Acme Plugin Example
 * Description: Provides consistent styling across the site for certain elements.
 * Version:     1.0.0
 * Author:      Tom McFarlin
 * Author URI:  https://tommcfarlin.com
 * License:     GPL-3.0+
 * License URI: http://www.gnu.org/licenses/gpl-3.0.txt
 */

include_once plugin_dir_path(__FILE__).'src/AddStyles.php';
include_once plugin_dir_path(__FILE__).'src/AddScripts.php';

Pero eso podría depender de cuándo y qué estés haciendo.

esto es demasiado simple

Quizás. Aquí está la cosa: cada vez que una persona se atrinchera en el uso de un determinado paradigma de programación, dicha persona trata de aplicarlo en todas partes y trata de hacerlo todo el tiempo.

No todos, pero muchos. Yo mismo incluido.

Y cuando te encuentres sobrediseñando algo, ¿por qué no dar un paso atrás y tratar de simplificar un poco tu carga de trabajo?

El problema aún está resuelto, y se hace de una manera que tiene una sobrecarga significativamente menor.