Så här visar du Metadata på en WordPress-post

I min sista serie artiklar tittade vi på begreppen objektorienterad programmering ur nybörjarperspektivet. Seriens mål var att ta de som inte kände till objektorienterad programmering i PHP och utforska de grundläggande aspekterna av paradigmet inom ramen för WordPress.

Om du inte hade möjlighet att läsa serien kan du läsa en kort sammanfattning (tillsammans med länkar till varje artikel i serien) i sista inlägget.

Under serien har en av de saker som vi gjorde för att hjälpa till att visa de objektorienterade principerna liksom några av funktionerna i WordPress API bygga ett plugin.

Specifikt byggde vi ett plugin som gjorde det möjligt för oss att se alla post-metadata som är kopplade till ett visst inlägg i WordPress instrumentbräda.

Pluggen är tillgänglig för nedladdning på GitHub där du också kan bläddra i källkoden, se kodkommentaren och se allat det som gick till att skapa plugin när vi utvecklade det.

Sedan det aktuella inlägget skrevs, har jag fått ett antal olika frågor, varav en har varit hur tar vi data som visas i instrumentbrädan - det vill säga postmetadata - och visar den på webens främre ände webbplats.

I den här artikeln ska vi titta på att utvidga plugin så att vi kan visa data på en enda inläggssida. Vi ska prata om hur man gör detta med tanke på vår befintliga kod, hur man gör det, och vi ska också prata om varför det här inte är en bra idé.

Så med det sagt, låt oss börja.

Ramifications of Extend plugin

Innan vi hoppar in i planeringen av hur vi faktiskt kommer att expandera pluginet, tycker jag att det är värt att ha en kort diskussion om varför att visa denna typ av information på fronten - även om det är möjligt - kanske inte en bra idé.

Det vill säga att jag tycker att det här är ett fall för hur, när det handlar om vissa typer av data, är det viktigt att överväga konsekvenserna av vad vi väljer att göra när man bygger produkter till andra och hur vi hanterar data.

Kort sagt, bara för att vi kan gör något betyder inte att vi skall gör det.

En titt på data

Tänk på det på så sätt: Metadata som är kopplade till ett visst inlägg lagras i databasen - en del av WordPress, vissa av teman och några av plugins - som alla använder informationen för sina egna specifika behov.

Om du tittar på bilden ovan kommer du märka att vissa rader identifieras med nycklar prefixade med ett understreck. Till exempel ,, vi har _edit_lock och _edit_last och sedan några numeriska värden. Detta är ett exempel på data som WordPress använder för att internt hantera postens status.

De andra nycklarna som du ser har att göra med plugins som jag har installerat i min lokala WordPress-installation och används för att visa hur andra verktyg kan spara data till metatatabellen och sedan relatera den till det angivna inlägget.

Vad är problemet?

Problemet med att visa all denna information på framsidan är att du kan visa för mycket information till användaren.

I det ovanstående fallet finns inget som är särskilt farligt eller känsligt som kan bidra till att kompromissa installationen, men det betyder inte att det alltid kommer att bli fallet. Ännu längre är det en stor chans att du kanske kan visa information som är relaterad till ett plugin eller tema som aldrig ville ha informationen visad.

Dessutom, för många - eller till och med de flesta - personer som besöker en blogg, ser den information som visas på framsidan av bloggen ut som ljud. Det är teknisk jargong som inte betyder någonting. Det är därför jag tycker att det är det bästa stället att göra den här informationen omdirigerad till instrumentbrädan.

Men vi kommer att förlänga plugin?

Kortfattat, men inte för att jag anser att den här typen av information är användbar för användaren är en bra idé, men eftersom det finns en praktisk applikation som kommer med att utöka ett befintligt plugin, är fördelarna med att utnyttja befintlig kod och se de negativa konsekvenserna av gör sådan.

Så ja - ibland kan de bästa lärdomarna komma från att implementera idéer som kanske inte är bra i efterhand.

Men det är okej. Så här lär vi oss rätt?

Dessutom finns det fortfarande några praktiska lektioner som följer med att lära sig att utöka en befintlig kodbas.

