Wat is er mis mee?

Nou eigenlijk niets. Maar het kan schoner, gemakkelijker te schalen en beter onderhouden worden!

Als we van boven naar beneden rennen, kunnen we zien dat we allemaal binnen een enkele functie:

1. De database opvragen voor berichten van een bepaald type
2. Een HTML-tekenreeks toewijzen aan een variabele
3. Een lus uitvoeren en verdere markeringen aan de tekenreeks toevoegen
4. De opgebouwde reeks retourneren

Nu kun je er heel goed naar kijken en denken "Big deal! Het is maar een paar regels HTML, wat is het probleem?" In sommige opzichten sta je goed achter je rechten om zo te denken. Maar onthoud, het is slechts 17 regels code op dit moment - wat gebeurt er wanneer u de plug-in uitbreidt / verbetert? Wat gebeurt er wanneer uw plug-in groeit tot 50/100/1000 regels code (of meer!). Zult u nog steeds blij zijn dat op verschillende plaatsen HTML-reeksen rond uw functie zijn verspreid? Wat gebeurt er als je wat HTML wilt uitvoeren die wat onhandige 'ontsnapping' nodig heeft om correct te werken binnen je PHP-code?

Hopelijk kun je zien dat deze aanpak voor het maken en uitvoeren van HTML-markeringen erg problematisch kan worden! Om nog maar te zwijgen over het feit dat het erg moeilijk wordt om de HTML te onderhouden en te verbeteren wanneer deze net is verspreid.

Dus met dit alles in gedachten, heb ik het op mezelf genomen om de manier waarop je denkt over het uitvoeren van HTML in WordPress te veranderen. Voor altijd.

Stap 2 De View Renderer-plugin bouwen

Oké, laten we hiermee beginnen.

Maak de bestanden en mappen

1. Maak een nieuwe map met plug-ins genaamd Uitzicht
2. Maak in die map het plug-in bestand aan view_renderer.php
3. Maak nu een bestand met de naam view.php - Dit zal onze klas zijn

Neem de klas op

Onze plug-in is eenvoudig, hij bevat alleen de Uitzicht klasse, zodat we deze in een van onze andere plug-ins kunnen gebruiken.

 / * view_renderer.php * / include ('View.php');

Ok, nu dat we de hebben opgenomen Uitzicht klas, het is tijd om het echt te bouwen.

De bekijkklasse

Hier hebben we een klasse genaamd Uitzicht met een enkele statische functie genaamd geven (hierdoor kunnen we de syntaxis gebruiken Bekijken :: render ($ template) vanaf elke locatie binnen onze plug-ins) en er zijn twee parameters nodig:

1. $ filePath - Het pad naar het sjabloonbestand. Vergeet niet dat we onze sjablonen binnen de Uitzicht map die we eerder hebben gemaakt
2. $ Viewdata - Alle variabelen waartoe we toegang zouden willen hebben binnen de sjabloon (veel meer hierover later)

Kopieer de onderstaande code naar view.php:

Dus wat precies gaat hier door?

1. Allereerst kijken we of het $ Viewdata varible heeft een waarde (dat wil zeggen, hebben we iets verzonden om in de sjabloon te gebruiken?). Als dit het geval is, extraheren we de inhoud (later meer hierover)

2. Vervolgens maken we gebruik van de uitvoerbuffer van PHP. Hiermee kunnen we een PHP-bestand analyseren en de inhoud opslaan in een variabele

3. Eindelijk geven we de string terug

Opmerking: vergeet niet om de plug-in nu vanuit het beheerdersdashboard te activeren

Het lijkt vrij eenvoudig he? Precies! Maar hoewel het een erg simpele kleine functie lijkt, biedt het ons eigenlijk de luxe om onze plug-ins op een supergeorganiseerde, schaalbare en onderhoudbare manier te kunnen schrijven. Laat me alsjeblieft demonstreren ...

Stap 3 Een voorbeeld uit de echte wereld

Laten we een eenvoudige plugin maken genaamd schuif

** Opmerking: dit is alleen voor demonstratiedoeleinden. U kunt hier uw eigen plug-in gebruiken.

1. Maak een map met de naam schuif
2. Maak in die map een bestand met de naam Slider.php
3. Kopieer de onderstaande code naar Slider.php

Voeg een shortcode toe

