Share
In deze serie hebben we gekeken naar hoe u aangepaste beheerpagina's kunt maken in WordPress zonder de Settings API te gebruiken. Dit wil niet zeggen dat de Settings API niet nuttig is (omdat het zo is!), Maar er kunnen momenten zijn waarop we een aangepaste functionaliteit of meer gespecialiseerde implementaties van functies moeten implementeren die de beschikbare API's niet betalen.
Daarnaast bekijken we enkele van de belangrijkste principes voor softwareontwikkeling, zoals het principe van de enkele verantwoordelijkheid, en deze toe te passen op ons werk.
Als je nu net meedoet met de serie, raad ik je aan de vorige berichten te lezen, zodat je bekend bent met wat we tot nu toe gedaan hebben en zodat je begrijpt waarom we een aantal beslissingen nemen die we zijn maken bij het schrijven van onze code.
Hoewel ik niet alles kan samenvatten wat we tot nu toe in de serie hebben besproken, kan ik ervoor zorgen dat ik de belangrijke punten benadruk.
Accentsconagua
invoer element is toegevoegd dat de invoer van gebruikers accepteert.Met dat gezegd zijnde, neem ik aan dat je de laatste versie van de broncode hebt (die als bijlage in het vorige artikel beschikbaar is) en je bent klaar om verder te gaan.
Net als bij de andere artikelen, neem ik aan dat u een lokale WordPress-ontwikkelingsomgeving op uw computer hebt ingesteld.
Verder neem ik aan dat je de nieuwste versie van de broncode hebt en je bent klaar om er verder bovenop te bouwen of je bent vertrouwd met het lezen van de code die we hier hebben en het implementeren wanneer je meer tijd hebt.
Ten slotte zullen we stap voor stap door elk stukje code stappen. Eerst zal ik praten over wat we gaan doen, dan zal ik de code laten zien, en dan zal ik uitleggen wat het ook is dat de code aan het doen is zodat er niets meer overblijft dat verwarrend kan zijn.
Als je echter verward raakt over alles in de code en de tutorial niet goed uitlegt wat er aan de hand is, laat dan een reactie achter en ik zal zeker een follow-up van je maken.
Laten we beginnen.
In het laatste artikel zijn we gestopt met een plug-in die looks alsof het iets doet, maar eigenlijk niets in de database opslaat, laat staan dat er iets uit de database wordt opgehaald.
Kortom, we hebben een plug-in die er functioneel uitziet maar dat niet is. En dat is waar we heen gaan met deze tutorial.
Concreet gaan we de volgende onderwerpen aanpakken:
Daarmee zijn we klaar om terug te gaan naar de code en verder te werken aan de plug-in.
Terugroepen van de vorige post, hebben we geprofiteerd van de WordPress API-functie wp_nonce_field. Deze specifieke functie doet het volgende:
Het veld nonce wordt gebruikt om te valideren dat de inhoud van het formulierverzoek afkomstig was van de huidige site en niet van een andere locatie. Een nonce biedt geen absolute bescherming, maar zou in de meeste gevallen moeten beschermen. Het is erg belangrijk om nonce-velden in formulieren te gebruiken.
Als u de optiepagina probeert op te slaan, krijgt u waarschijnlijk een wit scherm te zien. Dat is nooit goed, maar het is wat we verwachten gezien de huidige staat van onze plug-in.
We moeten een functie introduceren die in een van de beschikbare WordPress-hooks kan worden gehaakt, en zal controleren of de nonce-waarde geldig is. Als het is geldig, dan laat het ons verder gaan met het opslaan van de informatie; anders zouden we niet door moeten gaan.
Omdat we bezig zijn met het maken van een aangepaste beheerpagina, hebben we een andere haak nodig dan we in situaties als deze gewend zijn. In dit voorbeeld gaan we de gebruiken admin_post haak.
Vuurt op een geverifieerd verzoek om een beheerderspost wanneer er geen actie is geleverd.
Bedenk echter uit onze vorige discussies dat we onze lessen niet met meer verantwoordelijkheid dan nodig willen overbelasten. Bedenk dat de vraag die we onszelf constant moeten stellen is: "Welke reden zou deze klasse moeten veranderen?"
Op dit moment hebben we geen klasse die opslagopties kan beheren. Dus laten we er een introduceren. Laten we in de beheerdersdirectory van de plug-in een maken serializer klasse. Dit zal verantwoordelijk zijn voor het opslaan van de waarde van onze opties.
Zoals je kunt zien, heb ik mijn bestand een naam gegeven class-serializer.php. We weten uit ervaring en uit de bovenstaande code dat het nodig is om in te loggen in de admin_post haak hierboven genoemd, en we weten dat we een functie nodig hebben die verantwoordelijk is voor het opslaan van de informatie.
Laten we die nu definiëren.
Vanzelfsprekend is er nog steeds werk aan de winkel (we hebben zelfs deze klasse niet geïnstantieerd!) Maar de bovenstaande code zou genoeg kunnen zijn om te zien waar we naartoe gaan.
Een snel gesprek over afhankelijkheden
Voordat we enige functionaliteit toevoegen, laten we beginnen en dit instellen wanneer onze plug-in voor het eerst wordt geladen. Geef eerst de
custom-admin-settings.php. Nu moeten we ons afvragen of een van onze bestaande klassen de Serializer als een afhankelijkheid moet hebben.Ik denk dat er een geval kan worden gemaakt dat de
Submenu_Pagemoet een verwijzing naar de serializer bevatten, omdat de pagina de opties heeft om op te slaan.Als alternatief is het ook mogelijk om dit bestand volledig gescheiden te laten en beschikbaar te hebben voor een ander patroon. Als we dat zouden doen, zouden we afwijken van het onderwerp. Hoewel ik denk dat het belangrijk is, valt het buiten het bereik van wat we willen bereiken.
Dus laten we de
serializerklasse, initialiseer het en geef het vervolgens door aan de constructor van de submenupagina. De code in het opstartbestand van de plug-in moet er nu als volgt uitzien:in het(); $ plugin = nieuw Submenu (nieuw Submenu_Page ($ serializer)); $ Plugin-> init ();Daarmee zijn we klaar om door te gaan met het opslaan van onze opties.
Terug naar ontwikkeling
Laten we terugkeren naar de
serializer. Nu we het hebben aangesloten op de rest van de plug-in, is het tijd om code te schrijven, dus volgens de opmerking laten we de nonce-waarde controleren die we aan de voorkant hebben gemaakt.Gelukkig maakt WordPress dit eenvoudig dankzij een ingebouwde API-functie:
wp_verify_nonce. Deze functie accepteert twee argumenten:
- De actie
- De naam
Als je je herinnert uit het vorige artikel, hebben we dat gebruikt
acme-settings-saveals onze actie enacme-maat-berichtals onze nonce-waarde. Om dit te valideren, moeten we controleren of het bestaat in de$ _POSTverzameling en dat het de native checks van WordPress passeert.Om dit te doen, maak ik graag een
privaatmethode waarmee ik deze logica kan inkapselen in een functie die ik kan gebruiken in deopslaanfunctie die we hierboven hebben gedefinieerd.Als ik klaar ben, kan ik een oproep naar deze functie opnemen die ons in staat stelt om de geldigheid van de inzending te controleren en ofwel de routine te verlaten of door te gaan naar de volgende controle (die we tijdelijk zullen bereiken).
Merk op dat het simpelweg retourneren van false in deze conditionele geen geschikte manier is om dit aan te pakken. In plaats daarvan zou het schoner zijn om een foutmelding te geven die op het WordPress-dashboard wordt weergegeven. Dit is iets dat we in een toekomstige tutorial opnieuw zullen bekijken.
Voorlopig willen we er echter vooral voor zorgen dat we gegevens met succes kunnen indienen. Dit brengt ons bij het volgende deel van onze code.
Toestemming
Hoewel het nummer dat eenmaal is gebruikt (of de nonce) -validatie is uitgecheckt, is er nog één ding dat we moeten controleren: we moeten ervoor zorgen dat de huidige gebruiker toestemming heeft om de gegevens op te slaan.
Voor onze doeleinden willen we ervoor zorgen dat de huidige gebruiker een beheerder is. Om dit te doen, kunnen we kijken naar de mogelijkheden van de huidige gebruiker (u kunt zien dat deze pagina een referentie biedt voor elke rol en de bijbehorende mogelijkheden).
Merk op dat een van de mogelijkheden van de administratie is om opties te beheren. We kunnen nu de WordPress API-functie gebruiken
current_user_canom te controleren of de huidige gebruiker de opties op deze pagina kan opslaan.Maar eerst roept dit de vraag op: als de gebruiker geen opties kan opslaan, waarom zouden ze dan toegestaan worden om de pagina daadwerkelijk te zien?
Als je eerder teruggrijpt in de serie, hebben we het volgende stukje code geschreven:
submenu_page, 'render'));Dit zorgt ervoor dat de optiespagina is alleen beschikbaar voor beheerders; we willen echter extra voorzichtig zijn en dit ook controleren tijdens ons serialisatieproces.
Nu kunnen we de voorwaarde bijwerken waarin we ook de nonce-waarde controleren om ook de toestemming van de huidige gebruiker te controleren:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: geeft een foutmelding weer. // Sla de optie op als het bovenstaande geldig is.Nu we de code hebben ingesteld om zeker te zijn dat de nonce-waarde is ingesteld en dat de huidige gebruiker de waarde kan opslaan, kunnen we verder gaan met sanering.
Onthoud, wij zullen terugkeren naar de plaats waar het zegt dat we een foutmelding moeten weergeven. Maar dat staat niet in deze tutorial.
sanering
"Maar wacht," zegt u. "Ik dacht dat we ons klaarmaakten om de optie te redden!" Dat is zo, maar voordat we dat kunnen doen, moeten we een proces van ontsmetting doorlopen. Kort gezegd, ontsmetting is het idee om ervoor te zorgen dat de gegevens schoon, veilig en, ahum, sanitair voor de database.
Simpel gezegd, het voorkomt dat kwaadwillende gebruikers informatie invoegen in de database die uiteindelijk een negatieve invloed zou kunnen hebben op onze site.
Gelukkig biedt WordPress een mooie hulpfunctie waarmee we ervoor kunnen zorgen dat dit zo eenvoudig mogelijk is. Voor geïnteresseerden kunt u alles lezen over validatie en sanering van gegevens (hoewel we in de volgende zelfstudie naar validatie zullen kijken).
In onze code gaan we gebruiken
sanitize_text_field(zoals hierboven gelinkt). Deze functie doet het volgende:
Best leuk om dit ter beschikking te hebben, toch? Laten we dit aan het werk zetten. Om dit te doen, zoek de opslaan functie waarmee we hebben gewerkt en update deze zodat het er zo uitziet:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: geeft een foutmelding weer. // Als het bovenstaande geldig is, reinigt u de optie en slaat u deze op. if (null! == wp_unslash ($ _POST ['acme-bericht'])) $ value = sanitize_text_field ($ _POST ['acme-bericht']); update_option ('tutsplus-custom-data', $ waarde); Merk op dat we de invoer van de $ _POST verzamelen, het opschonen en vervolgens het resultaat opslaan in een afzonderlijke variabele. Vervolgens wordt die variabele naar de database geschreven met behulp van de update_option functie.
Voor dit artikel kies ik voor het gebruik van de sleutel tutsplus-maat-data. Wat je ook gebruikt, het is belangrijk dat het wordt voorafgegaan door iets unieks zodat een andere plug-in of een ander thema de optie niet overschrijft en je een bestaande optie niet overschrijft.
Ten slotte moeten we terugleiden naar de optiespagina. Omdat we geen ingebouwde API gebruiken, moeten we een functie schrijven om dit voor ons te doen. Gelukkig is het heel gemakkelijk.
Maak eerst een functie met de naam redirect en zorg ervoor dat het er zo uitziet:
De code hierboven moeten zelfverklarend zijn, maar om zeker te zijn dat het duidelijk is, doet het het volgende:
- Het controleert of een persoonlijke WordPress-waarde aanwezig is in de
$ _POSTverzameling. Als deze niet is ingesteld, stelt deze deze gelijk aan de aanmeldings-URL van WordPress. Dit zal mensen dwingen om naar de inlogpagina te gaan als de verwijzings-URL niet is ingesteld; er is echter geen reden waarom dit niet zou moeten zijn.- Vervolgens nemen we de verwijzer en zuiveren we de gegevens. Dit is iets waar de coderingsnormen om vragen en het zorgt ervoor dat de gegevens schoon zijn.
- Ten slotte initialiseren we a
wp_safe_redirectnaar de URL, zodat we terugkeren naar de pagina met opties.Als dit allemaal is gebeurd, voegt u dit toe als de laatste regel in de
opslaanfunctie hierboven. De definitieve versie van de code zou er als volgt uit moeten zien:has_valid_nonce () && current_user_can ('manage_options'))) // TODO: geeft een foutmelding weer. // Als het bovenstaande geldig is, reinigt u de optie en slaat u deze op. if (null! == wp_unslash ($ _POST ['acme-bericht'])) $ value = sanitize_text_field ($ _POST ['acme-bericht']); update_option ('tutsplus-custom-data', $ waarde); $ this-> redirect (); / ** * Bepaalt of de nonce-variabele die aan de optiepagina is gekoppeld * is ingesteld en geldig is. * * @access private * * @return boolean Fout als het veld niet is ingesteld of de nonce-waarde ongeldig is; * Anders, waar. * / private function has_valid_nonce () // Als het veld niet eens in de $ _POST staat, is het ongeldig. if (! isset ($ _POST ['acme-custom-message'])) // Input var okay. return false; $ field = wp_unslash ($ _POST ['acme-custom-message']); $ action = 'acme-settings-save'; retourneer wp_verify_nonce ($ field, $ action); / ** * Omleiden naar de pagina van waaruit we kwamen (wat altijd de * admin pagina zou moeten zijn.) Als het doorverwezen niet is ingesteld, dan leiden we de gebruiker om naar * de inlogpagina. * * @Access private * / private function redirect () // Om de coderingsnormen tevreden te stellen, moeten we dit initialiseren. if (! isset ($ _POST ['_ wp_http_referer'])) // Input var okay. $ _POST ['_ wp_http_referer'] = wp_login_url (); // Sanitize de waarde van de $ _POST-verzameling voor de coderingsnormen. $ Url = sanitize_text_field (wp_unslash ($ _POST ['_ wp_http_referer']) // Voer var okay in.); // Tot slot, leid om naar de beheerpagina. wp_safe_redirect (urldecode ($ url)); exit;Hier is het ding: we hebben beveiliging, opschoning, serialisatie en doorverwijzing op zijn plaats. Maar we laten geen foutmeldingen zien en we halen de gegevens niet op.
Dat is waar we zullen komen met de volgende tutorial.
Conclusie
Op dit moment hebben we een semi-functionele plug-in, maar er is nog meer werk aan de winkel. Het is duidelijk dat de informatie die we indienen bij de database nergens wordt weergegeven, en dat is geen goede zaak.
Maar net als bij het opslaan van informatie, zijn er belangrijke dingen om rekening mee te houden bij het ophalen van informatie. In de volgende zelfstudie zullen we kijken naar het ophalen van de informatie, deze weergeven aan de voorkant, weergeven op de pagina met opties en ook de informatie bijwerken als een gebruiker de waarde van het invoerelement wijzigt.
Als u ondertussen op zoek bent naar andere hulpprogramma's om uw groeiende verzameling hulpprogramma's voor WordPress te ontwikkelen of om code te bestuderen en meer vertrouwd te raken met WordPress, vergeet dan niet te zien wat we beschikbaar hebben in Envato Markt.
Onthoud dat je al mijn cursussen en tutorials op mijn profielpagina kunt vinden, 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..
Tot slot, aarzel niet om vragen of opmerkingen achter te laten in de feed. Ik doe mijn best om deel te nemen en elke vraag of kritiek die u biedt te beantwoorden in verband met dit project.
Middelen
