Якщо ви походите з об’єктно-орієнтованого фону або намагаєтесь створювати всі свої рішення для WordPress за допомогою об’єктно-орієнтованих методів, то іноді може здаватися, що ви б’єте кувалдою по цвяху.
Наприклад, припустимо, що хтось прийшов до вас і йому потрібен спеціальний плагін, який працює зі стороннім плагіном, але він має виконувати лише одну дію.
Чи варто витрачати час на створення інтерфейсу, реалізацію згаданого інтерфейсу в конкретному класі, налаштування передплатників, написання модульних тестів і так далі?
Я бачу апеляцію, але зазвичай кажу ні. Якщо суть того, що вам потрібно зробити, полягає в тому, щоб включити стилі або файли JavaScript, або те й інше, то чому б не покластися на рідні API WordPress і процедурне програмування?
Не надто розробляйте
Припустимо, до вас приходить потенційний клієнт, який:
- працює з дуже обмеженим бюджетом,
- має плагін третьої сторони, який погано підходить до теми,
- потребує лише легкого укладання,
- і має кошти, щоб укласти з вами контракт на роботу.
Якщо припустити, що все вищесказане вірно, то я б сказав, що робота над рішенням здається досить простою, чи не так? Нам потрібно перевірити сайт, щоб ми могли:
- визначити колірну гамму,
- знайти необхідні селектори для CSS,
- потім почніть створення плагіна.
Тепер, коли справа доходить до цього, я все ще намагаюся використовувати декілька найкращих практик. Незважаючи на те, що я схильний до об’єктно-орієнтованого програмування, я не завжди використовую його та не завжди рекомендую.
Натомість я думаю, що використання простої функції або набору функцій, підключених до API WordPress у процедурний спосіб, працює просто чудово. Однак це не означає, що ми не повинні прагнути створити надійну структуру організації файлів, тому що ви ніколи не знаєте, коли вам доведеться повернутися, щоб підтримувати проект.
З цією метою я зазвичай роблю ось що:
- створити каталог активів для таблиць стилів і 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';
Але це може залежати від того, коли і що ви робите.
Це надто просто
Може бути. Ось у чому річ: щоразу, коли людина починає використовувати певну парадигму програмування, вона намагається застосувати її скрізь і намагається робити це постійно.
Не всі, але багато. Я в тому числі.
І коли ви виявите, що щось надмірно проектуєте, чому б не зробити крок назад і спробувати трохи спростити своє робоче навантаження?
Проблема все ще вирішується, і це робиться таким чином, що має значно менше накладних витрат.