OK, nu gaan we een shortcode toevoegen die de laatste 5 berichten zal ophalen en ze in een lijst met de titel en inhoud zal weergeven. (Kortheidshalve zullen we onze plugin-klasse en onze actie toevoegen aan hetzelfde plugin-bestand, maar doe dit alsjeblieft niet in 'real-life': p)

 / ** * Voeg de shortcode toe (PHP 5.3 en hoger) * / add_shortcode ('slider', function () return Slider :: display (););

Dat zal ons in staat stellen om gewoon te gebruiken [Slider] in elke post / pagina en wordt het resultaat van Slider :: display ()

Voeg de Slider Class & toe display () Methode

 class Slider public static function display () // HTML-code HIER. 

Ontvang de laatste 5 berichten.

 / * * Ontvang de laatste 5 berichten * / openbare statische functie weergave () $ posts = get_posts (array ('numberposts' => 5)); 

Nu hebben we een reeks van post objecten en we zijn klaar om onze HTML op te bouwen door ze door te lussen. Maar we beginnen hier niet eenvoudig HTML-strings in onze functie in te voegen! In plaats daarvan gaan we de array met objecten doorgeven aan een sjabloonbestand en alle HTML-code uit de weg geruimd.

Maak de sjabloon

1. Maak een map met de naam templates
2. Maak in die map een bestand met de naam 01.template.php

Deze sjabloon bevat al onze markeringen en biedt ons toegang tot de gegevens die we hebben sturen er later op.

Gegevens naar de sjabloon verzenden

Telkens als we variabelen binnen onze sjablonen willen gebruiken, kunnen we eenvoudigweg sturen door een waarde in te stellen in de $ Viewdata matrix. Iedereen die vertrouwd is met het gebruik van MVC-frameworks, zal zich bij deze aanpak zeer thuis voelen.

 $ viewData = array ('posts' => $ posts);

De array sleutel hier ('posts') is belangrijk omdat we zo naar de gegevens in de sjabloon verwijzen. (Je kunt dit noemen wat je maar wilt, maar houd je aan iets dat logisch is.)

De sjabloon bouwen

Ok, dus we hebben gekeken naar hoe we de laatste 5 berichten kunnen ophalen en hoe we die reeks objecten naar de sjabloon kunnen sturen, het is nu tijd om het sjabloonbestand uit te werken.

 
 
   
 
post_title?>
 
post_content?>
 
   
 

Ah! Hoe prettig voelt het om al die markup in zijn eigen aparte bestand te hebben, weg van onze logica voor het ophalen van gegevens en programmeren? Geweldig, ik weet het! Het belangrijkste onderdeel van deze aanpak is dat we alleen gegevens uit variabelen binnen de sjabloon 'benaderen'. Alle 'logica' moet worden gedaan binnen de methode die de sjabloon aanroept. Dit leidt tot een zeer mooie workflow omdat u uw zorgen volledig oplost.

Stelt u zich eens voor hoe gemakkelijk het nu is wanneer u klaar bent om op deze plug-in te bouwen. Nooit meer aaneenschakeling van tekenreeksen en ontsnapte personages binnen functies.

De teruggegeven sjabloon retourneren

Ok, we hebben alle onderdelen gezien, laten we eens kijken hoe alles bij elkaar past, zodat we een sjabloon kunnen renderen en een string terug kunnen krijgen (dat we dan terug kunnen gaan naar onze shortcode):

1. Eerst moeten we een verwijzing naar onze sjabloon opslaan in een statische eigenschap
2. Dan moeten we controleren of de Uitzicht klasse bestaat
3. Vervolgens genereren we het volledige pad naar ons sjabloonbestand door een verwijzing naar de huidige plugin-map te pakken en onze statische eigenschap samen te voegen $ template
4. Eindelijk noemen we onze View :: render () methode en geef deze de twee benodigde parameters door

In dit geval, wij terugkeer het resultaat van de gerenderde sjabloon, want dat is hoe shortcodes werk. Maar als je het nodig had echo de resultaten in plaats daarvan (wanneer u bijvoorbeeld een beheerderspagina maakt, verwacht de terugbelfunctie dat uw uitvoer direct wordt afgedrukt), waarna terugkeer met echo.

De display () Methode volledig

 class Slider static $ template = '/templates/01.template.php'; openbare statische functie weergave () if (class_exists ('Weergave')) // Verkrijg de laatste 5 berichten $ posts = get_posts (array ('numberposts' => 5)); // Stel data in $ viewData = array ('posts' => $ posts); // Haal het volledige pad naar het sjabloonbestand. $ templatePath = dirname (__FILE__). statische :: $ template; // Retourneer de gerenderde HTML return View :: render ($ templatePath, $ viewData);  else return "U probeert een sjabloon weer te geven, maar we kunnen de View Class niet vinden"; 

