Slik viser du post Metadata på et WordPress-innlegg

I min siste serie av artikler så vi på begrepene objektorientert programmering fra nybegynnerperspektivet. Målet med serien var å ta de som ikke var kjent med objektorientert programmering i PHP, og utforske de grunnleggende aspektene av paradigmet i sammenheng med WordPress.

Hvis du ikke hadde mulighet til å lese serien, kan du lese en kort oppsummering (sammen med linker til hver artikkel i serien) i siste innlegget.

I løpet av serien ble en av de tingene vi gjorde for å hjelpe demonstrere de objektorienterte prinsippene, samt noen av funksjonene i WordPress API, å bygge et plugin. 

Spesielt bygget vi et plugin som tillot oss å se alle postdataene knyttet til et gitt innlegg i WordPress dashboard.

Pluggen er tilgjengelig for nedlasting på GitHub, hvor du også kan bla gjennom kildekoden, se kodens kommentarer og generelt se alt som gikk inn i å lage pluginet når vi utviklet det.

Siden det aktuelle innlegget ble skrevet, har jeg mottatt en rekke forskjellige spørsmål, hvorav en har vært hvordan tar vi dataene som vises i dashbordet - det vil si postmetadataene - og viser det på forsiden av nettet nettstedet.

I denne artikkelen skal vi se på å utvide plugin slik at vi kan vise dataene på en enkelt innleggsside. Vi skal snakke om hvordan du gjør dette gitt vår eksisterende kode, hvordan du gjør dette, og vi skal også snakke om hvorfor dette kanskje ikke er en god ide.

Så med det sagt, la oss komme i gang.

Ramifications for å utvide pluggen

Før vi hopper inn i planleggingen av hvordan vi faktisk skal utvide pluginet, synes jeg det er verdt å ha en kort diskusjon om hvorfor å vise denne typen informasjon på fronten - mens det er mulig - kanskje ikke en god ide.

Det vil si at jeg tror dette gjør et tilfelle for hvordan når det gjelder visse typer data, er det viktig å vurdere konsekvensene av hva vi velger å gjøre når du bygger produkter for andre og hvordan vi styrer dataene.

Kort sagt, bare fordi vi kan gjør noe betyr ikke at vi bør gjør det.

En titt på dataene

Tenk på det på denne måten: Metadataene som er knyttet til et gitt innlegg, lagres i databasen - noen av WordPress, noen av temaer, og noen av plugins - som alle bruker informasjonen til deres egne spesifikke behov.

Hvis du ser på bildet ovenfor, vil du legge merke til at noen rader er identifisert med nøkler prefiks med en understreking. For eksempel har vi _edit_lock og _edit_last og deretter noen numeriske verdier. Dette er et eksempel på data som WordPress bruker til internt å administrere statusen til innleggene.

De andre nøklene som du ser, har å gjøre med plugins som jeg har installert i min lokale WordPress-installasjon, og brukes til å demonstrere hvordan andre verktøy kan lagre data til metatatabellen og deretter forholde seg til det angitte innlegget.

Hva er problemet?

Problemet med å vise all denne informasjonen på forsiden er at du kan vise for mye informasjon til brukeren. 

I tilfellet over er det ingenting som er spesielt farlig eller følsomt som kan bidra til å kompromittere installasjonen, men det betyr ikke at det alltid vil være tilfelle. Enda videre er det en stor sjanse for at du kan ende med å vise informasjon som er relatert til et plugin eller tema som aldri ønsket at informasjonen ble vist.

Videre, for mange - eller til og med de fleste - folk som besøker en blogg, ser den informasjonen som vises på forsiden av bloggen, ut som støy. Det er teknisk sjargong som ikke betyr noe. Dette er grunnen til at jeg tror at dette er det beste stedet å gjøre det ved å holde denne informasjonen omgjort til instrumentbrettet.

Men vi kommer til å utvide pluggen?

Kort sagt, ja, men ikke fordi jeg synes å vise denne typen informasjon til brukeren, er en god ide, men fordi det er en praktisk applikasjon som følger med å utvide et eksisterende plugin, fordelene ved å utnytte eksisterende kode, og se negative konsekvenser av gjør slikt.

Så ja - noen ganger kan de beste leksjonene komme fra å implementere ideer som kanskje ikke er gode i ettertid. 

Men det er greit. Slik lærer vi riktig?

I tillegg er det fortsatt noen praktiske leksjoner som følger med å lære å utvide en eksisterende kodebase.

Utvider single post Meta Manager

