Onderhoudbare WordPress-metaboxen maken opslaan en ophalen

Zoals we aan het einde van deze serie tegenkomen, hebben we nog twee onderwerpen te bespreken:

1. Informatie opslaan in en ophalen uit de database
2. De code herformuleren zodat deze voor ons beter te onderhouden is

In het vorige artikel hebben we gekeken naar validatie, opschoning en implementatie van deze functionaliteit voor de elementen die we aan de voorkant hebben weergegeven. In dit artikel gaan we door met het proces door de informatie in de database op te slaan, de informatie op te halen en deze aan de voorkant weer te geven.

Onderweg bekijken we ook enkele van de ingebouwde WordPress API-functies die zijn ontworpen om dit een beetje gemakkelijker te maken voor ons, evenals enkele tips voor het dubbel controleren van ons werk in de database om te verifiëren dat onze informatie wordt opgeslagen precies zoals we verwachten.

We hebben nog net iets meer te doen om deze plug-in tot leven te brengen, dus laten we aan de slag gaan.

Gegevens opslaan

Om gegevens aan de voorkant weer te geven, moeten we dit natuurlijk eerst in de database krijgen. Omdat we werken met metaboxen, kunnen we functies gebruiken die beschikbaar zijn via de Meta Box API om deze informatie op te slaan.

Concreet gaan we werken met de volgende functies:

• update_post_meta voor het opslaan van informatie in de database
• delete_post_meta voor het verwijderen van informatie uit de database

Er is nog een andere functie, add_post_meta, dat is ook beschikbaar voor het schrijven van informatie naar de database; echter, update_post_meta doet hetzelfde als de gegevens nog niet in de database aanwezig zijn.

Een andere vraag die ik heb gezien bij het verwijderen van post-metadata, is waarom? Dat wil zeggen, waarom informatie verwijderen in plaats van een lege waarde opslaan? 

Je kunt stellen dat dit een persoonlijke voorkeur is - en dat is het ook - maar als je werkt met een uitgebreide plug-in met een aantal verschillende velden en de velden hebben geen waarde, dan is het logisch om geen lege rij te behouden.

Verder, tenzij de afwezigheid van een waarde betekenisvol is voor iets op de gebruikersinterface, is er ook geen reden om een ​​lege waarde te behouden, omdat we toestaan ​​dat de database de informatie die op het scherm wordt getoond nauwer weerspiegelt.. 

De gebruikersinterface, de laag van de toepassingslaag en de database zo consistent mogelijk houden, is handig wanneer u probeert onderhoudbare code te schrijven. 

Laten we dus, met dat gezegd, kijken naar het opslaan van de velden voor elk van onze invoervelden.

1. Concept

Herinner uit de vorige post dat de Droogte tabblad bevat een single textarea dat is bedoeld als een plek voor auteurs om verschillende notities en URL's op internet te verzamelen die relevant zijn voor de inhoud die ze voorbereiden op publicatie.

Toen we deze code voor het laatst achterlieten, hadden we het volgende:

Hier kijken we of de inhoud van de $ _POST array is ingevuld. Zo ja, dan ontsmetten we de informatie met behulp van trimmen en esc_textarea.
Op dit moment zijn we klaar om het naar de database te schrijven, dus laten we de regel die leest vervangen // Meer volgt nog…  met de volgende code (houd er rekening mee dat we de code na het blok nader bekijken):
Hier gebruiken we de update_post_meta functie om de inhoud in de database toe te voegen of bij te werken. Merk op dat de functie drie parameters vereist:
 
Het bericht-ID dat wordt gebruikt om deze informatie aan het bericht te koppelen
 
Een meta-sleutel die wordt gebruikt om de waarde uniek te identificeren
 
De werkelijke metawaarde die is gekoppeld aan de meta-sleutel
 
