Aangepaste WordPress-beheerpagina's maken, deel 4

Terwijl we beginnen aan het laatste artikel in de serie over het maken van aangepaste WordPress-beheerpagina's in WordPress, denk ik dat het belangrijk is om te herhalen dat dit niet bedoeld is om te zeggen dat we de Settings API (of een van de native API's) zouden moeten omzeilen. 

In feite heeft elke API zijn plaats, en we gebruiken er natuurlijk veel van via deze code. Maar er zijn waarschijnlijk tijden waarin u werkt aan een aangepaste plug-in of een aangepaste toepassing en u moet een beetje van uw eigen aangepaste validatie, serialisatie, routering enzovoort kunnen implementeren.

En dat is wat we in deze serie hebben gedaan. Dus naarmate we verder gaan met het voltooien van onze plug-in, wil ik ervoor zorgen dat u begrijpt dat ik niet voorstander ben om een ​​van de native API's te omzeilen. Ik pleit voor het gebruik van welke API's beschikbaar zijn voor de vereisten van uw project.

Voor uw beoordeling

Op dit punt ga ik ervan uit dat je de vorige artikelen hebt gelezen. Als dit niet het geval is, zal het u waarschijnlijk moeilijk begrijpen waar we vandaan komen en waarom we een aantal beslissingen nemen die we nemen met betrekking tot code.

Bovendien mis je sommige van de principes die we eerder hebben besproken. Kortom, ik raad aan een inhaalslag te maken en vervolgens terug te keren naar dit artikel.

Voor we beginnen

Met dat gezegd (en gesproken over vereisten), zijn er nog een paar dingen die we moeten afronden in verband met deze plug-in.

Concreet moeten we:

• haal de informatie uit de database
• valideer de informatie
• toon het op het dashboard
• toon de informatie op de voorkant

Gelukkig is het grootste deel van het werk voor ons gedaan. We hebben alle informatie die we nodig hebben in de database. Op dit punt is het een kwestie van functionaliteit introduceren do iets met die gegevens.

Zoals gewoonlijk neem ik aan dat je de nieuwste versie van de broncode hebt en je bent klaar om door te gaan met deze serie en het resterende stukje code toe te voegen. 

Met dat gezegd, laten we aan de slag gaan.

De plug-in voltooien

Voordat we beginnen met het schrijven van code, wil ik duidelijk maken dat de code die we gaan schrijven rechttoe rechtaan is, maar er is een mate van refactoring die we misschien moeten introduceren zodra we zover zijn dat we de informatie beschikbaar stellen over zowel de back-end en de front-end.

Dat is een goede zaak.

Het geeft ons niet alleen een kans om kritisch na te denken over de organisatie van onze code, maar het zal ons ook blootstellen aan een aantal aanvullende object-georiënteerde technieken die we tot nu toe niet in de tutorialserie hebben gezien.

Met dat in gedachten, laten we werken aan het ophalen van de informatie uit de database.

Informatie ophalen uit de database

Het grijpen van de informatie uit de database is een eenvoudig proces. Omdat we eerder met functies zoals hebben gewerkt update_option, dit zou heel gemakkelijk moeten zijn. 

We gaan ermee werken get_option. Het vereist slechts één enkel argument, en dat is de ID of de sleutel die we hebben gebruikt om de informatie op te slaan. In ons geval is dat zo tutsplus-maat-data. Als u creatief wilt worden, kunt u een optioneel tweede argument doorgeven dat wordt geretourneerd als de informatie niet wordt gevonden.

Om te laten zien hoe dit kan worden gebruikt, zal ik de functie een lege reeks laten retourneren, zodat we die hebben iets geldig om aan de gebruiker te tonen (zelfs als het niets is). Het codefragment om dit te doen ziet er als volgt uit:

Maar dit roept twee vragen op:
 
Waar komt dit vandaan (vooral als we dit op twee plaatsen in de plugin gaan weergeven)?
 
Moeten we deze informatie niet valideren?
 
