Если у вас есть объектно-ориентированный опыт или вы пытаетесь создать все свои решения для WordPress с использованием объектно-ориентированных методов, то будут моменты, когда вам может показаться, что вы бьете по гвоздю кувалдой.
Например, предположим, что кто-то приходит к вам и нуждается в разработке собственного плагина, который работает со сторонним плагином, но он должен делать только одну вещь.
Стоит ли тратить время на создание интерфейса, реализацию указанного интерфейса в конкретном классе, настройку подписчиков, написание модульных тестов и т. д.?
Я вижу привлекательность, но обычно говорю нет. Если суть того, что вам нужно сделать, заключается в том, чтобы включить стили, файлы JavaScript или и то, и другое, то почему бы не положиться на собственные API-интерфейсы WordPress и процедурное программирование?
Не переусердствуйте
Допустим, к вам приходит потенциальный клиент, который:
- работает с очень ограниченным бюджетом,
- имеет сторонний плагин, который не подходит к этой теме,
- нужна только легкая укладка,
- и имеет средства, чтобы заключить с вами контракт на работу.
Если предположить, что все вышесказанное верно, то я бы сказал, что работа над решением кажется достаточно простой, верно? Нам необходимо провести аудит сайта, чтобы мы могли:
- определить цветовую гамму,
- найти необходимые селекторы для CSS,
- затем начните сборку плагина.
Теперь, когда дело доходит до этого, я все еще стараюсь использовать несколько лучших практик. Несмотря на то, что я склоняюсь к объектно-ориентированному программированию, я не всегда его использую и не всегда рекомендую.
Вместо этого я думаю, что использование простой функции или набора функций, подключенных к WordPress API процедурным образом, работает просто отлично. Однако это не означает, что мы не должны стремиться к созданию прочной структуры организации файлов, потому что вы никогда не знаете, когда вам, возможно, придется вернуться, чтобы поддержать проект.
Для этого я обычно делаю следующее:
- создайте каталог ресурсов для таблиц стилей и JavaScript (для обоих или одного из других — в зависимости от того, что необходимо),
- создайте каталог src для кода, который будет отвечать за подключение к WordPress,
- добавьте обычный файл LICENSE, README и загрузочный файл плагина.
Результирующий каталог может выглядеть примерно так:
Оттуда я даже не заморачиваюсь с автозагрузчиком. Вместо этого я включаю файлы в исходный каталог. Вы можете перебирать эти файлы, а не делать что-то вроде этого :
<?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';
Но это может зависеть от того, когда и что вы делаете.
Это слишком просто
Может быть. Вот в чем дело: всякий раз, когда человек укореняется в использовании определенной парадигмы программирования, этот человек пытается применять ее везде и пытается делать это все время.
Не все, но многие. Я в том числе.
И когда вы обнаружите, что слишком много занимаетесь архитектурой, почему бы не сделать шаг назад и не попытаться немного упростить свою рабочую нагрузку?
Проблема по-прежнему решена, и это делается таким образом, чтобы значительно сократить накладные расходы.