Om du närmar dig mycket WordPress-pluginutveckling ur ett objektorienterat perspektiv, kommer du så småningom att nå en punkt där du inte gör mycket interaktion direkt med själva WordPress-kärnan.
Och i mina ögon är det en bra sak. Det är ett tecken på en arkitektur att du strukturerar din kod korrekt. Det är:
- Du har WordPress på grundnivå,
- Du har en uppsättning klasser som sitter precis ovanför WordPress och ansvarar för att skicka information till och från WordPress mellan plugin,
- Och du har resten av din kod som omfattar resten av funktionaliteten.
Hur detta implementeras kan variera, men det allmänna sättet jag föreställer mig detta är på samma sätt som jag brukar tänka på standard N-tier- applikationen där du har datalagret, applikationslagret och front-end.
Förutom den här gången har du WordPress, ett lager för att kommunicera med WordPress och resten av din kod, och, du vet, resten av din kod.
Hur ett plugin kan organiseras.
Så vad händer när du vill stoppa körning av plugin när det måste interagera med ett tredjepartsberoende och bara ska köras om det beroendet finns?
Stoppa utförande av plugin
På grund av PHP och WordPresss natur finns det några sätt att göra detta på. Koden jag ska dela med mig av föreskriver inte hur man gör det.
Istället är detta ett sätt att göra det (som har hämtats från något som är under utveckling). Vidare kommer jag att visa hur det interagerar med några andra komponenter i plugins också.
1 Konstruktören
Om du läser tillräckligt många artiklar om WordPress och objektorienterad programmering, kommer du sannolikt att upptäcka att konstruktörer inte bör användas för att definiera krokar. Och jag håller med.
Det skapar en onödig nivå av koppling, och det gör att testa saker svårare. Vad är då syftet med en konstruktör i WordPress-baserad kod?
Jag använder det av samma skäl som du kan förvänta dig på alla andra språk: För att initiera klassens egenskaper. I koden nedan kommer du att se tre saker:
- Jag initierar en egenskap,
- Jag kontrollerar om det finns ett tredjepartsberoende,
- Om det inte gör det lägger jag till ett felmeddelande,
- Jag uppdaterar fastigheten.
Visst, det är utförligt, men det tar inte heller till smart kod för att initiera värden.
(Ju äldre jag har blivit, desto mer har jag blivit förtjust i specifik kod eftersom det gör det lättare att läsa, plocka upp och komma igång med i en snabbare takt än alternativet.)
2 Initieringsmetoden
Eftersom vi inte använder en konstruktor för att arbeta med WordPress-krokar, bör denna funktionalitet existera inom ramen för en annan metod.
Detta ger oss en dedikerad plats för att sätta den här typen av funktionalitet, frikoppla den från resten av klassen och få den att interagera med WordPress endast när metoden uttryckligen anropas.
Men kom ihåg att hela poängen med det jag kommer till har att göra med att stoppa exekveringen av ett plugin – inte var man ska placera krokar.
Så låt oss säga att tredjepartsberoendet inte existerar, vad då? Minns i konstruktorn sattes en egenskap som gör att vi kan avgöra om vi ska gå vidare med att sätta upp krokar eller inte:
Och när det är på plats kommer resten av koden inte att köras.
Många ord, lite kod
Det låter som en hel del förklaringar till så väldigt lite kod.
Men en del av detta är också att försöka förmedla betydelsen av att ha delar av ett WordPress-baserat projekt separerade från resten av kärnan så att delarna kan interagera med sig själva utan att uttryckligen behöva prata med kärnan hela tiden.