Ne surconcevez pas la solution

Last updated Déc 9, 2022

Teneur

Si vous venez d’un milieu orienté objet ou si vous essayez de créer toutes vos solutions pour WordPress en utilisant des techniques orientées objet, il y aura des moments où vous aurez l’impression de frapper un clou avec un marteau.

Par exemple, disons que quelqu’un vient vers vous et a besoin d’un plugin personnalisé développé qui fonctionne avec un plugin tiers, mais il n’a besoin de faire qu’une seule chose.

Vaut-il la peine de prendre le temps de créer une interface, d’implémenter ladite interface dans une classe concrète, de mettre en place des abonnés, d’écrire des tests unitaires, etc.

Je peux voir l’appel, mais je dis généralement non. Si l’essentiel de ce que vous devez faire doit inclure des styles ou des fichiers JavaScript ou les deux, alors pourquoi ne pas vous fier aux API WordPress natives et à la programmation procédurale ?

Ne faites pas trop d’ingénierie

Disons qu’un client potentiel vient à vous qui :

travaille avec un budget très serré,
a un plugin tiers qui ne correspond pas bien à son thème,
n’a besoin que d’un style léger,
et a les fonds pour vous contracter pour le travail.

En supposant que tout ce qui précède est vrai, je dirais que trouver la solution semble assez simple, n’est-ce pas ? Nous devons auditer le site afin de pouvoir :

déterminer le jeu de couleurs,
trouver les sélecteurs nécessaires pour le CSS,
puis commencez à construire le plugin.

Maintenant, quand il s’agit de faire cela, j’essaie toujours d’employer une poignée de meilleures pratiques. Même si je tends vers la programmation orientée objet, je ne l’utilise pas toujours et je ne la recommande pas toujours.

Au lieu de cela, je pense que l’utilisation d’une simple fonction ou d’un ensemble de fonctions liées à l’API WordPress de manière procédurale fonctionne très bien. Cependant, cela ne signifie pas que nous ne devrions pas viser à créer une structure d’organisation de fichiers solide car vous ne savez jamais quand vous devrez peut-être revenir pour maintenir le projet.

Pour cela, voici ce que je fais normalement :

créer un répertoire d’assets pour les feuilles de style et JavaScript (pour les deux ou l’un pour l’autre – selon ce qui est nécessaire),
créer un répertoire src pour le code qui sera chargé de s’accrocher à WordPress,
ajoutez les fichiers habituels LICENSE, README et plugin bootstrap.

Le répertoire résultant peut ressembler à ceci :

À partir de là, je ne m’embête même plus avec un chargeur automatique. Au lieu de cela, j’inclus les fichiers dans le répertoire source. Vous pouvez parcourir ces fichiers plutôt que de faire quelque chose comme ceci :

<?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';

Mais cela peut dépendre du moment et de ce que vous faites.

C’est trop simple

Peut-être. Voici le problème : chaque fois qu’une personne s’enracine dans l’utilisation d’un certain paradigme de programmation, ladite personne essaie de l’appliquer partout et essaie de le faire tout le temps.

Pas tout le monde, mais beaucoup. Moi inclus.

Et lorsque vous vous retrouvez à sur-architecturer quelque chose, pourquoi ne pas prendre du recul et essayer de simplifier un peu votre charge de travail ?

Le problème est toujours résolu, et il est fait d’une manière qui a beaucoup moins de frais généraux.

Source d’enregistrement: tommcfarlin.com