Opprette Vedlikeholdbare WordPress Meta Bokser Lagre og Hent

Når vi kommer opp på slutten av denne serien, har vi to andre emner som skal dekke:

Lagrer informasjon til og henter informasjon fra databasen
Refactoring koden slik at den blir mer vedlikeholdsbar for oss

I den forrige artikkelen så vi på validering, sanering og implementering av denne funksjonaliteten for elementene som vi har vist på forsiden. I denne artikkelen skal vi fortsette prosessen ved å lagre informasjonen i databasen, hente informasjonen og vise den på fronten.

Underveis ser vi også på noen av de innebygde WordPress API-funksjonene som er laget for å gjøre dette litt enklere for oss, så vel som noen tips for å dobbeltsjekke vårt arbeid i databasen for å bekrefte at informasjonen blir lagret akkurat som vi forventer.

Vi har bare litt mer å gå for å få denne pluginen til livs, så la oss komme i gang.

Lagre data

For å vise data på fronten, må vi åpenbart få det inn i databasen først. Siden vi jobber med metakasser, kan vi bruke funksjoner som er tilgjengelige via Meta Box API for å lagre denne informasjonen.

Spesielt skal vi jobbe med følgende funksjoner:

update_post_meta for å lagre informasjon til databasen
delete_post_meta for å fjerne informasjon fra databasen

Det er en annen funksjon, add_post_meta, det er også tilgjengelig for å skrive informasjon til databasen; derimot, update_post_meta gjør det samme hvis dataene ikke allerede finnes i databasen.

Et annet spørsmål som jeg har sett kommer opp når det gjelder å slette postmetadata, er hvorfor? Det er, hvorfor slette informasjon i stedet for å lagre en tom verdi?

Du kan argumentere for at dette er en personlig preferanse - og det er - men hvis du jobber med et forsiktig plugin som har flere forskjellige felt, og feltene ikke har noen verdi, er det fornuftig å ikke opprettholde en tom rad.

Videre, med mindre fravær av verdi er meningsfylt for noe i brukergrensesnittet, er det heller ikke grunn til å opprettholde en tom verdi som vi tillater databasen å tettere speil informasjonen som vises på skjermen.

Å holde brukergrensesnittet, programlagskoden og databasen så konsekvent som mulig, er nyttig når du prøver å skrive vedlikeholdsbar kode.

Så med det sagt, la oss se på prosessen med å lagre feltene for hvert av våre felt.

1. Utkast

Husk fra forrige innlegg at utkast fanen inneholder en enkelt textarea det er ment å være et sted for forfattere å samle ulike notater og nettadresser fra hele nettet som er relevante for innholdet de forbereder seg for å publisere.

Da vi sist forlot denne koden, hadde vi følgende:

Her ser vi for å se om innholdet i $ _POST array er befolket. I så fall sanitiserer vi informasjonen ved hjelp av trim og esc_textarea.

På dette tidspunktet er vi klare til å skrive det til databasen, så la oss erstatte linjen som leser // Mer kommer… med følgende kode (merk at vi vil se nærmere på koden etter blokken):

Her bruker vi update_post_meta funksjon for å legge til eller oppdatere innholdet i databasen. Merk at funksjonen tar tre parametere:

Post-ID-en som brukes for å knytte denne informasjonen til innlegget
En metatast som brukes til å identifisere verdien unikt
Den faktiske meta verdien forbundet med meta-nøkkelen

Legg også merke til at hvis verdien av $ _POST array er tom så vi sjekker for å se om det er er en verdi for utkastet i databasen, og hvis det eksisterer, fjerner vi det.

2. Ressurser

Fordi vi allerede har lagt alt grunnarbeidet for å rydde opp informasjonen, og vi har sett hvordan både å oppdatere og slette informasjon i databasen, gjør det samme for ressurser fanen er mer av det samme.

Det ene unntaket er at siden vi arbeider med et dynamisk sett med opplysninger, må vi dynamisk knytte posten med en unik ID basert på hvor mange ressurser vi sparer.

I forrige innlegg så vår kode slik ut:

