Hoe Post-metadata te tonen op een WordPress-bericht

In mijn laatste serie artikelen hebben we gekeken naar de concepten van objectgeoriënteerd programmeren vanuit het perspectief van de beginner. Het doel van de serie was om degenen die niet vertrouwd waren met object-georiënteerd programmeren in PHP te nemen en de fundamentele aspecten van het paradigma in de context van WordPress te verkennen..

Als je de serie niet hebt gelezen, kun je een korte samenvatting (samen met links naar elk artikel in de serie) in het laatste bericht lezen.

In de loop van de serie is een van de dingen die we hebben gedaan om de objectgeoriënteerde principes te helpen demonstreren, evenals enkele functies van de WordPress API, een plug-in gebouwd. 

We hebben met name een plug-in gebouwd waarmee we alle post-metadata kunnen bekijken die aan een bepaald bericht in het WordPress-dashboard zijn gekoppeld.

De plug-in is beschikbaar om te downloaden op GitHub, waar je ook kunt bladeren door de broncode, de opmerkingen over de code kunt bekijken en over het algemeen alles kunt zien dat is overgegaan in het maken van de plug-in toen we deze ontwikkelden.

Sinds die specifieke post is geschreven, heb ik een aantal verschillende vragen ontvangen, waarvan er een is hoe we de gegevens die in het dashboard worden weergegeven - dat wil zeggen, de post-metadata - weergeven en weergeven op de voorkant van het web plaats.

In dit artikel gaan we kijken hoe we de plug-in zodanig kunnen uitbreiden dat we de gegevens op één enkele pagina kunnen weergeven. We gaan het hebben over hoe dit te doen gezien onze bestaande code, hoe dit te doen, en we gaan ook praten over waarom dit misschien geen goed idee is.

Dus met dat gezegd, laten we beginnen.

Versterkingen van het uitbreiden van de plug-in

Voordat we beginnen met het plannen van hoe we de plug-in daadwerkelijk gaan uitbreiden, denk ik dat het de moeite waard is om een ​​korte discussie te hebben waarom het weergeven van dit soort informatie op de frontend - hoewel mogelijk - misschien geen goed idee is.

Dat wil zeggen dat ik denk dat dit aantoont hoe, bij het omgaan met bepaalde soorten gegevens, het belangrijk is om na te denken over de consequenties van wat we doen wanneer we producten voor anderen bouwen en hoe we de gegevens beheren.

Kortom, alleen omdat wij kan iets doen, betekent niet dat wij moeten doe het.

Een blik op de gegevens

Zie het op deze manier: de metagegevens die zijn gekoppeld aan een bepaald bericht worden opgeslagen in de database - sommige door WordPress, sommige door thema's en sommige door plug-ins - die allemaal de informatie gebruiken voor hun eigen specifieke behoeften.

Als u de bovenstaande afbeelding bekijkt, ziet u dat sommige rijen worden aangeduid met sleutels die zijn voorafgegaan door een onderstrepingsteken. Bijvoorbeeld, we hebben _edit_lock en _edit_last en dan een aantal numerieke waarden. Dit is een voorbeeld van gegevens die WordPress gebruikt om de status van de berichten intern te beheren.

De andere sleutels die u ziet hebben te maken met plug-ins die ik heb geïnstalleerd in mijn lokale WordPress-installatie en worden gebruikt om te demonstreren hoe andere hulpprogramma's gegevens kunnen opslaan in de metatatabel en deze vervolgens kunnen relateren aan het gegeven bericht.

Wat is het probleem?

Het probleem met het weergeven van al deze informatie aan de voorkant is dat je te veel informatie aan de gebruiker zou kunnen tonen. 

In het bovenstaande geval is er niets dat bijzonder gevaarlijk of gevoelig is dat de installatie kan schaden, maar dat betekent niet dat dit altijd het geval zal zijn. Verder is er een grote kans dat je uiteindelijk informatie krijgt die gerelateerd is aan een plug-in of een thema waarvan de informatie nooit werd weergegeven.

Bovendien zal voor veel - of zelfs de meeste - mensen die een blog bezoeken, het zien van de informatie die aan de voorkant van de blog wordt weergegeven, op ruis lijken. Het is technisch jargon dat niks zal betekenen. Dit is waarom ik denk dat het bewaren van deze informatie op het dashboard de beste plaats is om het te doen.

Maar we gaan de plug-in uitbreiden?

Kortom, ja, maar niet omdat ik denk dat het weergeven van dit soort informatie voor de gebruiker een goed idee is, maar omdat er een praktische toepassing is die wordt geboden door het uitbreiden van een bestaande plug-in, de voordelen van het gebruik van bestaande code en het zien van de negatieve gevolgen van doen.

