Não exagere na engenharia da solução

Se você vem de um background orientado a objetos ou tenta construir todas as suas soluções para WordPress usando técnicas orientadas a objetos, haverá momentos em que pode parecer que você está acertando um prego com uma marreta.

Por exemplo, digamos que alguém venha até você e precise de um plugin personalizado desenvolvido que funcione com um plugin de terceiros, mas ele só precisa fazer uma coisa.

Vale a pena dedicar um tempo para criar uma interface, implementar a referida interface em uma classe concreta, configurar assinantes, escrever testes de unidade e assim por diante?

Eu posso ver o apelo, mas geralmente digo não. Se a essência do que você precisa fazer deve incluir estilos ou arquivos JavaScript ou ambos, por que não confiar nas APIs nativas do WordPress e na programação processual?

Não exagere na engenharia

Digamos que um cliente em potencial venha até você que:

• está trabalhando com um orçamento muito apertado,
• tem um plugin de terceiros que não se encaixa bem com o tema,
• precisa apenas de um estilo leve,
• e tem os fundos para contratá-lo para o trabalho.

Supondo que todos os itens acima sejam verdadeiros, então eu diria que trabalhar com a solução parece bastante simples, certo? Precisamos auditar o site para que possamos:

• determinar o esquema de cores,
• encontre os seletores necessários para o CSS,
• então comece a construir o plugin.

Agora, quando se trata de fazer isso, ainda tento empregar um punhado de práticas recomendadas. Mesmo tendo tendência para a programação orientada a objetos, nem sempre a uso nem sempre a recomendo.

Em vez disso, acho que usar uma função simples ou um conjunto de funções conectadas à API do WordPress de maneira processual funciona bem. No entanto, isso não significa que não devemos ter como objetivo criar uma estrutura sólida de organização de arquivos porque você nunca sabe quando pode ter que voltar para manter o projeto.

Para esse fim, aqui está o que eu normalmente faço:

• crie um diretório de ativos para folhas de estilo e JavaScript (para ambos ou um dos outros – o que for necessário),
• crie um diretório src para o código que será responsável por se conectar ao WordPress,
• adicione o arquivo de bootstrap de LICENSE, README e plugin usual.

O diretório resultante pode ser algo assim:

A partir daí, nem me incomodo com um carregador automático. Em vez disso, incluo os arquivos no diretório de origem. Você pode percorrer esses arquivos versus fazer algo assim :

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

Mas isso pode depender de quando e o que você está fazendo.

Isso é muito simples

Pode ser. Aqui está a coisa: sempre que uma pessoa se enraíza no uso de um determinado paradigma de programação, essa pessoa tenta aplicá-lo em todos os lugares e tenta fazê-lo o tempo todo.

Nem todos, mas muitos. Eu mesmo incluído.

E quando você se encontra arquitetando algo em excesso, por que não dar um passo para trás e tentar tornar sua carga de trabalho um pouco mais simples?

O problema ainda está resolvido, e é feito de uma maneira que tem uma sobrecarga significativamente menor.