Persisted WordPress Admin-kennisgevingen deel 1

WordPress-beheerdersmeldingen bieden een handige manier om berichten weer te geven voor gebruikers in het beheerdersgebied, bijvoorbeeld nadat een bericht is bijgewerkt of een plug-in is geactiveerd. Ze worden ook gebruikt door vele thema's en plug-ins om meldingen over alles weer te geven, van nieuwe functies of beveiligingswaarschuwingen tot details over lopende promoties of upgradeaanwijzingen.

WordPress core biedt vier verschillende beheerdersmeldingen die contextueel kunnen worden gebruikt om een ​​gebruiker te waarschuwen voor een specifiek type kennisgeving. Dit wordt bereikt door een unieke accentkleur weer te geven voor elk type beheerderskennisgeving.

Beheerdersmeldingen worden meestal bovenaan elke beheerderspagina weergegeven om op te vallen tussen de inhoud van de hoofdpagina en zijn duidelijk merkbaar. Ze zijn elegant ontworpen om niet te visueel te worden afgeleid.

WordPress hergebruikt ook admin-berichten op andere locaties in de beheerdersinterface, bijvoorbeeld wanneer een update voor een thema of plug-in beschikbaar is. Het kerngebruik van beheerdersboodschappen is niet beperkt tot alleen maar worden weergegeven bovenaan het beheerdersscherm.

Het weergeven van een beheerderskennisgeving in een aangepaste plug-in of thema is relatief eenvoudig en vereist slechts een paar regels code, zoals we binnenkort zullen ontdekken. WordPress biedt echter niet standaard een manier om een ​​aanhoudende beheerderskennisgeving te negeren.

Ook al kunt u een knop Verwijderen toevoegen aan een beheerdersverklaring, dit belet niet dat deze opnieuw verschijnt wanneer de pagina opnieuw wordt geladen. Bovendien verschijnen admin-mededelingen op elke beheerderspagina, wat verre van ideaal is.

Als u precies wilt weten wanneer en wanneer beheerdersmeldingen worden weergegeven en u ze effectief kunt verwijderen, moet u aangepaste code toevoegen om het standaardgedrag aan te passen.

Wat we zullen behandelen

We beginnen bij het begin en verkennen de basis van het implementeren van beheerdersmeldingen via een aangepaste plug-in, inclusief weergave ervan op specifieke pagina's in de WordPress-beheerder.

Beheerdersmeldingen verschijnen standaard op elke pagina, wat niet altijd is wat u wilt. U wilt bijvoorbeeld mogelijk alleen een melding weergeven op een pagina met plug-inopties. Dus onze volgende aanloophaven is om voorwaardelijk beheerdersbevoegdheden te tonen, afhankelijk van het huidige beheerdersscherm.

Hierop voortbouwend, introduceren we manieren om admin-meldingen verder te beheren door te beheren wanneer ze verschijnen ook. In plaats van te verschijnen zodra de pagina wordt geladen, verschijnen ze alleen als aan bepaalde triggervoorwaarden is voldaan. Dit kan bijvoorbeeld handig zijn als u een beheerderskennisgeving wilt weergeven op een pagina met pluginopties, maar enkel en alleen nadat instellingen waren opgeslagen.

Zoals hierboven vermeld, is er geen eenvoudige manier om blijvende beheerdersmeldingen tussen paginaladingen te negeren. Dus de rest van de tutorialserie zal zich vooral richten op verschillende methoden die u kunt gebruiken om beheerdersmeldingen te verwijderen, zodat ze niet onverwacht opnieuw verschijnen.

Tot slot, voor een beetje plezier, zullen we zien hoe u uw eigen aangepaste typen beheermeldingen kunt maken en extra decoratie zoals pictogrammen kunt toevoegen aan uw beheerdersmededelingen.

Aan het einde van deze zelfstudiereeks kunt u elk type beheerdersbericht overal in de WordPress-beheerder weergeven. Bovendien kunt u beslissen of u ze wilt weergeven bij het laden van een pagina of via een aangepaste actie. U kunt ze ook op verschillende manieren verwijderen, afhankelijk van uw behoeften.