Når det gjelder dynamisk behandling av informasjon, a for hver sløyfe fungerer bra; Når vi lagrer informasjon, må vi imidlertid knytte en unik nøkkel med hver verdi.

Et alternativ ville være å sette opp en for-løkke for å suffikere metatasten med en unik nøkkel (ved å bruke iteratoren for hver verdi i løkken), men dette kan føre til problemer når det gjelder å slette informasjon. Spesifikt, hvis brukeren skriver inn en verdi for første, andre og tredje innmatning, men fjerner den andre innmatingen som bare forlater den første og tredje når oppdateringen oppdateres, må vi skikkelig slette de tomme verdiene og skifte alle postene tilsvarende.

Dette kan gjøres på en rekke forskjellige måter, men det er faktisk lettere å lagre et enkelt serialisert array til en unik indeks i stedet for å prøve å gjøre noe fancy med databaseresultater, spørringer og så videre.

Som sådan oppdaterer vi koden ovenfor for å se slik ut:

Hvis du kikker inn i databasen og ser på denne spesifikke nøkkelen, bør du se noe som dette lagret som verdien:

a: 3: i: 0; s: 22: "http://tommcfarlin.com"; i: en; s: 19: "http://tutsplus.com"; i: 2; s: 17:" http://google.com ";

Vi ser hvordan dette spiller ut når vi henter informasjonen fra databasen senere i denne artikkelen. Vær også oppmerksom på at vi må ta stilling til saken når en bruker har fjernet alle forekomster av ressurser.

Akkurat som vi gjorde i første del av artikkelen, sletter vi bare post-metadataene hvis det finnes en verdi. Dette kan gjøres ved å bruke meget lignende kode:

Nå må vi lagre verdiene for den siste meta-boksen.

3. Publisert

Den endelige fanen i meta-boksen, publisert fanen, kommer til å være den enkleste for oss å oppdatere som det trekker sammen alt vi har sett på så langt i artikkelen.

Spesielt er det iterating gjennom en samling av verdier, skriver dem til en matrise, og serialiserer deretter arrayet til databasen. Kanskje det viktigste å merke seg er at vi bruker en assosiativ array, og vi indekserer hver verdi med verdien av kommentar-IDen.

Som vi ser senere i artikkelen, vil dette gjøre det mye lettere å angi verdiene på brukergrensesnittet.

 $ comment_value) $ comment = strip_tags (stripslashes ($ comment_value)); $ sanitized_comments [$ comment_id] = $ comment;  update_post_meta ($ post_id, "authors-commentary-comments", $ sanitized_comments);