Merk ook op dat als de waarde van de $ _POST array is leeg, dan controleren we om te zien of daar is een waarde voor het concept in de database en als deze bestaat, verwijderen we deze.
2. Middelen
Omdat we al het basiswerk hebben gedaan om de informatie te ontsmetten en we hebben gezien hoe zowel informatie als gegevens in de database kunnen worden bijgewerkt en verwijderd, door hetzelfde te doen voor de Middelen tabblad is meer hetzelfde.
De enige uitzondering is dat omdat we te maken hebben met een dynamische set informatie, we het bericht dynamisch moeten associëren met een unieke ID op basis van het aantal bronnen dat we opslaan.
In het vorige bericht zag onze code er zo uit:
Als het gaat om het dynamisch verwerken van informatie, foreach loop werkt geweldig; Bij het opslaan van informatie moeten we echter een unieke sleutel aan elke waarde koppelen. 
Een optie zou zijn om een ​​for-lus in te stellen om de meta-sleutel te vervangen door een unieke sleutel (door de iterator te gebruiken voor elke waarde in de lus), maar dit kan problemen veroorzaken als het gaat om het verwijderen van informatie. In het bijzonder, als de gebruiker een waarde invoert voor de eerste, tweede en derde invoer, maar vervolgens de tweede invoer verwijdert, waarbij alleen de eerste en derde worden achtergelaten bij het bijwerken van de post, moeten we die lege waarden correct verwijderen en alle records dienovereenkomstig verplaatsen.
Dit kan op verschillende manieren worden gedaan, maar het is eigenlijk gemakkelijker om een ​​enkele geserialiseerde array op te slaan naar een unieke index in plaats van te proberen iets bijzonders te doen met databaserijen, query's enzovoort.
Daarom werken we de bovenstaande code bij om er als volgt uit te zien:
Als u de database bekijkt en naar deze specifieke sleutel kijkt, zou u zoiets als dit moeten zien als de waarde:
a: 3: i: 0; s: 22: "http://tommcfarlin.com"; i: 1; s: 19: "http://tutsplus.com"; i: 2; s: 17:" http://google.com ";
We zullen zien hoe dit uitpakt wanneer we de informatie uit de database later in dit artikel ophalen. Merk ook op dat we rekening moeten houden met het geval wanneer een gebruiker alle instanties van bronnen heeft verwijderd.
Net als in het eerste deel van het artikel, verwijderen we eenvoudig de post-metadata als er een waarde bestaat. Dit kan worden gedaan met behulp van zeer vergelijkbare code:
Nu moeten we de waarden opslaan voor de laatste metabox.
3. Gepubliceerd
Het laatste tabblad van de metabox, de Gepubliceerd Tab, wordt de gemakkelijkste voor ons om te updaten omdat het alles samenbrengt waar we tot nu toe in het artikel naar hebben gekeken.
In het bijzonder itereren we door een verzameling waarden, schrijven we ze naar een array en vervolgens serialiseren we de array naar de database. Het belangrijkste om op te merken is dat we een associatieve array gebruiken en we indexeren elke waarde aan de hand van de waarde van de opmerking-ID.
Zoals we later in het artikel zullen zien, zal dit het veel gemakkelijker maken om de waarden in de gebruikersinterface in te stellen.
 $ comment_value) $ comment = strip_tags (stripslashes ($ comment_value)); $ sanitized_comments [$ comment_id] = $ opmerking;  update_post_meta ($ post_id, 'authors-commentary-comments', $ sanitized_comments); 
