När ska man använda WordPress-subaktioner (och vad är de?)

Jag gick nyligen igenom processen med att använda en klasskonstruktor för att förhindra att ett plugin fungerar om det ett förväntat beroende inte laddas.

Även om jag inte anser att denna strategi är ett problem för ett engångsberoende eller i vissa situationer, finns det sätt som detta kan leda till kodlukt.

Det hindrar oss också från att använda en inbyggd funktion i Core som kallas WordPress-subactions:

https://twitter.com/JJJ/status/822265137935646720

Men innan jag tittar på subaktioner vill jag se till att jag är tydlig med problemen med att använda villkorsmetoden (versus subaktioner) kan föda med kodlukter.

WordPress Subactions

Det finns många sätt som kodlukter kan förklaras på, men mitt favoritsätt kommer från Martin Fowler :

… lukter är vissa strukturer i koden som indikerar brott mot grundläggande designprinciper och påverkar designkvaliteten negativt.

Det finns en annan bra sida om kodlukter på Source Making som jag rekommenderar att du läser om du har en chans.

Och sättet som villkor kan leda till kodlukt är enkelt: det har potential att beskräpa din kod med en enorm uppsättning uttalanden som inkluderar många class_exists- kontroller.

Och det är ett problem.

Varje gång du introducerar ett annat beroende i din kod, lägger du till ytterligare en villkorlig kontroll för att se om en klass finns i WordPress-applikationen.

Jag tror att det är okej att göra det här med ett enda beroende – kanske till och med två beroenden – och om du arbetar "tillräckligt högt" i din arkitektur, men det är inte hur du ska hantera det här med många beroenden eller på en lägre nivå i ditt plugin.

Det är där WordPress subactions kommer in i bilden. Du kan se en lista över subactions i tweeten via John ovan.

Det finns en officiell definition av underåtgärder i bbPress Codex också:

Dessa interna åtgärder kan ses som "underåtgärder" och låter dig lägga till eller omordna WordPress-åtgärder efter behov för plugins som är beroende av bbPress.

Och du kan se ett exempel på det i den här filen.

Visst, den här definitionen är specifik för bbPress, men det betyder inte att den inte är tillämplig på det vi gör i WordPress.

Exempel: Om du någonsin har använt do_action för att definiera en anpassad åtgärd, eller om du har utnyttjat en hook från någon annan utanför WordPress-kärnan, då är du bekant med strategin att implementera en delåtgärd.

Med andra ord är WordPress-underåtgärder helt enkelt åtgärder som vi kan använda för att ändra ordningen i vilken vårt plugin beror på ett annat plugin.

Hur detta implementeras kan variera inom ramen för ditt arbete, men det mest populära och mest "korrekta" WordPress-sättet att göra detta på är utan tvekan att dra fördel av prioritetsargumentet för när din plugin laddas.

Det vill säga, ta prioritet för beroendet och se till att det är tidigare än när din plugin aktiveras.

Det finns alternativa metoder som kan användas, som att ändra pluginbeteende närhelst de aktiveras eller inte, men detta ligger utanför omfattningen av det här inlägget, och det kan negativt förändra användarupplevelsen (för WordPress i allmänhet, inte mindre).

Oavsett vad är poängen att när det kommer till att använda WordPress-subaktioner, objektorienterad programmering och hantering av tredjepartsberoenden, se till att de beslut du fattar inte kommer att skada designen av din kod.

Om det är vettigt att kontrollera förekomsten av en klass, okej, men om det är mer meningsfullt att vänta tills en uppsättning klasser eller plugins har laddats före din egen, är WordPress-underåtgärder troligen mer meningsfulla.