Organisera WordPress-inställningsskärmar
Eftersom många av oss fortsätter att gå vidare med PHP7+ kan vi fortsätta att dra nytta av många nya funktioner som språket erbjuder.
Men under tiden finns det fortfarande funktioner i PHP och relaterad programvara som vi kan använda för att effektivisera vår utveckling. Det minsta (och det som jag har skrivit och talat om lite) är namnrymder.
Men här är grejen: Jag gillar att ha mina plugins filer och kataloger strukturerade så att de är organiserade för att spegla namnutrymmeskonventionerna de följer. Och detta kan göras för taxonomier, metaboxar, domänobjekt, databasrelaterad funktionalitet och så vidare.
I det här inlägget vill jag dock prata om ett sätt att organisera WordPress-inställningsskärmar från både de logiska – det vill säga deras filsystemsplats – och de virtuella – det vill säga deras namnrymder – organisatoriska strukturer.
Organisera WordPress-inställningsskärmar
Den första punkten jag vill göra är denna: Även om jag pratar om att organisera WordPress-inställningsskärmarna, pratar jag ingenting om API:et. Anta istället att jag för det här inlägget talar om följande:
- en anpassad meny som har en associerad menysida,
- en menysida som återger kraven för en inställningssida (som nonce-fältet och så vidare)
- en del som innehåller de faktiska inställningarna (eller flera deldelar om du vill inkludera flera inställningar).
Jag kommer inte att prata om processen för sanering, serialisering, hämtning, validering och visning. Detta är rent organisatoriskt.
Att tänka igenom processen
Med tanke på att vi kommer att organisera våra filer genom kataloger som också mappar 1:1 med namnområden, låt oss fundera igenom exakt vad det är vi behöver. Så här närmar jag mig det:
- Vi skapar något specifikt för WordPress-applikationen. Detta indikerar ett namnområde.
- Vi kommer att skapa en administrationsmeny som innebär att vi både arbetar i administrationsområdet för WordPress, alltså ett annat namnområde, och med menyer, som är ett annat namnområde.
- Därefter behöver vi filer för att visa standardskärmen för WordPress så vi behöver ett namnområde Views,
- Och då behöver vi domänspecifik kod för att komma in i vyn så att vi i slutändan kommer att behöva en Partials-katalog (och därmed ett namnområde).
Så den slutliga, logiska organisationen av data skulle se ut ungefär så här:
Det kanske viktigaste att notera om denna speciella organisation av filer är att AdminMenu- klassen är en basklass från vilken alla specifika (eller mer konkreta) klasser kan ärva.
Detta innebär att klassen AcmeAdminMenu ärver vissa egenskaper och funktioner från den och sedan implementerar dess logik eller lägger till dess logik.
När du organiserar dina filer på det här sättet blir namnområdena nästan självklara, eller hur? Här är namnutrymmet för var och en av filerna:
- WordPressAdminMenuAdminMenu
- WordPressAdminMenuAcmeAdminMenu
- WordPressAdminMenuViewsSettings
- WordPressAdminMenyViewsSettingsDelar
Observera att eftersom acme-settings.php tekniskt sett bara är uppmärkning för renderingsalternativ, behöver den inte nödvändigtvis vara namnbredd eftersom den ingår i vyn som renderar den.
Oavsett, om du är ett fan av att hålla saker så organiserade som möjligt, är det bara vettigt att kapsla en del i en katalog som heter just det.
Vad sägs om kod?
Om du är intresserad av att se koden för något sånt här, funderar jag på att sätta ihop ett litet plugin som visar hur allt detta hänger ihop. Det här är trots allt lite hög nivå, eller hur? Jag menar att det inte finns någon implementering.
Återigen, om detta hjälper dig att peka i rätt riktning för ett pågående eller framtida projekt, kan det vara tillräckligt.