Dus ja - soms kunnen de beste lessen voortkomen uit het implementeren van ideeën die achteraf misschien niet goed zijn. 

Maar dat is oke. Dit is hoe we leren, goed?

Plus, er zijn nog steeds enkele praktische lessen die horen bij het leren uitbreiden van een bestaande codebasis.

Single Post Meta Manager uitbreiden

Zoals met alle tutorials die ik deel, probeer ik precies te plannen wat we moeten doen voordat we het doen, zodat we niet veel giswerk hoeven te coderen, en zodat we een actieplan hebben voor het ontwerpen van onze oplossing.

Dus, voordat je verder gaat, als je de Single Post Meta Manager niet hebt bekeken, doe dat dan nu en we gaan door.

Als dit is gebeurd, is dit wat we van plan zijn te doen:

1. We zullen het standaard twintig-veertien-thema gebruiken als basis voor ons voorbeeld.
2. We introduceren een openbare map die zal worden gebruikt om de informatie over de openbaar kant van de blog specifiek in de context van afzonderlijke berichten.
3. We zullen haken definiëren waarmee we informatie aan de inhoud van de post kunnen toevoegen, zodat de post-metagegevens onder aan de inhoud kunnen worden weergegeven. We gebruiken hiervoor een rudimentaire tabel die stijlen van het huidige thema erven. Houd er rekening mee dat je hierdoor een aantal echt schone stijlen kunt krijgen en dat je uiteindelijk heel zwakke stijlen zult hebben. Deze zijn voor u om zelf te implementeren.
4. We maken dan gebruik van de sjabloon die we in de eerste versie van de plug-in hebben gemaakt om ervoor te zorgen dat de post-metadata voor het gegeven bericht worden opgehaald om deze aan de voorkant weer te geven.

Niets is te gecompliceerd, toch? We moeten gewoon precies zijn in onze stappen. Dus laten we beginnen.

Introduceer de Public Directory

Ervan uitgaande dat je twintigveertien al hebt geactiveerd en de plug-in hebt geïnstalleerd, gaan we aan de slag om onze functionaliteit te introduceren. Het eerste dat we moeten doen is 

• introduceer een openbaar directory
• voeg het toe Single_Post_Meta_Manager_Public klasse
• de klasse opnemen in het kerninvoegbestand

Na het toevoegen van de bestanden kan het bovenstaande worden gedaan door de volgende coderegels naar de load_dependencies functie in includes / single-post-meta-manager.php.

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

Merk op dat de enige nieuwe regel de tweede is eenmalig benodigd instructie die het klassenbestand importeert. 

Hierna definiëren we de eigenschappen, constructor en methoden voor de Single_Post_Meta_Manager_Public klasse:

versie = $ versie;  / ** * Gebruikt de gedeeltelijke locatie in de beheerdersdirectory voor het renderen van de * post-metadata aan het einde van de berichtinhoud. * * @param string $ content De berichtinhoud. * @return string $ content De berichtinhoud inclusief de gegeven metadata van berichten. * / 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 (); $ inhoud. = $ sjabloon; ob_end_clean (); return $ inhoud; 

Vervolgens moeten we de Single Post Meta Manager's maken define_public_hooks functie. Dit zou er als volgt uit moeten zien:

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

Vervolgens moeten we een aanroep voor deze functie binnen de constructor definiëren. Dat wil zeggen, net onder de $ This-> define_admin_hooks (); regel, toevoegen $ This-> define_public_hooks (); telefoontje.

Ervan uitgaande dat alles goed is gegaan, zou je in staat moeten zijn de plug-in te activeren, elk bericht te laden en dezelfde metagegevens te zien die nu zowel in de voorkant van de post als in het dashboard van de post worden weergegeven:

Samenvatting

Zoals eerder in deze zelfstudie is vermeld, is het weergeven van dit soort informatie aan de voorkant van een bericht niet altijd het beste idee; Als u echter leert hoe u praktisch kunt toevoegen aan een bestaande plug-in, wordt geheel nieuwe functionaliteit geïntroduceerd en worden sommige van de bestaande componenten opnieuw gebruikt.

Uiteindelijk is de belangrijkste bezigheid tweeledig:

• Gebruik maken van bestaande code is een krachtig iets
• Het blootstellen van gegevens die niet relevant zijn voor gebruikers is een gevaarlijk idee

Dus na het lezen van deze specifieke tutorial, merk ik op dat ik dit niet noodzakelijkerwijs doe om dit in een productieniveau te doen, maar meer als een leermiddel. Dat wil zeggen, gebruik het op eigen risico.

Laat zoals gewoonlijk al uw vragen, opmerkingen en meer in de onderstaande feed staan!