Share
Zoals we hier meerdere malen op WP Tuts hebben vermeld (en zoals je ongetwijfeld hebt opgemerkt), is er nooit een betere tijd geweest om een WordPress-ontwikkelaar te zijn. Of het nu gaat om klantwerk of productontwikkeling (met thema's of plug-ins), aan de slag gaan in het WordPress-ecosysteem is bijna meer een kwestie van 'waar' dan van 'hoe'.
WordPress heeft geweldige API-documentatie voor ontwikkelaars, ongeacht het ervaringsniveau. Maar een actieve ontwikkelingsgemeenschap en een goed gedocumenteerde API maken een platform niet immuun voor slechte ontwikkelingspraktijken.
Zoals met de meeste aspecten van webontwikkeling, betekent het feit dat iets werkt niet dat het op de juiste manier is gebouwd. Maar als ontwikkelaars en vakmensen hebben we de taak ervoor te zorgen dat het werk dat we vrijgeven, werkt en correct is gebouwd. Als je de broncode voor verschillende thema's of plug-ins doorbladert, laat dit zien dat ontwikkelaars producten vrijgeven die werken, maar die niet op de best mogelijke manier zijn ontworpen. Dit geldt met name voor thema-opties, menupagina's, validatie, enzovoort.
En dat willen we stoppen.
In deze serie gaan we een duik nemen in de WordPress Settings API. We gaan kijken naar wat het is, waarom het ertoe doet en hoe we het kunnen gebruiken in ons werk.
Ons uiteindelijke doel is dat deze reeks een solide referentie is voor de instellingen-API achteloos van je niveau van ervaring. Uiteindelijk moet u een duidelijk beeld hebben van de API en solide voorbeelden van hoe u de dingen op de juiste manier kunt doen.
Om compleet te zijn, moeten we beginnen bij ground zero. Dus voordat we een code schrijven of voorbeelden doornemen, moeten we de Settings API introduceren, wat het is en waarom het ertoe doet.
Op het meest basale niveau is de instellingen-API een verzameling functies die wordt aangeboden door WordPress en die het proces vereenvoudigt van het introduceren van menu's, optiepagina's en het opslaan, valideren en ophalen van gebruikersinvoer.
Makkelijk genoeg, toch?
In deze serie duiken we elk aspect in, maar dit zou een eenvoudige definitie moeten geven waarvan we de rest van de artikelen kunnen gebruiken..
Nu begrijpen we wat de instellingen-API eigenlijk is is, we moeten kijken waarom we dit zouden willen gebruiken in tegenstelling tot de invoer van gebruikers, serialisatie en validatie allemaal alleen.
De Settings API wordt geleverd door de ontwikkelaars van het WordPress Platform om het eenvoudig te maken om de applicatie uit te breiden. Als zodanig zou het niet logisch zijn om de functies te gebruiken die door de auteurs van het platform zelf worden geboden?
Natuurlijk is het volledig mogelijk om deze functies te omzeilen en onze eigen functionaliteit "brute force" en niemand anders kan het echt stoppen, maar dit vereist onnodig werk voor ons, negeert aanbevelingen van het WordPress Core-team en kan uiteindelijk de samenhangende ervaring doorbreken van het Dashboard.
Kiezen om gebruik te maken van de functionaliteit die wordt geboden voor ontwikkelaars door ontwikkelaars zorgt ervoor dat we op de juiste manier communiceren met de kernapplicatie.
Het gebruik van de instellingen-API gaat er niet alleen om ervoor te zorgen dat we de ontwikkeling benaderen via de aanbevolen kanalen. Het gaat er ook om ervoor te zorgen dat onze gebruikersinterfaces de beste werkwijzen van het platform volgen en dat onze gegevens worden opgeschoond met behulp van dezelfde mechanismen die de rest van WordPress gebruikt. Het doet geen pijn dat het ons ook veel tijd kan besparen.
Wanneer u begint met het uitbouwen van uw interfaces op een zodanige manier dat ze gebruik maken van bestaande WordPress-stijlen en de Settings API gebruiken, zal uw werk veel strakker worden geïntegreerd met de rest van het systeem.
Dit betekent dat wanneer gebruikers uw werk beginnen te gebruiken, ze niet het gevoel hebben dat ze een hulpprogramma van derden gebruiken wanneer ze met hun blog werken. In plaats daarvan werken ze met een verbetering (in tegenstelling tot, laten we zeggen, een toevoeging) aan het kernplatform.
Toegegeven, het gebruik van native WordPress-stijlen is geen echt onderdeel van de Settings API en het bovenstaande is enigszins een subjectief perspectief, maar aspecten van de Settings API - zoals het introduceren van menupagina's - maken gebruik van native WordPress-stijlen. Is het dan niet logisch dat de rest van je werk dit voorbeeld volgt??
Door gebruik te maken van functies die eigen zijn aan WordPress in plaats van uw eigen functies te gebruiken, kunt u er zeker van zijn dat instellingen voor opslaan, ophalen en valideren correct worden beheerd. De Settings API biedt immers veel van dezelfde functionaliteit waarop de kernapplicatie vertrouwt.
Bovendien is de instellingen-API onderworpen aan dezelfde regels als de rest van de WordPress-API. Als zodanig, wanneer de applicatie wordt bijgewerkt en / of wijzigingen worden geïntroduceerd, zullen de functies het gebruikelijke afnameproces moeten doorlopen. Dit geeft u voldoende tijd om te werken aan het upgraden van uw project voordat de compatibiliteitsonderbrekingen zijn doorgevoerd. Dit is niet noodzakelijk het geval als u uw eigen functionaliteit wilt gebruiken.
Op dit punt moet u een duidelijk beeld hebben van wat de instellingen-API is en waarom u deze zou moeten gebruiken bij het werken met thema's en plug-ins.
Natuurlijk is dit allemaal een beetje argumentatief - we moeten eigenlijk praktische voorbeelden bekijken. In de rest van deze serie zullen we het volgende bekijken:
Aan het einde van de serie zou je alles moeten hebben dat je nodig hebt om te beginnen met het maken van solide WordPress-gebaseerde producten.
Accentsconagua