Share
I forrige innlegg i serien begynte vi å jobbe med et lite plugin som ga et praktisk eksempel på wp_remote_post. Saken er, eksemplet var ufullstendig.
Jo, det er fint å se hvordan du ringer ved hjelp av funksjonen og til og med hvordan du konfigurerer et skript som er ansvarlig for å motta dataene og returnerer dataene, men det er lite brukt, med mindre vi gjør noe med det.
I denne siste artikkelen i serien går vi tilbake til pluginet som vi startet med den siste artikkelen, og begynner å forbedre det litt.
Spesielt vil vi ...
Accentsconagua
wp_remote_get og wp_remote_post Til slutt vil alt arbeidet som er oppnådd i denne artikkelen være tilgjengelig på GitHub og koblet i konklusjonen av artikkelen. Men før det, la oss gå videre og komme i gang.
I den forrige artikkelen konfigurerer vi et grunnleggende plugin som viser informasjon om den besøkende til dagens nettside:
Ved å bruke informasjon som er tilgjengelig via serversiden, kan vi vise IDen til den besøkende, adressen de navigerte til, og siden som er sett på.
Enkle ting, rett?
For å gjøre koden mer lesbar, vedlikeholdsbar og i stand til å bli stylet, er det noen ting vi må gjøre. Men først, hvis du har fått dette langt, gå gjennom forrige artikkel, implementer kildekoden, og kom tilbake til dette innlegget.
Tilbakekall fra den forrige artikkelen, introduserte vi en fil som heter wp-fjern received.php som var ansvarlig for å ta tak i informasjon fra PHP $ _POST samling og bygge en visning som var mer brukervennlig enn en enkel dump av dataene.
Spesifikt, her er koden som vi jobbet med:
Postdataene"; ekko "
Du kan nå lagre eller ignorere denne informasjonen,
";Men la oss rense dette opp litt. I stedet for å ekko flere setninger, la oss bygge opp en enkelt streng av HTML og returnere den. I tillegg gir vi noen ekstra elementer og klassenavn som gjør det enklere å få tilgang via CSS:
'; $ html. = 'Postdataene
'; $ html. = '
Ingenting er for komplisert. Kort sagt, vi la til en wrapper med en unik ID, og så plasserte alt innenfor pakken. Vi fjernet også setningen om hvorvidt informasjonen kunne bli lagret.
Se siden i nettleseren din for å dobbeltsjekke alle ting ser det samme ut. På dette punktet bør det ikke være noen forskjell fra skjermbildet ovenfor.
Hvis ja, vurder koden din.
Før vi går inn i å faktisk serialisere denne informasjonen, la oss fortsette ved å utforme informasjonen som mottakeren har gitt.
For å gjøre det, la oss lage en css katalog i roten til plugin katalogen. Vi lager også en mindre underkatalog der vår plugin MINDRE fil vil oppholde seg. Jeg ringer filen display.less siden det er vant til, vet du, stil skjermen :).
Deretter legger vi hele plugin-mappen til CodeKit. Hvis du ikke er kjent med hvordan du gjør dette, kan du lese denne serien.
På dette tidspunktet er vi klare til å skrive litt mindre for å gi vårt plugin en litt bedre presentasjon.
Legg til følgende kode i MINDRE filen:
# wp-fjernkontroll-post-eksempel-container bakgrunn: # f7f5e7; grense: 1px solid # ac0404; polstring: 20px; h4 margin: 0; // h4 ul li liste-stil-type: sirkel; // li // ul // / # wp-ekstern-post-eksempel-container
CodeKit (eller MINDRE kompilatoren hvis du velger å gå den ruten) skal generere riktig CSS. Deretter må vi instruere pluginet vårt for å laste opp den nye CSS-filen. For å gjøre dette, legg til følgende linje kode til konstruktøren din:
add_action ('wp_enqueue_scripts', array ($ dette, 'add_style_sheet')); Deretter legger du til følgende funksjon i klassen din:
offentlig funksjon add_style_sheet () wp_enqueue_style ('wp-ekstern-post-eksempel-stil', plugins_url ('wp-fjernkontroll-post-eksempel / css / display.css')); // end add_style_seet Endelig, last opp et enkelt innlegg, og siden din skal se slik ut:
WP Remote Post Eksempel med stil Ser bra ut, ikke sant? Sikker på at du kan tilpasse det, men du vil, men dette er eksemplet som vi skal til for denne artikkelen.
Endelig er vi klare til å faktisk gjøre noe med disse dataene.
Nå skal vi definere en funksjon som tar et svar fra wp-fjern receiver.php og lagre det faktisk til posten metadata, men bare hvis den ikke allerede eksisterer.
Spesielt, her er hva vi skal gjøre:
For det første, la oss først definere en funksjon som vil gjøre akkurat det. Vær oppmerksom på at den vil akseptere en unik ID som vil korrespondere med IP-adressen vi ser ovenfor, samt webadressen og siden URL.
privat funksjon save_post_data ($ unique_id, $ site_url, $ page_url) if ("== get_post_meta (get_the_ID (), 'unique_id', sant)) add_post_meta (get_the_ID (), 'unique_id', $ unique_id); add_post_meta (get_the_ID (), 'site_url', $ site_url); add_post_meta (get_the_ID (), 'page_url', $ page_url); // ende if Basert på kravene nevnt ovenfor, vil vi bare lagre data for dette innlegget hvis ingenting eksisterer for den angitte IP-adressen.
På dette punktet trenger vi bare å gjøre en mindre endring til vår get_post_response funksjon. Oppdater betinget slik at det kaller inn i funksjonen som vi har definert ovenfor:
hvis (is_wp_error ($ response)) $ html = ''; $ html. = __ ('Det oppstod et problem å hente svaret fra serveren.', 'wprp-example'); $ html. = ''; ellers $ html = ''; $ html. = ''; $ this-> save_post_data ($ unique_id, $ site_url, $ page_url);'. __ ('Din melding postet med suksess! Svaret var som følger:', 'wprp-example'). '
'; $ html. = ''. $ respons ['body']. '
'; $ html. = '
Og det er det!
Det endelige pluginet er tilgjengelig for gjennomgang og for nedlasting på GitHub. Den inneholder også dokumentasjon for hver funksjon som følger med pluginet, samt en README, slik at du kan følge med alt som var inkludert her.
Merk at hvis du er interessert i argumentene som wp_remote_post aksepterer, gå gjennom den forrige artikkelen der vi dekket dette når vi snakket om wp_remote_get.
Endelig riper dette bare overflaten av det som er mulig med HTTP API. Forhåpentligvis har denne serien bidratt til å gi en solid introduksjon til API, og har bidratt til å bane vei for fremtidig arbeid med API.