Akkurat som vi gjorde i forrige avsnitt, hvis det ikke er noe spesifisert i $ _POST array, så kontrollerer vi eksistensen av verdiene i databasen, og hvis de eksisterer, sletter vi dem:

 $ comment_value) $ comment = strip_tags (stripslashes ($ comment_value)); $ sanitized_comments [$ comment_id] = $ comment;  update_post_meta ($ post_id, "authors-commentary-comments", $ sanitized_comments);  ellers if ("! == get_post_meta ($ post_id," authors-commentary-comments ", sant)) delete_post_meta ($ post_id," authors-commentary-comments ");

Som nevnt, trekker dette siste eksempelet alt sammen som vi har sett for de to siste kategoriene, så det bør være relativt klart kode å følge på dette punktet.

Et ord om databasen

Før vi går videre, la oss ta et øyeblikk for å forstå hvordan vi kan ende opp med å spørre informasjon fra databasen.

La oss si at du har et innlegg med ID på 9000 (din vil variere basert på oppsettet ditt). Du kan ta den IDen og se i wp_postmeta tabell for å se all metainformasjonen som er knyttet til innlegget.

Videre kan du spesifisere nøkkelen for å trekke tilbake kun informasjonen som er knyttet til post-ID og nøkkel.

Hvis du bare angir post-ID, vil du se all metainformasjon knyttet til innlegget. Hvis du bare angir nøkkelen, vil du se alle post-IDer som inneholder innhold for utkastene sine. Hvis du angir både post-ID og nøkkel, trekker du bare utkastet til informasjonen du har angitt for ett enkelt innlegg.

Når vi snakker om å hente data, la oss se på trinnene som er nødvendige for å vise postdataene i kontrollpanelet i plugin-modulen.

Henter data

Nå som all informasjon har blitt lagret i databasen, kan vi introdusere kode som henter den og vise den i den riktige kategorien for hvert plugin. Den fine tingen om dette er at den skal bruke funksjoner og konstruktører (som get_post_meta og til) som vi allerede har brukt.

1. Utkast

Lokaliser admin / synspunkter / partials / drafts.php. Forutsatt at du har fulgt med alt opp til dette punktet, bør koden se slik ut:

Å fylle dette textarea, vi må ringe til get_post_meta bruker nåværende post-ID og nøkkel som vi pleide å lagre informasjon tidligere i denne artikkelen. Ta en titt på følgende kode:

 <?php echo get_post_meta( get_the_ID(), 'authors-commentary-drafts', true ); ?>

Legg merke til at vi passerer inn i tre parametere:

Den første er post-IDen som hentes ved å bruke get_the_ID funksjon.
Den andre er nøkkelen som vi har angitt når du lagrer dataene for å identifisere det unikt.
Den tredje er en boolsk verdi sant som forteller funksjonen å returnere oss verdien som en streng i stedet for i en matrise.

Hvis verdien ikke eksisterer, returnerer den bare en tom streng slik at textarea er tom.

2. Ressurser

Til ressurser, vi gjør et lignende kall; Men denne gangen ønsker vi å iterere gjennom resultatene slik at vi dynamisk kan opprette brukergrensesnittet.

På grunn av måten WordPress serierer arrayet, vil vi fortsatt at informasjonen returneres i et strengformat (selv om det vil være et de-serialisert array) som gjør at vi kan bruke en for hver loop for å iterere gjennom den.

Kort sagt, henter vi informasjonen fra databasen, slår gjennom den skaper en inngang element for hver verdi og deretter gjøre det til siden.

Dette tillater oss også å fjerne elementer ved å bare slette en verdi og deretter oppdatere innlegget. Derfra vil skjermen gjenopprette seg selv slik at det ikke finnes noen tomme inngangselementer.

3. Publisert

Muligens er dette den enkleste delen av plugin. Siden vi allerede har så mye kode i malen, er det eneste vi virkelig trenger å gjøre, å avgjøre om verdien for avkrysningsboksen er satt i metadatabasen.

Siden vi bruker kommentasjons-ID som den numeriske indeksen til arrayet, kan vi bare sjekke om kommentasjons-IDen er inneholdt i en rekke metatyper som returneres fra metadataene.

Dette er hvordan:

 load_post_comments (); ?>      comment_ID, $ comments)? 'sjekket =' sjekket '': ";?> /> Denne kommentaren har mottatt et svar.   COMMENT_AUTHOR; ?>: COMMENT_CONTENT; ?>

Legg merke til at vi henter verdien fra databasen, igjen bestått ekte som den tredje verdien.

Deretter tar vi gjeldende kommentasjons-ID og kontrollerer for å se om den verdien er inneholdt i matrise-tastene (ved å bruke array_key_exists) Av post-metadataene som ble returnert. Hvis ja, merker vi av i avmerkingsboksen som markert. ellers gjør vi ingenting.

Neste

På dette tidspunktet har vi et fullt fungerende plugin som oppfyller alle kravene som vi satt ut for å bygge ut fra den første artikkelen i serien.

Men er pluggen selv vedlikeholdbar? Det vil si, oppfyller det det primære målet for denne serien?

I noen dager, ja, men det er rom for forbedring. Siden en del av utviklingen må jobbe med kode som vi arver, skal vi se på hvordan vi refactorer noen av kodene som vi har skrevet for å gjøre det lettere å forstå og vedlikeholde.

I tillegg vil vi se på grunner til hvorfor vi utfører noen av refactoring som vi gjør. Tross alt ville det ikke gi stor mening å forenkle koden eller å flytte den rundt uten begrunnelse.

Men før du gjør det, gå videre og arbeid gjennom denne artikkelen og ta en kikk på koden fra det tilknyttede GitHub-depotet og la noen kommentarer, spørsmål eller generell tilbakemelding nedenfor.

Kode