Aanmaakbare WordPress-metaboxen maken controleren en zuiveren

In deze reeks hebben we een plug-in gemaakt die bedoeld is om auteurs een manier te bieden om ideeën en verwijzingen naar inhoud die ze in WordPress maken te verzamelen, te beheren en op te slaan.

Daarbij kijken we ook naar manieren waarop we onze plug-in zo kunnen inrichten dat de code en de bestandsorganisatie duidelijk en onderhoudbaar is, zodat we met de ontwikkeling van de plug-in eenvoudig kunnen toevoegen, verwijderen en onderhouden. Kenmerken.

Tot nu toe hebben we de basisbestandstructuur van de plug-in en de front-end samengesteld, maar we hebben nog geen functionaliteit geïmplementeerd voor het opslaan van informatie in de database. En als u geen informatie kunt opslaan, heeft de plug-in voor niemand iets.

In dit bericht gaan we terug naar de code aan de serverzijde en beginnen we de functionaliteit te implementeren die:

1. Controleer of de gebruiker post-metadata kan opslaan
2. Sanitiseer de post-metadata
3. Sla de metadata van de post op
4. Valideer en haal de post-metadata op

We hebben ons werk voor ons uitgesneden. In dit artikel gaan we naar de eerste twee stappen en in de volgende post kijken we naar de laatste twee stappen.

Verifiëren van machtigingen

Om te verifiëren dat de gebruiker de mogelijkheid heeft om te publiceren om metadata van berichten op te slaan, moeten we een beveiligingscontrole uitvoeren tijdens het serialisatieproces. Om dit te doen, moeten we gebruik maken van een nonce-waarde.

Een nonce is een "eenmaal gebruikt nummer" om te voorkomen dat URL's en formulieren worden misbruikt.

1. Voeg een nonce toe

Om er een in onze metabox te introduceren, kunnen we de functionaliteit implementeren in de markup die verantwoordelijk is voor het renderen van de postsjabloon. Hiertoe laadt u admin / views / auteurs-commentaar-navigation.php en werk de sjabloon bij zodat deze een aanroep bevat wp_nonce_field:

 
 Conceptbronnen gepubliceerd 
  

In de bovenstaande code hebben we een nonce geïntroduceerd die overeenkomt met de actie van het opslaan van het commentaar van de auteur (die we hebben genoemd) authors_commentary_nonce) en geassocieerd met een waarde die wordt geïdentificeerd door authors_commentary.

We zullen zien waar dit tijdelijk in het spel komt. Voorlopig ziet u niets nieuws als u uw browser laadt. Dat komt omdat de nonce-waarden worden weergegeven in een verborgen veld. 

Voor diegenen die nieuwsgierig zijn, kun je de ontwikkeltools van je favoriete browser starten, de metabox inspecteren en je zou iets als het volgende in de opmaak moeten vinden:

Natuurlijk, de waarde van jouw nonce zal anders zijn.

2. Controleer de nonce

Om er zeker van te zijn dat de gebruiker toestemming heeft om het bericht op te slaan, willen we drie dingen controleren:

1. dat de gebruiker informatie voor een post berichttype
2. dat het bericht niet automatisch wordt opgeslagen door WordPress
3. dat de gebruiker daadwerkelijk toestemming heeft om op te slaan

We zullen twee hulpfuncties schrijven om de eerste en derde te bereiken, en we zullen een aantal ingebouwde functies gebruiken om nummer twee te controleren (die ook daadwerkelijk in de tweede helperfunctie gebruikt zal worden).

Laten we eerst beginnen met het instellen van de haak en de functie die zal worden gebruikt om de hulpfuncties te gebruiken en de metadata op te slaan. In de constructor voor Authors_Commentary_Meta_Box, voeg de volgende regel code toe:

Laten we vervolgens de functie definiëren. Merk op dat ik aan het bellen ben met twee functies in het volgende codeblok. We zullen ze tijdelijk definiëren:

is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return; 

Gezien de bovenstaande code, vertellen we WordPress dat we onze moeten ontslaan save_post functioneer wanneer het is save_post actie wordt genoemd. Binnen de functie zeggen we: "Als het bericht dat wordt opgeslagen geen post-berichttype is of als de gebruiker geen toestemming heeft om op te slaan, verlaat dan de functie."

Natuurlijk moeten we de functies definiëren zodat de logica werkt. Eerst schrijven we de is_valid_post_type functioneren als een privaat functie van de huidige klasse. Het zal de $ _POST array om ervoor te zorgen dat het type bericht dat wordt opgeslagen, in feite een bericht is.

Vervolgens voegen we de user_can_save functie. Dit is de functie die ervoor zorgt dat het bericht niet door WordPress wordt opgeslagen en dat als een gebruiker de functie opslaat, de nonce-waarde die aan de berichtactie is gekoppeld, correct is ingesteld.
Merk hier op dat we voorbijgaan in de nonce_action en de nonce_id die we in de eerste stap in de sjabloon hebben gedefinieerd. We gebruiken ook wp_verify_nonce in combinatie met deze informatie.
Dit is hoe we kunnen verifiëren dat het bericht dat wordt opgeslagen, wordt gedaan door een gebruiker met de juiste toegang en machtigingen.
Sanitize the Data
Ervan uitgaande dat de gebruiker met een standaard berichttype werkt en dat hij of zij toestemming heeft om informatie op te slaan, moeten we de gegevens opschonen.
Om dit te doen, moeten we dit doen:
 
Controleer of geen van de informatie in de metagegevens van het bericht leeg is
 
Verwijder alles wat gevaarlijk kan zijn om naar de database te schrijven
 