Wilt u volgen?

U haalt het meeste uit deze zelfstudiereeks als u doorgaat terwijl we elk voorbeeld van een beheerderskennis uitwerken. De code wordt stapsgewijs gepresenteerd zodat u zelf een werkende plug-in kunt bouwen terwijl we door de zelfstudie gaan. Als u echter niet alle code zelf wilt invoeren, kunt u de voltooide plug-in downloaden in deel vier.

Er wordt van uitgegaan dat je op zijn minst een basiskennis hebt van de ontwikkeling van WordPress-plug-ins, inclusief hoe hooks werken. Als dat niet het geval is, raad ik u aan deze onderwerpen te lezen via de officiële WordPress-documentatie voordat u doorgaat:

• Inleiding tot ontwikkeling van plug-ins
• Een plug-in schrijven
• WordPress Hooks

Om de plugin-code voor elk voorbeeld te testen, hebt u een werkende WordPress-site nodig. De eenvoudigste manier om dit te doen is om WordPress lokaal te installeren, zodat je gemakkelijk toegang hebt om bestanden te bewerken. 

Er zijn veel keuzes om lokaal met WordPress te ontwikkelen, waaronder:

• Lokaal door Vliegwiel
• DesktopServer
• MAMP (en MAMP PRO)
• Zwerver

Als WordPress nieuw voor u is, is Local of DesktopServer waarschijnlijk het gemakkelijkst in te stellen. Lokaal is gratis te gebruiken (ze hebben een premium-versie in de fabriek), en DesktopServer heeft een beperkte (gratis) versie plus een premium-versie beschikbaar.

Ook wordt enige eerdere ervaring met PHP en JavaScript aanbevolen, evenals enige ervaring met het implementeren van Ajax-verzoeken. Alles zal echter onderweg worden uitgelegd, dus een grondige kennis is niet vereist.

Een nadere blik op beheerdersmeldingen

Laten we eens kijken naar de meest elementaire implementatie van een beheerderskennisgeving en de code die nodig is om een ​​melding van het succestype te maken.

function display_admin_notice () ?> 
Het geheim van succes is om iets te weten dat niemand anders kent ~ Aristotle Onassis
 
Het enige wat we hier deden was het registreren van het display_admin_notice () functie die wordt uitgevoerd wanneer de admin_notices haak branden. Het maakt niet uit wat de geregistreerde functie wordt genoemd, het heeft geen invloed op hoe de melding van de beheerder wordt weergegeven.
Maak je geen zorgen over het invoeren van de code hierboven jezelf nu; richt u gewoon op de manier waarop de kennisgeving van de beheerder wordt gegenereerd, daar zullen we in latere handleidingen aan bouwen.
U kunt elke gewenste markup gebruiken om een ​​beheerderskennisgeving weer te geven; het aanbevolen formaat is echter als volgt:
bericht
Vervangen klasse met een lijst met CSS-klassenamen. Je moet de klas opnemen merk op plus een van de volgende klassen om het type beheerderskennisgeving te bepalen:
 
 kennisgeving-error (rood)
 
 kennisgeving-waarschuwing (geel oranje)
 
 kennisgeving-succes (groen)
 
 kennisgeving-info (blauw)
 
De bericht blok kan elke tekst of geldige HTML zijn die in de admin-melding wordt weergegeven.
Het bovenstaande voorbeeld toont beheerdersberichten op alle beheerderspagina's, wat niet altijd ideaal is, dus in deel twee zullen we bekijken hoe u precies kunt bepalen op welke pagina's ze voorkomen.
Er is nog een ingebouwde CSS-klasse die u kunt toevoegen div.notice die een knop Verwijderen toevoegt aan de beheerderskennisgeving. Laten we eens kijken wat er gebeurt als dezelfde melding van succesbeheerder de is-afgezet kunnen klas toegevoegd.
function display_admin_notice () ?> 
Het geheim van succes is om iets te weten dat niemand anders kent ~ Aristotle Onassis
 
