Jeśli pochodzisz ze środowiska zorientowanego obiektowo lub próbujesz budować wszystkie swoje rozwiązania dla WordPressa przy użyciu technik zorientowanych obiektowo, to będą chwile, w których może się wydawać, że wbijasz gwóźdź młotem kowalskim.
Załóżmy na przykład, że ktoś przychodzi do Ciebie i potrzebuje opracowanej niestandardowej wtyczki, która współpracuje z wtyczką innej firmy, ale musi zrobić tylko jedną rzecz.
Czy warto poświęcić czas na stworzenie interfejsu, implementację wspomnianego interfejsu w konkretnej klasie, skonfigurowanie subskrybentów, napisanie testów jednostkowych i tak dalej?
Widzę apel, ale generalnie mówię nie. Jeśli sednem tego, co musisz zrobić, jest uwzględnienie stylów lub plików JavaScript lub obu, to dlaczego nie polegać na natywnych interfejsach API WordPress i programowaniu proceduralnym?
Nie przesadzaj z inżynierią
Załóżmy, że przychodzi do Ciebie potencjalny klient, który:
- pracuje z bardzo napiętym budżetem,
- ma wtyczkę innej firmy, która nie pasuje do tego motywu,
- wymaga jedynie lekkiej stylizacji,
- i ma fundusze, aby zlecić ci pracę.
Zakładając, że wszystko powyższe jest prawdą, powiedziałbym, że rozwiązanie problemu wydaje się dość proste, prawda? Musimy przeprowadzić audyt witryny, abyśmy mogli:
- określić kolorystykę,
- znaleźć niezbędne selektory dla CSS,
- następnie zacznij budować wtyczkę.
Teraz, jeśli chodzi o to, nadal staram się stosować garść najlepszych praktyk. Mimo że mam tendencję do programowania obiektowego, nie zawsze go używam ani nie zawsze go polecam.
Zamiast tego myślę, że użycie prostej funkcji lub zestawu funkcji podłączonych do API WordPress w sposób proceduralny działa dobrze. Nie oznacza to jednak, że nie powinniśmy dążyć do stworzenia solidnej struktury organizacji plików, ponieważ nigdy nie wiadomo, kiedy będziesz musiał wrócić, aby utrzymać projekt.
W tym celu oto, co zwykle robię:
- utworzyć katalog assetów dla arkuszy stylów i JavaScript (dla obu lub jednego z nich – w zależności od tego, co jest konieczne),
- utworzyć katalog src dla kodu, który będzie odpowiedzialny za podpięcie się pod WordPressa,
- dodaj zwykły plik LICENSE, README i plik startowy wtyczki.
Wynikowy katalog może wyglądać mniej więcej tak:
Stamtąd nawet nie zawracam sobie głowy automatycznym ładowaniem. Zamiast tego dołączam pliki do katalogu źródłowego. Możesz iterować przez te pliki zamiast robić coś takiego :
<?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';
Ale to może zależeć od tego, kiedy i co robisz.
To jest zbyt proste
Może. Oto rzecz: za każdym razem, gdy ktoś ugruntuje się w używaniu określonego paradygmatu programowania, wspomniana osoba próbuje zastosować go wszędzie i próbuje to robić przez cały czas.
Nie wszyscy, ale wielu. Ja również.
A kiedy zauważysz, że coś przesadzasz, dlaczego nie cofnąć się o krok i spróbować nieco uprościć swoją pracę?
Problem jest nadal rozwiązany, i to w sposób, który ma znacznie mniejsze koszty.