We zullen de eerste vraag een beetje later in de tutorial bekijken. Laten we eerst eens praten over validatie.
Valideer de informatie
Over validatie valt veel te zeggen in WordPress. Maar om deze tutorial zo rechtlijnig mogelijk te houden, gaan we het hebben over inputvalidatie. We hebben tenslotte te maken met gebruikersinvoer via een invoer element, dus het is logisch.
Je kunt er alles over lezen in de Codex, maar inputvalidatie wordt vaak gedefinieerd als het volgende:
Gegevensvalidatie is het proces om ervoor te zorgen dat een programma werkt op schone, correcte en bruikbare gegevens.
In het laatste artikel bespraken we het onderwerp van sanitering, wat er in feite op neerkomt dat gegevens schoon zijn voordat ze in de database worden ingevoegd. Evenzo is validatie ervoor te zorgen dat het voor onze gebruikers schoon, veilig en leesbaar is.
Daarom is het niet genoeg net om de informatie uit de database te halen. We moeten het ook valideren. In het geval van onze plug-in zijn de gegevens eenvoudig genoeg zodat het lijkt alsof u te veel informatie nodig hebt om het te valideren; het doel van de oefening is echter om de mindset te helpen ontwikkelen voor hoe we moeten omgaan met opschonen, opslaan, terugvinden, valideren en weergeven van gegevens.
Validatietechnieken
En net zoals het geval is met ontsmetting, biedt WordPress een aantal functies die validatie eenvoudig maken, vooral omdat deze betrekking heeft op invoervalidatie. In deze situatie kunnen we zo agressief zijn als we willen. 
In ons geval is het misschien genoeg om het te gebruiken esc_attr bij het weergeven van de opties. Als we gebruikers toestemming hebben gegeven om in te voeren ieder type HTML, dan willen we misschien gebruiken wp_kses.
De laatste functie kan een zelfstudie vereisen, vooral als je WordPress nog niet kent, dus we blijven bij de eerste voor onze doeleinden.
deserialisatie
Eerder in het project creëerden we een klasse specifiek voor het opslaan van informatie in de database. We hebben deze klasse gebeld serializer. Voor degenen die zich niet precies herinneren wat het doet:
 
De klasse definieert een functie die op de brandt admin_post haak en slaat de informatie op die naar de server wordt verzonden.
 
De functie controleert of de informatie veilig kan worden opgeslagen en de gebruiker heeft toestemming om in de database op te slaan.
 
De functie zuivert de gegevens en schrijft deze naar de database.
 
Maar we willen die klasse niet overladen met een verantwoordelijkheid die niet logisch is. En aangezien we deze informatie zowel op de optiespagina als op de voorkant van de site zullen weergeven, zou het logisch zijn dat we een klasse hebben voor het deserialiseren van de waarde en toegankelijk maken voor de hele WordPress-applicatie..
Dus maak in de hoofdmap van uw plugin-map een gedeelde map en voeg een bestand toe met de naam class-deserializer.php.
Vervolgens willen we dat onze code zo wordt ingesteld dat deze:
 
is gebaseerd op objectgerichte principes
 
haalt de informatie op waarvoor deze wordt gevraagd
 
valideert de informatie
 
stuurt het terug naar de beller
 
Daartoe kan het initiële skelet van de klasse er ongeveer zo uitzien:
Het is eenvoudig, voor de zekerheid. We zullen tijdens deze zelfstudie meer code toevoegen, maar onthoud het principe van de enkele verantwoordelijkheid, en dit is een klasse die moet worden gebruikt tussen twee delen van de WordPress-applicatie..
Merk op dat we in de bovenstaande code drie functies hebben gedefinieerd. Laten we bespreken wat iedereen gaat doen:
 get_value zal de inkomende optiesleutel gebruiken die in ons geval is tutsplus-maat-data, en zal de waarde teruggeven aan de beller. Volgens de coderingsstandaarden van WordPress moeten we 'laattijdig ontsnappen' gebruiken om ervoor te zorgen dat we de informatie correct valideren. We zullen dit even zien spelen.
Met dat gezegd, laten we doorgaan en de functies uitstippelen. Ik zal ook PHP DocBlocks geven om uit te leggen wat elke functie doet.
Op dit punt moet de bovenstaande code gemakkelijk te volgen zijn, gezien de hierboven opgesomde punten en de opmerkingen in de code.
Toon het op de pagina Opties
Om dit te laten zien op de pagina met opties, moeten we opnieuw kijken naar de manier waarop we de Submenu_Page in de custom-admin-settings.php het dossier. In het bijzonder moeten we de deserializer instantiëren en doorgeven aan de constructor van de Submenu_Page.
Eerst moeten we het bestand opnemen. Dit kan gebeuren direct nadat we hebben gecontroleerd of het bestand met de primaire plug-in rechtstreeks is geopend:
De code in de hoofdfunctie van de root van de plug-in ziet er nu als volgt uit:
in het(); $ deserializer = nieuwe Deserializer (); $ plugin = nieuw Submenu (nieuw Submenu_Page ($ deserializer)); $ Plugin-> init (); 
En dan de constructor voor de Submenu_Page zou er als volgt uit moeten zien:
deserializer = $ deserializer;  
Vanaf hier kunnen we de optiespagina aanpakken. We werken gewoon het waarde attribuut door een oproep te doen naar de functie in de deserializer. Onthoud dat, aangezien we onvoorwaardelijk de waarde terughalen en uiteindelijk een lege string retourneren als niets bestaat, het prima zou moeten werken.
 Welk bericht wilt u boven elk bericht weergeven?? 
  