Ik hoop dat je het organisatieniveau van deze aanpak kunt waarderen! Nu jij tonen functie is alleen verantwoordelijk voor het verzamelen van de gegevens die het nodig heeft en het retourneren van het resultaat van de gegenereerde sjabloon.

Verder nemen

Ons voorbeeld hierboven gaat over zo eenvoudig als het wordt. Toch is het nog steeds een enorm verbeterde workflow. Laten we nu eens naar een ander voorbeeld kijken dat laat zien hoe nuttig het echt kan zijn.

Stel dat uw plug-in gebruikmaakt van een aangepaste metabox. Om dat te doen, moeten we:

1. Voeg een constructorfunctie toe aan de schuif klasse
2. Voeg een methode toe om de metabox aan elk bericht toe te voegen
3. Voeg een callback-methode toe om de HTML voor de metabox weer te geven
4. Voeg de juiste hook toe aan het plugin-bestand om de klasse alleen te instantiëren bij het toevoegen / bewerken van posts
5. Ten slotte zouden we een sjabloonbestand toevoegen zoals we eerder deden, en het toevoegen als een eigenschap aan het begin van de klas

 class Slider static $ metaBox = '/templates/metabox.template.php'; openbare functie __construct () add_action ('add_meta_boxes', array ($ this, 'add_some_meta_box'));  / ** * Voegt de metabox toe container * / publieke functie add_some_meta_box () add_meta_box ('some_meta_box_name', 'Some Meta Box Headline', array ($ this, 'render_meta_box_content'), 'post', 'advanced', ' hoog ',);  / ** * Render Meta Box-inhoud * / openbare functie render_meta_box_content () / ** From the Codex ** / echo '
TEST UITVOERING - dit wordt weergegeven in de metabox.
';  // class // voeg de actie hook-functie toe call_Slider () return new Slider ();  if (is_admin ()) add_action ('load-post.php', 'call_Slider');

Bekijk de render_meta_box_content methode daar. Het is de perfecte gelegenheid om de View Renderer te gebruiken! Stel je een realistischer voorbeeld als dit voor:

 / ** * Render Meta Box-inhoud * / publieke functie render_meta_box_content ($ post) $ name = get_post_meta ($ post-> ID, "name"); $ fieldName = static :: $ fieldName; echo '
Uw naam: 
'; echo 'Naam: '; echo ''; echo 'Bijwerken'; 

Urg! Natuurlijk wordt het werk gedaan, maar het is zo moeilijk om het op deze manier te doen! Wat als we in plaats daarvan onze View Renderer gebruiken.

 / ** * Render Meta Box-inhoud * / openbare functie render_meta_box_content ($ post) $ viewData = array ('name' => get_post_meta ($ post-> ID, 'name'), 'field' => static :: $ veldnaam ); $ templatePath = dirname (__FILE__). statische :: $ Metabox; echo View :: render ($ templatePath, $ viewData); 

En in het sjabloonbestand:

 
Uw naam: 
  Naam:   Bijwerken

Het lijkt in dit voorbeeld misschien maar een heel klein voordeel. Maar geloof me, als je je zorgen zo apart houdt, word je een veel betere WordPress-ontwikkelaar vrij snel.

Conclusie

Ik denk dat je nu waarschijnlijk een goed begrip hebt van wat we hier proberen te bereiken en ik dring er bij je op aan om deze techniek te gebruiken bij het bouwen van plug-ins in de toekomst. Hopelijk vindt u 'scheiding van punten van zorg' om van nut te zijn voor u.

Tutorial opmerkingen:

• Hoewel we de View Renderer zelf hebben gemaakt tot een plug-in, kon je deze eenvoudig toevoegen aan bestaande plug-ins. Hiermee wordt de extra stap verwijderd om ervoor te zorgen dat de plug-in is geactiveerd voordat u deze ergens gebruikt.
• U bent niet beperkt tot de use-cases die in deze zelfstudie worden uitgelegd, het kan overal worden gebruikt waar u normaal HTML zou uitvoeren (hoe zit het met het gebruik van een sjabloonbestand om een ​​aantal 'in-line' JavaScript uit te voeren? Of over een aantal specifieke CSS-regels op basis van opties opgehaald uit de database?)

Ik zou graag willen weten wat voor toepassingen je hebt gevonden voor deze techniek, dus deel deze alsjeblieft in de comments :)