Een aangepast WordPress-berichtensysteem maken, deel 2

Als u nu net bezig bent met deze specifieke serie, zijn we bezig met het bouwen van ons eigen aangepaste berichtensysteem dat aansluit op WordPress, waardoor we kunnen profiteren van enkele van de bestaande API's, maar ons ook iets meer kunnen laten controle.

Van de vorige tutorial:

Maar net zoals we hebben gekeken naar het maken van aangepaste beheerpagina's, is het ook mogelijk om een ​​systeem te implementeren waarmee we onze eigen aangepaste berichten, hun type en wanneer en waar ze op de beheerpagina kunnen weergeven, instellen. 

Hoewel het niet nodig is om de serie voorafgaand aan deze te lezen, raad ik aan de voorgaande zelfstudie te lezen. Elk van deze bouwt voort op de basis van de vorige tutorial (en we zullen dat blijven doen voor de rest van de serie).

Met dat gezegd, het hele doel van deze serie is om een ​​inleiding te geven over hoe we de WordPress API en object-georiënteerd programmeren kunnen gebruiken om een ​​aangepast berichtensysteem te creëren dat we kunnen gebruiken tijdens het werk dat we misschien voor een klant doen.

Maar voordat we aan de slag gaan, zijn er enkele vereisten waaraan u moet voldoen.

Voordat u aan de slag gaat

  • Lees het vorige artikel.
  • Installeer PHP 5.6.25 en MySQL 5.6.28.
  • Installeer Apache of Nginx.
  • Stel WordPress 4.6.1 in.
  • Zorg dat je favoriete IDE of editor klaar is.

Als u op zoek bent naar een alles-in-één oplossing, bekijk dan MAMP, en als u geïnteresseerd bent in hoe dit allemaal bij elkaar past, bekijk dan deze artikelen.

Onze routekaart

Als je toevallig de vorige tutorial niet hebt gelezen, is de routekaart die we voor deze tutorial hebben opgesteld als volgt:

  1. In deze tutorial leggen we de basis voor het absolute minimum van onze plug-in en wat we nodig hebben om te beginnen.
  2. In het tweede stuk gaan we de plugin een beetje verder nemen door een heel eenvoudige WordPress-beheerpagina toe te voegen. We bellen ook naar de aangepaste haak die we gaan gebruiken, en dat gaan we aan de serverkant verbinden. We beginnen ook met de basis voor onze instellingen Messenger.
  3. In deze zelfstudie beginnen we onze instellingsversie te implementeren door ondersteuning voor fouten en succesberichten toe te voegen en enkele punten over beveiliging te bespreken.
  4. We eindigen door alles samen te binden, het in actie te zien en de laatste plug-in openbaar beschikbaar te maken voor u om te downloaden.

Het is duidelijk dat we nummer één hebben bereikt. Dus in deze tutorial gaan we specifiek focussen op het toevoegen van een basisbeheerpagina en het opzetten van een aangepaste hook waarmee we kunnen profiteren van onze aangepaste messenger.

Terug aan het werk

Met dat alles bedekt, laten we teruggaan naar de ontwikkeling. Bedenk dat we op dit punt de basis van deze plug-in moeten instellen, zodat we deze kunnen activeren en navigeren naar instellingen en dan Voorbeeld Tuts + aangepast bericht om een ​​generieke beheerpagina te zien.

Als je tot nu toe hebt gevolgd, is de code voor de pagina uiterst eenvoudig (en we zullen later een foto van de pagina zien), en:

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.

Ik herhaal dit omdat dit is waar we beginnen met het implementeren van onze eigen aangepaste messenger.

Om dit te doen, moeten we het volgende introduceren:

  1. een haak die we definiëren
  2. een functie die bij die haak is geregistreerd
  3. iets weergeven wanneer die functie is geactiveerd

Een aangepaste haak definiëren

Het definiëren van een aangepaste haak klinkt veel intimideriger dan het in werkelijkheid is. De meesten van ons zijn bekend met het bellen naar add_action en add_filter, maar hoe kunnen we deze functies gebruiken om een ​​oproep te doen naar onze eigen haken?

Eenvoudig: we gebruiken do_action en definieer onze actie die we registreren bij WordPress. Neem bijvoorbeeld de bovenstaande code en, net onder de h1 label, laten we het volgende doen:

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.

Niet slecht, toch? Nu moeten we een functie registreren die wordt geactiveerd wanneer die haak wordt gebeld. Voordat we dat doen, wil ik echter zeker weten dat we allemaal op dezelfde pagina staan ​​als wat do_action echt waar.

Dit is wat het ontwikkelaarsdocument zegt do_action:

Met deze functie worden alle functies opgeroepen die aan de actiehaak zijn gekoppeld $ tag. Het is mogelijk om nieuwe actiehaken te creëren door simpelweg deze functie aan te roepen, door de naam van de nieuwe haak op te geven met behulp van de $ tag parameter.

Als de definitie niet duidelijk is, kan de implementatie ervan misschien helpen. Laten we daar nu eens naar kijken.

2. Registreer een functie

Net zoals we met elk ander type functie doen, moeten we een functie registreren die elke keer dat we werken wordt geactiveerd tutsplus_settings_messages haak is ontslagen. Maar omdat we met objectgeoriënteerd programmeren werken, moeten we een klasse ontwerpen die deze functie definieert.

