Share
In deze serie hebben we bekeken hoe we een systeem kunnen implementeren waarmee we op programmatische wijze aangepaste berichten kunnen definiëren die op een bepaalde beheerpagina in de WordPress-backend worden weergegeven.
Als je tot nu toe de reeks hebt gevolgd, dan weet je:
Zoals vermeld in de vorige tutorial:
Maar als je een van mijn eerdere tutorials hebt gelezen, weet je dat ik geen fan ben van het hebben van gedupliceerde code. Noch ben ik fan van het feit dat een klas veel dingen doet. En, helaas, dat is precies wat we hier doen.
En we gaan dat in deze laatste tutorial aanpakken. Tegen het einde hebben we een compleet gereformeerde oplossing die gebruik maakt van een aantal objectgerichte middenobjecten, zoals overerving. We zullen ook een paar methoden gebruiken die we programmatisch kunnen gebruiken of die kunnen worden geregistreerd met het WordPress-haaksysteem.
Op dit punt zou u precies moeten weten wat u nodig heeft in uw lokale ontwikkelingsomgeving. Concreet zou u het volgende moeten hebben:
Ik raad ook de meest recente versie van de broncode aan, omdat je hiermee alle wijzigingen kunt doorlopen die we gaan maken. Als je het niet hebt, is dat goed, maar ik raad aan om de vorige tutorials te lezen voordat je verder gaat.
Zoals je je wellicht herinnert (of hebt vastgesteld aan de hand van de bovenstaande opmerking), heeft de vorige zelfstudie een klasse achtergelaten die te veel werk deed.
Een manier om dit te weten is dat als je zou beschrijven wat de klas aan het doen was, je geen enkel antwoord zou kunnen geven. In plaats daarvan zou je moeten zeggen dat het verantwoordelijk was voor het verwerken van succesberichten, waarschuwingsberichten, foutmeldingen en ze allemaal onafhankelijk van elkaar weergeven.
En hoewel je misschien zou beweren dat het 'het beheren van aangepaste berichten' was, hoefde je niet per se te beschrijven hoe uitgebreid de klas was. Dat is wat we hopen op te lossen in deze tutorial.
Concreet gaan we kijken naar het volgende:
We hebben ons werk voor ons uit handen, dus laten we doorgaan en aan de slag gaan met al het bovenstaande.
Als het gaat om het refactoren van ons werk, helpt het om precies te weten wat het is dat we willen doen. In ons geval herkennen we dat we veel dubbele code hebben die kan worden gecondenseerd.
Bovendien hebben we drie verschillende soorten berichten die op precies dezelfde manier worden beheerd, afgezien van de manier waarop ze worden weergegeven. En in dat geval is het een kwestie van de HTML-klassenattributen.
We kunnen die code dus generaliseren om op een specifiek te focussen type, en we kunnen een groot aantal methoden consolideren voor het toevoegen van succesberichten of het ophalen van foutberichten door een methode te generaliseren om het genoemde te herkennen type.
Uiteindelijk zullen we dat doen. Maar eerst wat schoonmaak.
In de vorige zelfstudies hebben we gewerkt met een klasse genaamd Settings_Messenger. Tot nu toe heeft het zijn doel gediend, maar we gaan deze les refactoren gedurende de rest van deze tutorial.
Als het gaat om dit soort refactoring, is het eenvoudig om gewoon de klas te verwijderen en opnieuw te beginnen. Er zijn tijden waarin dit gepast is, maar dit is niet een van hen. In plaats daarvan nemen we die klas en refactoren wat er al is.
Dat alles om te zeggen, verwijder het bestand niet en begin met een nieuw bestand. Probeer in plaats daarvan bij te houden wat we in deze zelfstudie doen.
Laten we eerst een introduceren Settings_Message klasse. Dit vertegenwoordigt ieder type instellingsbericht waarmee we gaan schrijven. Dat wil zeggen, het zal succesberichten, foutmeldingen en waarschuwingsberichten beheren.
Om dit te doen, zullen we de klasse definiëren, één enkele eigenschap introduceren en dan zullen we deze in de constructor plaatsen. Bekijk deze code, en ik zal hieronder iets meer uitleggen:
Accentsconagua
berichten = array ('succes' => array (), 'error' => array (), 'warning' => array (),); Merk op dat we een privéattribuut hebben gemaakt, $ messages. Wanneer de klasse wordt geïnstantieerd, maken we een multidimensionale array. Elke index, geïdentificeerd door of succes, fout, of waarschuwing, verwijst naar zijn eigen array waarin we de bijbehorende berichten opslaan.
Vervolgens moeten we een bericht kunnen toevoegen, een bericht kunnen ontvangen en alle berichten kunnen ontvangen. Ik zal elk van deze meer in het kort bespreken.
Laten we eerst kijken naar hoe we berichten toevoegen:
berichten [$ type])) retour; array_push ($ this-> messages [$ type], $ message);
Dit bericht neemt eerst de inkomende reeks en zuivert de gegevens. Vervolgens controleert het om te zien of het al bestaat in de succesberichten. Als dat zo is, komt het gewoon terug. We willen immers geen dubbele berichten.
Anders wordt het bericht toegevoegd aan de verzameling.
Het ophalen van berichten bestaat in twee vormen:
Onthoud dat er soms momenten zijn waarop we alleen waarschuwingsberichten willen weergeven. Andere keren willen we misschien alle berichten weergeven. Omdat er twee manieren zijn om dit te doen, kunnen we er een gebruiken en er vervolgens van profiteren in een andere functie.
Geluid verwarrend? Houd me vast en ik zal het allemaal uitleggen. Het eerste deel waar we ons op gaan richten is hoe berichten kunnen worden weergegeven type (denk aan succes, fout of waarschuwing). Hier is de code om dat te doen (en het zou er bekend uit moeten zien):
berichten [$ type])) retour; $ html = ""; $ html. = ''; $ allowed_html = array ('div' => array ('class' => array (),), 'ul' => array (), 'li' => array (),); echo wp_kses ($ html, $ allowed_html);'; foreach ($ this-> messages [$ type] als $ message) $ html. = "
'; $ html. = '- $ message
"; $ html. = '
Merk hier op dat we veel van dezelfde code uit de vorige zelfstudie gebruiken; we hebben het echter gegeneraliseerd zodat het naar de binnenkomende kijkt Type $ en past het dynamisch toe op de markup.
Dit stelt ons in staat om een enkele functie te hebben voor het weergeven van onze berichten. Dit is echter niet alles. Hoe zit het met de keren dat we willen krijgen allemaal berichten? Dit zou kunnen zijn om op een pagina te renderen of ze programmatisch te pakken voor een andere verwerking.
Om dit te doen, kunnen we een andere functie introduceren:
berichten als $ type => $ bericht) $ this-> get_messages ($ type);
Dit bericht moet gemakkelijk genoeg zijn om te begrijpen. Het doorloopt gewoon alle berichten die we in onze verzameling hebben en roept de get_messages functie die we hierboven hebben geschetst.
Het maakt ze nog steeds allemaal samen (waarvan we er één zullen zien in onze tijdelijke implementatie van een aangepaste haak). Als je ze voor een ander doel zou willen gebruiken, zou je het resultaat in een string kunnen voegen en het aan de beller kunnen teruggeven, of een andere programmatische functie kunnen uitvoeren.
Dit is maar één implementatie.
Dat doet het voor de echte Settings_Message klasse. Maar hoe communiceren we ermee? Natuurlijk kunnen we er direct mee praten, maar als er een tussenklasse is, hebben we controle over wat er aan ons is teruggegeven zonder meer verantwoordelijkheid toe te voegen aan de Settings_Message klas, rechts?
Ga naar Settings_Messenger. Deze klasse is verantwoordelijk voor ons om instellingenberichten te lezen en te schrijven. Ik denk dat er een zaak gemaakt zou kunnen worden dat je dit in twee klassen zou kunnen splitsen door zijn verantwoordelijkheid omdat het zowel leest als schrijft maar als een boodschapper die verzendt en ontvangt, dat is het doel van deze klasse.
De eerste configuratie van de klas is eenvoudig.
Settings_Message klasse die we kunnen gebruiken om berichten te verzenden en ontvangen.tutsplus_settings_messages haak die we in een eerdere tutorial hebben gedefinieerd.Bekijk de eerste paar methoden:
message = new Settings_Message (); openbare functie init () add_action ('tutsplus_settings_messages', array ($ this, 'get_all_messages')); Onthoud eerder in deze tutorial dat we de haak hebben gedefinieerd in onze weergave, die u kunt vinden in settings.php. Voor de volledigheid staat het hier:
We gaan geen opties op deze pagina weergeven. In plaats daarvan gaan we deze pagina gebruiken om te demonstreren hoe we onze aangepaste messenger kunnen gebruiken.
Merk echter op dat deze specifieke haak gebruik maakt van de get_all_messages methode die we in een ogenblik zullen bespreken. Het hoeft deze methode niet te gebruiken. In plaats daarvan, het kon worden gebruikt om eenvoudig succesberichten of andere methoden die u wilt gebruiken, weer te geven.
Het creëren van de functies om berichten toe te voegen is eenvoudig omdat deze functies een type en het bericht zelf vereisen. Herinner de Settings_Message zorgt voor het ontsmetten van de informatie, zodat we de binnenkomende berichten eenvoudig kunnen doorgeven.
Zie hieronder waar we succes-, waarschuwings- en foutmeldingen toevoegen:
add_message ('succes', $ bericht); openbare functie add_warning_message ($ message) $ this-> add_message ('warning', $ message); openbare functie add_error_message ($ bericht) $ this-> add_message ('error', $ message); Het is gemakkelijk, is het niet?
Het ophalen van berichten is niet veel anders, behalve dat we alleen het type berichten moeten opgeven dat we willen ophalen:
get_messages ('succes'); openbare functie get_warning_messages () echo $ this-> get_messages ('warning'); openbare functie get_error_messages () echo $ this-> get_messages ('error'); Klaar en klaar, goed?
Merk op dat de berichten vooral verwijzen naar twee andere methoden die we nog niet hebben behandeld. Dit zijn privéberichten die ons helpen de bovenstaande oproepen te vereenvoudigen.
Bekijk de volgende privémethoden die beide verantwoordelijk zijn voor het toevoegen en ophalen van berichten rechtstreeks vanuit de Settings_Message instance gehandhaafd op het messenger-object:
bericht-> add_message ($ type, $ bericht); private functie get_messages ($ type) return $ this-> message-> get_messages ($ type);
En dat wraps de nieuwe Settings_Messenger klasse. Dit is allemaal veel eenvoudiger, nietwaar?
Het roept echter de vraag op: hoe beginnen we de plug-in nu we al deze wijzigingen hebben gehad?
Bekijk de volledige functie hieronder:
in het(); $ messenger = new Settings_Messenger (); $ Messenger-> init (); $ messenger-> add_success_message ('Mooi gefotografeerd jochie, dat was één op de miljoen!'); $ messenger-> add_warning_message ('Gaan niet voorzichtig in die goede nacht.'); $ messenger-> add_error_message ('Danger Will Robinson.'); En dat is het.
Een paar punten om op te merken:
Settings_Messenger, dan hoef je je geen zorgen te maken over het weergeven van berichten op je instellingenpagina.Settings_Messenger, maar het komt er eigenlijk niet uit omdat ik ben met behulp van de methode init.Dat is alles voor de refactoring. Dit zal niet werken precies uit de doos, omdat er nog steeds een code nodig is om alle PHP-bestanden te laden die nodig zijn om de plug-in te laten werken; de bovenstaande code richt zich echter op de refactoring, wat het punt is van deze hele tutorial.
Voor een volledig werkende versie van deze tutorial en complete broncode dat doet werk uit de doos, download de broncode die aan dit bericht is gekoppeld op de rechterzijbalk.
Ik hoop dat je in de loop van dit materiaal een aantal nieuwe vaardigheden en manieren hebt opgepikt om WordPress-ontwikkeling te benaderen. Bij het bekijken van de serie hebben we veel behandeld:
Zoals gewoonlijk ben ik ook altijd bereid om vragen te beantwoorden via de reacties, en je kunt ook mijn blog bekijken en me volgen op Twitter. Ik praat meestal ook over softwareontwikkeling binnen WordPress en tangentiële onderwerpen. Als je geïnteresseerd bent in meer WordPress-ontwikkeling, vergeet dan niet om mijn vorige series en tutorials te bekijken, en het andere WordPress-materiaal dat we hier op Envato Tuts hebben+.