Utvidga enstaka Meta Manager

Som med alla handledningar som jag delar, försöker jag planera ut exakt Vad vi gör innan vi gör det så att vi inte kodar genom mycket gissningsarbete och så att vi har en handlingsplan för hur vi ska arkitektera vår lösning.

Så innan du går vidare, om du inte har granskat meta-administratören för enstaka inlägg, gör du det nu och vi fortsätter.

En gång gjort, här är vad vi ska planera att göra:

Vi använder det vanliga tjugofemtemet som grund för vårt exempel.
Vi presenterar en offentlig katalog som ska användas för att visa informationen på offentlig sidan av bloggen, särskilt inom ramen för enskilda inlägg.
Vi definierar krokar som gör det möjligt för oss att lägga till information till innehållet i inlägget så att post-metadata kan visas längst ner på innehållet. Vi använder ett rudimentärt bord för detta som kommer att få ärva av stilar från det aktuella temat. Observera att du med det här kan sluta ha några riktigt rena stilar, och du kan sluta ha några riktigt svaga stilar. Dessa kommer att vara upp för dig att genomföra på egen hand.
Vi utnyttjar sedan den mall som vi skapade i den inledande versionen av pluginet för att se till att posta metadata för det angivna inlägget för att visa det på frontänden.

Ingenting för komplicerat, eller hur? Vi behöver bara vara exakta i våra steg. Så låt oss börja.

Presentera den offentliga katalogen

Om du antar att du har tjugofemt redan aktiverat och plugin installerat, låt oss börja arbeta med att introducera vår funktionalitet. Det första vi behöver göra är att

introducera a offentlig katalog
Lägg till Single_Post_Meta_Manager_Public klass
inkludera klassen i kärna plugin filen

Efter att du har lagt till filerna kan ovanstående göras med följande rader av kod till load_dependencies funktion i includes / single-post-meta-manager.php.

privata funktioner load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'Admin / klass-single-post-meta-manager-admin.php'; require_once plugin_dir_path (dirname (__FILE__)). 'Offentligt / klass single-post-meta-manager-public.php'; require_once plugin_dir_path (__FILE__). 'Klass-single-post-meta-manager-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader ();

Observera att den enda nya raden är den andra require_once uttalande som importerar klassfilen.

Därefter ska vi definiera egenskaper, konstruktörer och metoder för Single_Post_Meta_Manager_Public klass:

version = $ version;  / ** * Använder den del som finns i admin-katalogen för att göra * post-metadata slutet av inläggets innehåll. * * @param string $ content Inläggets innehåll. * @return string $ content Inläggets innehåll inklusive de givna inlägget metadata. * / public function 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. = $ mall; ob_end_clean (); returnera $ content;

Därefter måste vi skapa enhetschef för Single Post Meta define_public_hooks fungera. Det här ska se ut så här:

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

Därefter måste vi definiera ett samtal till denna funktion inom konstruktören. Det är precis under $ This-> define_admin_hooks (); rad, lägg till $ This-> define_public_hooks (); ring upp.

Om du antar att allt har gått bra, ska du kunna aktivera pluginet, ladda upp ett inlägg och se samma metadata som nu visas på framsidan av inlägget och i kontrollpanelen i posten:

Sammanfattning

Som tidigare nämnts i denna handledning är det inte nödvändigtvis att visa denna typ av information på den främre änden av ett inlägg. Men hur man praktiskt lägger till ett befintligt plugin kommer att introducera helt ny funktionalitet samtidigt som man återanvändar några av de befintliga komponenterna.

I slutändan är nyckeln ta bort två gånger:

Att utnyttja befintlig kod är en kraftfull sak
Att exponera data som är irrelevant för användarna är en farlig idé

Så efter att du läst denna speciella handledning noterar du att jag inte nödvändigtvis godkänner att du gör det på en produktionsnivå, men mer som ett lärandeverktyg. Det är, använd det på egen risk.

Vänligen lämna alla dina frågor, kommentarer och mer i foderet nedan som vanligt!

Koda