En dit is waar onze aangepaste instellingen messenger voor het eerst in het spel komt. Toegegeven, we zullen niet veel werk verrichten in termen van het toevoegen van aangepaste berichten, maar wij zullen gebruik onze aangepaste haak en we zullen renderen iets op de pagina.

Verder leggen we de basis voor de klas die we in de komende lessen zullen verbeteren. Voeg hier het bestand toe class-settings-messenger.php naar de beheerder map in uw plug-in (en maak u geen zorgen, dit alles is beschikbaar om te downloaden).

Onthoud dat we in deze zelfstudie geen naamruimten of autoloaders gebruiken (hoewel we ze eerder hebben behandeld). Merk op dat ik code zal leveren voor de in het methode tijdelijk. 

Keer nu terug naar het opstartbestand van de plug-in, tutsplus-maat-message.php, en voeg de volgende code toe aan de hoofdfunctie:

in het(); $ messenger = new Settings_Messenger (); $ Messenger-> init (); 

Laten we nu de init-functie opnieuw bekijken in de Settings_Messenger en sluit het aan op onze aangepaste actie.

Let op in de bovenstaande code, het eerste argument dat we doorgeven add_action is de naam van onze aangepaste haak. De tweede is een methode die een bericht op de beheerpagina zal weergeven. We hebben het nog niet geschreven (dus als u probeert deze code uit te voeren, krijgt u een foutmelding).

Maar laten we dat veranderen.

3. Een aangepast bericht weergeven

Maak eerst een functie in de Settings_Messenger klas genoemd display_message, en laten we gewoon een verklaring herhalen van een verklaring om te zien of deze wordt weergegeven in de aangepaste pagina die we hebben gemaakt:

En als u de code uitvoert, ziet u zoiets als dit. Kijk goed onder de h1 tag en je zou de zin moeten zien die we hierboven hebben opgenomen.

Dit is echter het probleem: het bericht dat we weergeven komt niet overeen met de markup die WordPress gebruikt om succesboodschappen, waarschuwingen of fouten weer te geven. 

We zullen dit later in de serie in detail bespreken, maar laten we doorgaan en een succesbericht weergeven. We zijn tenslotte zo ver gekomen, toch? We tonen ons eigen bericht via een aangepaste haak met behulp van een door ons gemaakte Messenger-klasse.

Er zijn een aantal manieren waarop we dit kunnen doen: We kunnen een sjabloonbestand gebruiken, we kunnen markup gebruiken in de functie en het daar zuiveren, of we kunnen het bestand opnemen in de functie. Voor deze tutorial ga ik de markup maken in de functie en gebruiken wp_kses om de code te ontsmetten.

Dit is normaal niet hoe ik zou aanraden dit te doen, maar het is een manier waarop het kan worden bereikt, en het stelt ons ook bloot aan wp_kses, wat een functie is die we allemaal zouden moeten gebruiken bij het weergeven van informatie aan de browser.

Gebruik deze code:

 

U hebt met succes een aangepast succesbericht weergegeven.

"; $ allowed_html = array ('div' => array ('class' => array (),), 'p' => array (),); echo wp_kses ($ html, $ allowed_html);

En dit zou moeten resulteren in de volgende screenshot:

Merk hier op dat het bericht blijft bestaan. Er is geen knop Opslaan, er is geen manier om dit bericht te verbergen en er is geen manier om dit bericht buiten de code te veranderen. Maar dat is goed, want dat is niet het punt van deze oefening.

Een paar dingen die ik wil vermelden, echter:

  • De klassekenmerken op het div-element die u ziet, zijn rechtstreeks van WordPress geleend. Dit is zodat we die stijlen kunnen erven.
  • Sommige berichten kunnen worden verworpen. We behandelen dit in een toekomstige zelfstudie.
  • De $ allowed_html array doorgegeven aan wp_kses is wat ervoor zorgt dat niets andere dan de opgegeven elementen en attributen worden gerenderd. Het is een erg goede, krachtige en schone manier om gegevens te ontsmetten.

En dat is alles wat er te zien is in deze specifieke tutorial; we zijn echter net begonnen.

Conclusie

Terwijl we door deze reeks heengaan, gaan we kijken hoe we succesboodschappen, foutmeldingen en waarschuwingsberichten kunnen verwerken en hoe we de mogelijkheid kunnen introduceren om berichten te negeren.

Bovendien kunnen we zien hoe de invoer van de gebruiker kan worden gebruikt om het type bericht dat wordt weergegeven te regelen. 

Merk op dat ik ook altijd blij ben om vragen te beantwoorden via de reacties, en je kunt ook mijn blog bekijken en mij volgen op Twitter. Ik praat meestal ook over softwareontwikkeling binnen WordPress en tangentiële onderwerpen.

Tot de volgende zelfstudie downloadt u de bestanden, bestudeert u de code en ziet u hoe deze wordt uitgevoerd op uw lokale computer. In het volgende deel gaan we precies verder waar we gebleven waren.

Middelen

  • Aangepaste beheerpagina's maken met WordPress
  • Aan de slag met WordPress
  • MAMP
  • Een aangepast WordPress-berichtensysteem maken, deel 1
  • add_action
  • do_action
  • wp_kses