En daarmee zou je in staat moeten zijn om je waarde op de optiespagina op te slaan en op te halen.
Toon het aan de voorkant
We zijn bijna klaar. Het laatste wat we moeten doen is de plug-in instellen om het aangepaste bericht aan de voorkant weer te geven. In het bijzonder willen we weergeven wat de gebruiker heeft ingevoerd op de enkele berichtpagina (versus een archiefpagina of een ander type pagina) en dit boven elk bericht doen.
Dit betekent dat we het volgende moeten doen:
 
Stel een functie in die de haak hook__ontent gebruikt.
 
Lees de waarde met behulp van onze deserializer.
 
Maak de waarde vóór de inhoud vooraf (misschien in zijn eigen element).
 
Gelukkig is dat niet zo dat veel werk, vooral omdat we het meeste werk hebben dat we nodig hebben om te beginnen. Toch moeten we een deel van de plug-in maken dat specifiek verantwoordelijk is voor het omgaan met de front-end van de site.
Maak hiervoor een openbaar map in de hoofdmap van uw plugin-map en voeg toe class-inhoud messenger.php.
In de klas moeten we een constructor definiëren die de deserializer als een afhankelijkheid accepteert. De constructor (en de benodigde eigenschap) zou er als volgt uit moeten zien:
deserializer = $ deserializer; 
Dan moeten we een maken in het functie die een interne functie registreert (die we zullen bellen tonen) om de inhoud samen met het nieuwe bericht weer te geven.
Hierna moeten we het hoofdinvoegbestand bijwerken zodat het onze nieuwe klasse instantiseert en de deserializer doorgeeft aan de constructor. Vervolgens wordt de klas geïnitialiseerd.
Eerst voegen we het toe:
Dan zullen we het instantiëren:
in het(); 
Vanaf hier zouden we klaar moeten zijn om te gaan. Zorg ervoor dat u een waarde hebt ingevoerd op de pagina met opties. Sla uw werk op en bekijk een enkele berichtpagina op uw site. Het zou er ongeveer zo uit moeten zien:
Als dit niet het geval is, vergelijk dan uw code met wat hierboven staat (of wat is bijgevoegd) en zorg ervoor dat u al uw klassen, functies en haken correct hebt ingesteld.
Een woord over weergaven en afhankelijkheden
Hoewel we in deze reeks over het beginsel van één verantwoordelijkheid hebben gesproken, hebben we eigenlijk niet veel gesproken over geavanceerdere onderwerpen die we zouden kunnen gebruiken om de code nog schoner te maken en betere werkwijzen te volgen.
Sommige van deze onderwerpen omvatten dingen zoals PHP-autoloading en dingen zoals afhankelijkheidsinjectie. Ik heb hier nog niet over gesproken omdat ze buiten de kern van het onderwerp vallen en het primaire doel van deze serie is om les te geven.
Afhankelijk van hoe deze specifieke serie is ontvangen, overweeg ik om zelf een aantal tutorials over deze onderwerpen te maken.
Conclusie
En daarmee besluiten we de serie over het maken van aangepaste beheerpagina's. Ik hoop dat je in deze serie een aantal dingen hebt geleerd die verder gaan dan de standaardmanier voor het maken van beheerpagina's.
Daarnaast hoop ik dat je hebt gezien hoe je een paar softwareontwikkelingstechnieken kunt toepassen in je dagelijkse werk met WordPress. Verder hoop ik dat de discussie over opvattingen en afhankelijkheden ook tot meer geavanceerde onderwerpen heeft geleid. Dit zijn dingen die ik hoop te behandelen in toekomstige tutorials.
Zoals gewoonlijk zie je mijn cursussen en tutorials op mijn profielpagina, en je kunt me volgen op mijn blog en / of Twitter op @tommcfarlin, waar ik het heb over verschillende softwareontwikkelingspraktijken en hoe we ze in WordPress kunnen gebruiken..
Vergeet niet om de code te downloaden in de zijbalk van dit bericht, het te bekijken, ermee te spelen en te zien wat u kunt doen om het uit te breiden en uw eigen functionaliteit eraan toe te voegen. Zoals gewoonlijk, aarzel niet om me te contacteren via de opmerkingen over de tutorial.
Middelen
 
De instellingen-API
 
De complete gids voor de instellingen-API
 
update_option
 
get_option
 
Validatie van invoer
 
Gegevensvalidatie
 
esc_attr
 
wp_kses
 
admin_post
 
Single Responsibility Principle
 
Late ontsnapping
 



		
			
	   
	




Code