Nadat we dit hebben gedaan, zullen we kijken naar het opslaan van de informatie voor elk van de metaboxen. Maar laten we eerst werken aan ontsmetting. Er zijn een aantal manieren waarop we dit kunnen implementeren. Voor de doeleinden van dit bericht doen we het op de meest eenvoudige manier: we controleren het bestaan ​​van de informatie op basis van de sleutel. Als deze bestaat, zullen we deze opschonen.
Voor ervaren programmeurs zult u waarschijnlijk een aantal codengeuren opmerken met de code die we gaan schrijven. Later in deze serie zullen we wat refactoring doen om te zien hoe we de plug-in beter onderhoudbaar kunnen maken, dus dit hoort allemaal bij de bedoeling van dit specifieke bericht.
Met dat gezegd, spring terug in de save_post functie.
1. Concepten
Omdat de eerste tab die in de metabox aanwezig is, de Concepten tab, we zullen ermee beginnen. Merk op dat het een is textarea, dus de logica die bestaat voor het ontsmetten van die informatie zou als volgt moeten zijn:
 
verwijder alle HTML-tags
 
ontsnappen aan de inhoud van het tekstgebied
 
Bedenk dat het textarea is genaamd auteurs-commentaar-tocht zodat we er toegang toe hebben binnen de $ _POST matrix. Om dit te bereiken, gebruiken we de volgende code:
Simpel gezegd, we controleren of de informatie in de $ _POST array is leeg. Zo niet, dan zullen we de gegevens opschonen.
2. Middelen
Dit specifieke veld is iets meer vorm omdat het dynamisch is. Dat wil zeggen dat de gebruiker alles kan hebben van nul-tot-veel invoervelden die we allemaal moeten beheren. Houd er rekening mee dat dit tabblad voornamelijk is bedoeld voor URL's, dus we moeten ervoor zorgen dat we de informatie op deze manier veilig ontsmetten..
Ten eerste moeten we een kleine wijziging aanbrengen in de createInputElement functie die bestaat binnen de admin / assets / js / resources.js het dossier. We moeten er met name voor zorgen dat het kenmerk name een array gebruikt, zodat we deze correct kunnen gebruiken en er doorheen kunnen herhalen wanneer we kijken naar $ _POST gegevens.
Zorg ervoor dat de regels code die verantwoordelijk zijn voor het maken van het eigenlijke element er zo uitziet:
// Maak vervolgens het daadwerkelijke invoerelement en stuur het vervolgens terug naar de beller $ inputElement = $ ('') .attr (' type ',' tekst ') .attr (' name ',' authors-commentary-resources ['+ iInputCount +'] ') .attr (' id ',' authors-commentary-resource- ' + iInputCount) .attr ('waarde', ');
Merk op dat de sleutel tot wat we hebben gedaan ligt in de lijn die het naam. Concreet plaatsen we het aantal ingangen en indexen van de array.
Spring vervolgens terug in de save_post functie en voeg de volgende code toe (die we na het blok bespreken):
Omdat we met een reeks ingangen werken, moeten we eerst controleren of de array niet leeg is. Als dat niet het geval is, moeten we het herhalen omdat we niet zeker weten hoeveel ingangen we moeten beheren.
Net als bij het vorige blok, doen we een basisniveau van ontsmetting en ontsnapping. Dit is iets dat je zo agressief of zo ontspannen kunt maken als je wilt. We komen in de volgende post terug op deze voorwaarde wanneer het tijd is om de gegevens op te slaan.
3. Gepubliceerd
Dit tabblad is vergelijkbaar met de vorige tabbladen omdat we te maken hebben met een onbepaald aantal elementen dat we moeten opschonen. Dit betekent dat we een kleine update moeten uitvoeren voor de gedeeltelijke verantwoordelijke voor het renderen van deze invoer.
Aan de positieve kant, we hebben alleen te maken met een checkbox die een Booleaanse waarde heeft om te worden gecontroleerd of niet (of, specifiek, 'aan' of leeg) dus het ontsmetten van de informatie is heel eenvoudig.
Laten we eerst het gedeeltelijke bijwerken. bevind zich admin / views / partials / published.php. Zoek vervolgens de regel die de definieert invoer checkbox en verander het zodat het er zo uitziet:
  Deze reactie heeft een reactie ontvangen. 
Merk op dat we de naam attribuut zodat het een array gebruikt met een index als waarde. Vervolgens springen we terug in de save_post nog een keer functioneren om validatie op dit specifieke element in te voeren:
Net zoals we hebben gedaan met de vorige stukjes gegevens, controleren we eerst of de inhoud bestaat. Als dat zo is, dan maken we het schoon om het voor te bereiden op sparen. Als dat niet gebeurt, doen we niets.
On To Saving
Op dit punt bevinden we ons in de positie om de laatste twee punten van de serie aan te pakken:
 
Opslaan en ophalen
 
refactoring
 
Vanaf het volgende bericht zullen we de code die we in dit bericht hebben geschreven opnieuw bekijken om te zien hoe we het in de database kunnen opslaan en uit de database kunnen halen om het in de front-end te kunnen weergeven.
Vervolgens gaan we verder met refactoren. Een deel van het schrijven van onderhoudbare code zorgt immers voor een overzichtelijke en eenvoudig te wijzigen code. Omdat de code waar we dagelijks mee werken al is geschreven en zou kunnen worden herzien, gaan we aan het einde van de serie bekijken hoe we dat moeten doen..
Bekijk in de tussentijd de bovenstaande code, bekijk de bron van GitHub en laat eventuele vragen en opmerkingen achter in het onderstaande veld. 



		
			
	   
	




Code