Som med alle veiledningene som jeg deler, prøver jeg å planlegge ut nøyaktig hva vi gjør det før vi gjør det slik at vi ikke kodes gjennom mye gjetningsarbeid, og slik at vi har en handlingsplan for hvordan vi skal arkitektere vår løsning.

Så, før du går videre, hvis du ikke har vurdert Single Post Meta Manager, vennligst gjør det nå, og vi fortsetter.

Når det er gjort, er det det vi skal planlegge å gjøre:

1. Vi bruker standard twentyfourteen tema som grunnlag for vårt eksempel.
2. Vi presenterer en offentlig katalog som skal brukes til å vise informasjonen på offentlig siden av bloggen, spesielt i sammenheng med enkelt innlegg.
3. Vi definerer kroker som gjør det mulig for oss å legge til informasjon i innholdet i innlegget, slik at innleggets metadata kan vises nederst på innholdet. Vi bruker et rudimentært bord for dette som vil arve stiler fra dagens tema. Vær oppmerksom på at du ved å gjøre dette kan ende opp med å ha noen veldig rene stiler, og du kan ende opp med å ha noen veldig svake stiler. Disse vil være opp for deg å implementere på egen hånd.
4. Vi vil da dra nytte av mal som vi opprettet i den første versjonen av pluginet for å sørge for å hente postdataene for det oppgitte innlegget for å vise det på forsiden.

Ingenting er for komplisert, ikke sant? Vi må bare være presise i trinnene våre. Så la oss komme i gang.

Sett inn den offentlige katalogen

Forutsatt at du allerede har tjuefemteen allerede aktivert og pluginet installert, la oss komme til å arbeide med å introdusere vår funksjonalitet. Det første vi må gjøre er å 

• introdusere en offentlig katalog
• Legg til Single_Post_Meta_Manager_Public klasse
• inkludere klassen i kjernepluginfilen

Etter at du har lagt til filene, kan ovenstående gjøres ved hjelp av følgende kodelinjer til load_dependencies fungere i omfatter / enkelt-post-meta-manager.php.

private funksjon load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'Admin / klasse-single-post-meta-leder-admin.php'; require_once plugin_dir_path (dirname (__FILE__)). 'Offentlig / klasse-single-post-meta-leder-public.php'; require_once plugin_dir_path (__FILE__). 'Class-single-post-meta-leder-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); 

Legg merke til at den eneste nye linjen er den andre require_once setning som importerer klassefilen. 

Etter det, la oss definere egenskapene, konstruktøren og metodene for Single_Post_Meta_Manager_Public klasse:

versjon = $ versjon;  / ** * Bruker den delvise som er plassert i admin-katalogen for å gjøre * post-metadataene til slutt på innleggets innhold. * * @param string $ content Innleggets innhold. * @return string $ content Innleggets innhold inkludert de oppgitte innleggene metadata. * / offentlig funksjon display_post_meta_data ($ content) ob_start (); require_once plugin_dir_path (dirname (__FILE__)). 'Admin / partials / single-post-meta-manager.php'; $ template = ob_get_contents (); $ content. = $ template; ob_end_clean (); returnere $ content; 

Deretter må vi opprette Meta Manager for Single Post define_public_hooks funksjon. Dette burde se slik ut:

get_version ()); $ this-> loader-> add_action ('the_content', $ public, 'display_post_meta_data'); 

Deretter må vi definere et anrop til denne funksjonen innen konstruktøren. Det er, like under $ Dette-> define_admin_hooks (); linje, legg til $ Dette-> define_public_hooks (); anrop.

Forutsatt at alt har gått bra, bør du kunne aktivere pluginet, laste opp et innlegg, og se de samme metadataene som nå vises på forsiden av innlegget, så vel som i dashbordet til innlegget:

Sammendrag

Som nevnt tidligere i denne opplæringen, er ikke nødvendigvis den beste ideen å vise denne typen informasjon på forsiden av et innlegg. Imidlertid lærer man å lære å legge til et eksisterende plugin, og introdusere helt ny funksjonalitet samtidig som man gjenbruker noen av de eksisterende komponentene.

Til slutt er nøkkelopptaket to ganger:

• Å utnytte eksisterende kode er en kraftig ting
• Å eksponere data som er irrelevant for brukere er en farlig ide

Så etter å ha lest denne spesielle opplæringen, merk at jeg ikke nødvendigvis godkjenner å gjøre dette i et miljø på produksjonsnivå, men mer som et læringsverktøy. Det er, bruk det på egen risiko.

Som vanlig, vennligst la alle dine spørsmål, kommentarer og mer i feedet under!