We hebben nu een eenvoudige manier om een ​​beheerderskennisgeving te negeren. Voordat u echter te opgewonden raakt, is er een probleem met het gebruik van deze methode. Als u de pagina vernieuwt, wordt de beheerdersmelding opnieuw weergegeven! U kunt dus instellen dat een beheerdersboodschap moet worden gesloten, maar dat deze persistent is en dat de vergrendelde status tussen het laden van de pagina is vergeten.
Later behandelen we persistente beheerdersmeldingen en onderzoeken we verschillende manieren waarop u ze kunt negeren zonder dat ze worden weergegeven.
Maar beheerdersmeldingen zijn slecht! Zijn zij niet?
Als u helemaal bekend bent met beheerdersberichten in WordPress en / of WordPress-nieuws in het algemeen bijhoudt, is het mogelijk dat u zich bewust bent van een zekere mate van negativiteit ten aanzien van het gebruik van beheerdersmeldingen in aangepaste plug-ins en thema's..
Dit komt voort uit enkele plug-ins waarin admin-meldingen worden gebruikt om hun 'belangrijke' berichten over te brengen. Als je veel plug-ins hebt geïnstalleerd en slechts een paar van hen misbruik maken van het beheerdersmeldsysteem, kun je snel eindigen met de melding 'soep' van de beheerder, waarbij een hele wirwar aan berichten boven aan elke beheerderspagina wordt weergegeven..
Het overbelasten van beheerdersschermen met onnodige meldingen kan chaos (en hoofdpijn) veroorzaken en is begrijpelijkerwijs irritant voor gebruikers omdat het het beheren van een site bemoeilijkt.
In het ideale geval moeten alleen belangrijke beheerdersmeldingen, zoals kritieke beveiligingsupdates, worden weergegeven bij het laden van elke pagina. Als u algemene beheerdersmeldingen weergeeft om gebruikers te laten weten dat een plug-in zojuist is bijgewerkt en u wordt gevraagd op een link te klikken voor meer informatie, moet u zich echt afvragen of dit op elke beheerderspagina moet staan.
Een typische favoriet is om een ​​niet-kritieke beheerderskennisgeving weer te geven die niet gemakkelijk permanent kan worden verwijderd. Ik garandeer je dat er geen gemakkelijkere manier is om je plug-in gebruikers te vervreemden dan door dit te doen!
Er zijn echter gebruiksmogelijkheden voor permanente meldingen die niet kunnen worden verwijderd, zoals database-updates. Plug-ins die aangepaste tabellen gebruiken, moeten zo nu en dan een update-routine uitvoeren om ervoor te zorgen dat de plug-in correct blijft werken. In dit geval is het dus redelijk om een ​​niet-afwijsbaar beheerdersbericht toe te voegen.
Een goede vuistregel is om gewoon gezond verstand te gebruiken. Zou de beheerder merken dat je iets aan je plug-in toevoegt, irriteer je als gebruiker? Als dit het geval is, kunt u overwegen de opmerking toe te voegen of overwegen of deze beter op een andere locatie wordt weergegeven.
Conclusie
In deze zelfstudie hebben we behandeld wat de beheerdersmededelingen zijn en de verschillende ingebouwde typen die door WordPress worden geboden, inclusief een af ​​te zetten beheerderskennisgeving. Zoals we hebben gezien, zijn er enkele nadelen aan de standaardimplementatie van beheerdersmeldingen, zoals niet-afsluitbaar zijn en het feit dat ze op elke beheerderspagina worden weergegeven..
WordPress heeft een ongelooflijk actieve economie. Er zijn thema's, plug-ins, bibliotheken en vele andere producten die u helpen uw site en project uit te bouwen. De open-source aard van het platform maakt het ook een geweldige optie van waaruit je je programmeervaardigheden kunt verbeteren. Hoe het ook zij, u kunt zien wat wij beschikbaar hebben Envato Market.
De rest van de handleidingen in deze serie zullen zich concentreren op hoe we beheerdersmeldingen kunnen uitbreiden om meer praktisch te zijn wanneer ze worden gebruikt in uw eigen plug-ins en thema's.



		
			
	   
	




Code