Överkonstruera inte lösningen
Om du kommer från en objektorienterad bakgrund eller försöker bygga alla dina lösningar för WordPress med hjälp av objektorienterade tekniker, kommer det att finnas tillfällen då det kan kännas som att du slår en spik med en slägga.
Låt oss till exempel säga att någon kommer till dig och behöver utveckla ett anpassat plugin som fungerar med ett tredjeparts plugin men det behöver bara göra en sak.
Är det värt att ta sig tid att skapa ett gränssnitt, implementera nämnda gränssnitt i en konkret klass, ställa in prenumeranter, skriva enhetstester och så vidare?
Jag kan se överklagandet, men jag säger generellt nej. Om kärnan i vad du behöver göra måste inkludera stilar eller JavaScript-filer eller båda, varför inte lita på de inbyggda WordPress API:erna och procedurprogrammering?
Överkonstruera inte
Låt oss säga att en potentiell kund kommer till dig som:
- arbetar med en mycket snäv budget,
- har ett plugin från tredje part som inte passar bra med temat,
- behöver bara lätt styling,
- och har pengar för att anlita dig för arbetet.
Förutsatt att allt ovanstående är sant, skulle jag säga att det verkar enkelt att arbeta igenom lösningen, eller hur? Vi måste granska webbplatsen så att vi kan:
- bestämma färgschemat,
- hitta nödvändiga väljare för CSS,
- börja sedan bygga plugin-programmet.
Nu när det gäller att göra detta försöker jag fortfarande använda en handfull bästa praxis. Även om jag tenderar mot objektorienterad programmering, använder jag det inte alltid och rekommenderar det inte alltid.
Istället tror jag att det fungerar bra att använda en enkel funktion eller uppsättning funktioner kopplade till WordPress API på ett procedurmässigt sätt. Det betyder dock inte att vi inte bör sträva efter att skapa en solid filorganisationsstruktur eftersom du aldrig vet när du kan behöva komma tillbaka för att underhålla projektet.
För det ändamålet är det här vad jag normalt gör:
- skapa en tillgångskatalog för stilmallar och JavaScript (för båda eller en av de andra – beroende på vad som är nödvändigt),
- skapa en src- katalog för koden som kommer att ansvara för att ansluta till WordPress,
- lägg till den vanliga LICENS-, README- och plugin-bootstrap-filen.
Den resulterande katalogen kan se ut ungefär så här:
Därifrån bryr jag mig inte ens om en autoloader. Istället inkluderar jag filerna i källkatalogen. Du kan iterera genom dessa filer jämfört med att göra något så här :
<?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';
Men det kan bero på när och vad du gör.
Det här är för enkelt
Kanske. Så här är det: Närhelst en person blir förankrad i att använda ett visst programmeringsparadigm, försöker personen att tillämpa det överallt och försöker göra det hela tiden.
Inte alla, men många. Jag själv inklusive.
Och när du kommer på att du överarbetar något, varför inte ta ett steg tillbaka och försöka göra din arbetsbörda lite enklare?
Problemet är fortfarande löst, och det görs på ett sätt som har betydligt mindre omkostnader.