Net als in het vorige gedeelte, als er niets is opgegeven in de $ _POST array, dan controleren we het bestaan ​​van de waarden in de database en als ze bestaan, verwijderen we ze:
 $ comment_value) $ comment = strip_tags (stripslashes ($ comment_value)); $ sanitized_comments [$ comment_id] = $ opmerking;  update_post_meta ($ post_id, 'authors-commentary-comments', $ sanitized_comments);  else if ("! == get_post_meta ($ post_id, 'authors-commentary-comments', true)) delete_post_meta ($ post_id, 'authors-commentary-comments');
Zoals gezegd, dit laatste voorbeeld trekt alles bij elkaar wat we hebben gezien voor de laatste twee tabbladen, dus het zou een relatief duidelijke code moeten zijn om op dit punt te volgen.
Een woord over de database
Voordat we verder gaan, nemen we even de tijd om te begrijpen hoe we uiteindelijk informatie uit de database kunnen ondervragen. 
Laten we zeggen dat je een bericht hebt met de ID van 9000 (de jouwe zal variëren op basis van je instelling). U kunt die ID nemen en kijken in de wp_postmeta tabel om alle meta-informatie te zien die aan het bericht is gekoppeld.
Bovendien kunt u de sleutel opgeven om alleen de informatie terug te trekken die is gekoppeld aan het bericht-ID en de sleutel.
Als u alleen de bericht-ID opgeeft, ziet u alle metagegevens die aan het bericht zijn gekoppeld. Als u alleen de sleutel opgeeft, ziet u alle bericht-ID's die inhoud voor hun concepten bevatten. Als u zowel de bericht-ID als de sleutel opgeeft, haalt u alleen de conceptinformatie terug die u voor één bericht hebt opgegeven.
Spreken van het ophalen van gegevens, laten we eens kijken naar de stappen die nodig zijn om de post-metadata weer te geven in het dashboard van onze plug-in.
Het ophalen van gegevens
Nu alle informatie in de database is opgeslagen, kunnen we code introduceren die deze informatie ophaalt en weergeeft op het juiste tabblad van elke plug-in. Het leuke hiervan is dat het functies en constructors zal gebruiken (zoals get_post_meta en voor) die we al hebben gebruikt.
1. Concept
bevind zich admin / views / partials / drafts.php. Ervan uitgaande dat je tot nu toe alles hebt gevolgd, ziet de code er als volgt uit:
  
Om dit te vullen textarea, we moeten bellen get_post_meta met behulp van de huidige bericht-ID en de sleutel die we eerder in dit artikel hebben gebruikt om informatie op te slaan. Bekijk de volgende code:
 <?php echo get_post_meta( get_the_ID(), 'authors-commentary-drafts', true ); ?> 
Merk op dat we drie parameters doorgeven:
 
De eerste is de post-ID die wordt opgehaald met behulp van de get_the_ID functie.
 
De tweede is de sleutel die we hebben opgegeven bij het opslaan van de gegevens om deze uniek te identificeren.
 
De derde is een booleaanse waarde true die de functie vertelt om de waarde als een tekenreeks terug te geven in plaats van in een array.
 
Als de waarde niet bestaat, retourneert deze eenvoudig een lege tekenreeks, dus de textarea is leeg.
2. Middelen
Voor Middelen, we doen een soortgelijke oproep; Deze keer willen we echter de resultaten herhalen, zodat we de gebruikersinterface dynamisch kunnen maken.
Vanwege de manier waarop WordPress de array serialiseert, willen we nog steeds dat de informatie wordt geretourneerd in een tekenreeksindeling (hoewel het een array met gedelitaliseerde reeksen is) die ons in staat zal stellen een foreach lus om er doorheen te herhalen.
 
     
 
 
Kortom, we halen de informatie uit de database op, lus er doorheen en creëren een invoer element voor elke waarde en vervolgens naar de pagina te renderen. 
Dit stelt ons ook in staat om elementen te verwijderen door simpelweg een waarde te verwijderen en vervolgens de post bij te werken. Vanaf daar zal het display zichzelf zodanig opnieuw renderen dat er geen lege invoerelementen zijn.
3. Gepubliceerd
Wellicht is dit het gemakkelijkste onderdeel van de plug-in. Omdat we al zoveel code in de sjabloon hebben, is het enige dat we echt moeten doen, bepalen of de waarde voor het selectievakje is ingesteld in de metagegevensmatrix.
Omdat we de opmerking-ID gebruiken als de numerieke index van de array, kunnen we eenvoudig controleren of de opmerking-ID zich bevindt in de array met meta-sleutels die wordt geretourneerd uit de metadata.
Hier is hoe:
 load_post_comments (); ?> 
  
   comment_ID, $ reacties)? 'checked = "checked"': ";?> /> Deze reactie heeft een reactie ontvangen.  
 COMMENT_AUTHOR; ?>: COMMENT_CONTENT; ?> 
 
 
  
 
Merk op dat we de waarde uit de database halen, opnieuw passerend waar als de derde waarde. 
Vervolgens nemen we de huidige opmerking-ID en controleren om te zien of die waarde zich bevindt in de arraysleutels (door te gebruiken array_key_exists) Van de post-metagegevens die zijn geretourneerd. Als dat het geval is, markeren we het selectievakje als aangevinkt; anders doen we niets.
Volgende
Op dit moment hebben we een volledig werkende plug-in die voldoet aan alle vereisten die we zijn gaan opstellen, te beginnen met het eerste artikel in de serie.
Maar is de plug-in zelf onderhoudbaar? Dat wil zeggen, voldoet het aan het primaire doel van deze serie?
In someways, ja maar er is ruimte voor verbetering. Omdat een deel van de ontwikkeling moet werken met code die we erven, gaan we kijken hoe we sommige van de code die we hebben geschreven kunnen herfactoren om het gemakkelijker te begrijpen en beter te onderhouden te maken.
Daarnaast zullen we kijken naar redenen waarom we sommige refactoring die we doen uitvoeren. Het zou tenslotte niet logisch zijn om code te vereenvoudigen of te verplaatsen zonder enige reden.
Maar voordat je dit doet, ga je gang en werk je door dit artikel en bekijk je de code van de bijbehorende GitHub-repository en laat je hieronder eventuele opmerkingen, vragen of algemene feedback achter..



		
			
	   
	




Code