In deel een van deze serie leerden we hoe we een eenvoudige beheerderskennisgeving konden implementeren die bovenaan elke WordPress-beheerderspagina verschijnt. In deze zelfstudie gaan we een plug-in uitbouwen voor al onze aangepaste beheerderscodes.

We beginnen met het implementeren van standaard admin-kennisgevingen en gebruiken deze als basis voor meer flexibele en geavanceerde voorbeelden.

Onze plug-in instellen

Laten we echter eerst een nieuwe plug-in instellen die we voor al onze beheerdersmeldingen zullen gebruiken, zodat we klaar zijn om code in te voeren.

Ik neem hier aan dat je al een lokale WP-ontwikkelsite hebt opgezet. Als dat niet zo is, raadpleeg dan de links in deel een van deze tutorialserie.

Maak een nieuwe map met plug-ins genaamd admin_notices binnen / Wp-content / plugins /, en maak vervolgens een admin_notices.php bestand dat het belangrijkste plugin-bestand zal zijn.

Doe open admin_notices.php in je favoriete editor en voeg de basis plugin-structuur toe:

in het();

We hebben een eenvoudige plugin-header toegevoegd, zodat WordPress onze plug-in herkent. Dit wordt gevolgd door een klasse die methoden bevat om onze admin-kennisgevingen weer te geven.

Ik heb de klas genoemd Gwyer_Admin_Notices om het zo uniek mogelijk te maken. Op deze manier is het veel minder waarschijnlijk dat het conflicteert met een bestaande klassennaam.

Laten we beginnen met het weergeven van een standaard beheerderskennisgeving en deze vervolgens toevoegen om het nuttiger te maken. Om een ​​beheerderskennisgeving aan te maken, voegt u de admin_notices hook to the in het() functie:

add_action ('admin_notices', array ($ this, 'test_notice'));

De haak bevat een test_notice callback-functie die zal worden gebruikt voor het uitvoeren van de markeringsmarkering voor beheerders.

Voeg de volgende klassemethode toe aan Gwyer_Admin_Notices om de daadwerkelijke beheerderskennisgeving weer te geven. Voor de berichten gebruiken we klassieke filmoffertes van de afgelopen 100 jaar films.

/ ** * Een testbeheerdersmelding uitvoeren. * / public function test_notice () ?> 
Yoo hoo, big summer blow out.
 
Activeer de plug-in om de testmelding te tonen.
Laten we ook voorbeelden toevoegen van de andere soorten beheerdersmeldingen die we kunnen weergeven, inclusief het afroepbare type door het toevoegen van de is-afgezet kunnen CSS-klasse. Voeg deze toe aan de test_notice () methode onder de bestaande beheerderskennisgeving div:
Toto, ik heb het gevoel dat we niet meer in Kansas zijn.
 
Je had me bij hallo".
 
Van alle gin-gewrichten in alle steden in de wereld, loopt ze de mijne in.
 
Niemand zet een baby in de hoek.
Dit is het volledige scala aan typen meldingen voor beheerders die we kunnen weergeven via de WordPress core CSS-klassen. Houd er echter rekening mee dat het bericht dat de pagina kan worden verwijderd, bij elke pagina opnieuw verschijnt!
'Ontoelaatbare' admin-melding betekent in deze context alleen voor de huidige pagina. Het is niet erg flexibel om persistente beheerdersmeldingen te hebben, dus later zullen we specifiek kijken naar verschillende manieren waarop u uw admin-meldingen effectief kunt negeren.
Admin Notice Hooks
Tot nu toe hebben we alleen het admin_notice haak om een ​​beheerderskennisgeving te implementeren. Er zijn in feite vier afzonderlijke admin notice hooks die je kunt gebruiken om meldingen weer te geven, maar admin_notice wordt het meest gebruikt.
De vier beschikbare haken zijn:
 
 admin_notices (gebruikt in de meeste omstandigheden)
 
network_admin_notices
 
all_admin_notices* 
 
user_admin_notices* 
 
*Geen officiële documentatie beschikbaar voor deze hooks.
Dus waar zou je normaal gesproken gebruik van maken all_admin_notices, user_admin_notices, en network_admin_notices? En hoe verschillen ze van admin_notices?
Ik zei eerder dat het admin_notices haak displays meldingen op alle admin-pagina's, maar dit is niet helemaal waar. Als je ernaar kijkt admin-header.php in WordPress core, zul je dat zien admin_notices, network_admin_notices, en user_admin_notices zijn wederzijds exclusief. Dat wil zeggen, alleen een van deze hooks vuurt op een WordPress admin-pagina.
Een reeks voorwaardelijke expressies evalueert de huidige beheerderspagina en vuurt slechts één ervan af, afhankelijk van het type beheerderspagina dat u momenteel gebruikt.
ten eerste, is_network_admin () controleert of u zich op een netwerkbeheerdersscherm bevindt (bijvoorbeeld elke beheerderspagina op basis van a / Wp-admin / netwerk / URL). Als dat zo is, de network_admin_notices haak branden.
Anders, is_user_admin () controleert of u zich op een gebruikersbeheerdersscherm bevindt (bijvoorbeeld elke beheerderspagina op basis van a / Wp-admin / user / URL). Als dat zo is, de user_admin_notices haak branden. 
En, zoals je misschien al geraden had, als beide is_network_admin () en is_user_admin () return false dan de admin_notices haak branden.
Dat verlaat net het all_admin_notices haak. Deze haak maakt geen deel uit van de voorwaardelijke uitdrukking die hierboven is besproken, dus deze haak wordt gegarandeerd weergegeven allemaal admin-pagina's maakt niet uit wat, inclusief multisite-netwerkbeheerderspagina's.
Ter verduidelijking, voor elke WordPress-beheerderspagina, alleen de all_admin_notices haak is gegarandeerd om altijd te vuren. Alleen van de andere drie haken een wordt geactiveerd afhankelijk van de beheerderspagina waar je momenteel bent.
Ik zou je willen aanmoedigen om ernaar te kijken admin-header.php (aan het einde van het bestand) om zelf te zien hoe WordPress evalueert wanneer elke admin-melding wordt gebruikt.
We zullen alleen gebruiken admin_notices door deze serie zelfstudies, maar je zult misschien merken dat je een aantal van de andere haken in je eigen project nodig hebt, dus het is de moeite waard om ze te bekijken.
Beheerkennisgevingen op specifieke pagina's weergeven
Laten we nu onze aandacht richten op het weergeven van beheerdersmeldingen op specifieke pagina's. Geef eerst de oproep aan add_action dus onze testmeldingen worden niet meer getoond.
Binnen in het(), voeg een nieuw toe add_action () oproep die we zullen gebruiken om een ​​beheerderskennisgeving op één specifieke beheerderspagina weer te geven.
add_action ('admin_notices', array ($ this, 'specific_admin_page'));
Definieer vervolgens de specific_admin_page () methode als volgt:
/ ** * Geef een beheerderskennisgeving op een specifiek beheerdersscherm. * / public function specific_admin_page () $ admin_page = get_current_screen (); ?> 
Informatie: we zijn momenteel op de baseren; ?> admin pagina.
 
Sla uw wijzigingen op en bekijk elke pagina in de WordPress-beheerder. Ik zal de hoofdpagina van het dashboard proberen.
Zoals u ziet, wordt voor elke beheerderspagina die u bezoekt, de (basis) naam van de pagina weergegeven in de beheerderskennisgeving.
De get_current_screen () functie retourneert a WP_Screen object met details over het huidige beheerdersscherm. De specifieke objecteigenschap waarin we geïnteresseerd zijn, is WP_Screen-> base, die evalueert naar het basistype van het huidige scherm. Probeer verschillende WordPress-beheerderspagina's te laden om te zien voor welke waarden wordt geretourneerd WP_Screen-> base.
We kunnen de basiswaarde gebruiken om onze admin-melding voorwaardelijk alleen op de dashboardpagina te laden. De waarde die we moeten controleren is dashboard. Laten we ook een alternatieve beheerderskennisgeving weergeven als we niet op de dashboardpagina voor beheerders staan. Vervang uw definitie van specific_admin_page () met:
/ ** * Geef een beheerderskennisgeving op een specifiek beheerdersscherm. * / public function specific_admin_page () $ admin_page = get_current_screen (); if ($ admin_page-> base == "dashboard"):?> 
We maakten het! Welkom bij het dashboard.
  
Waar ben je naartoe gegaan? Dit is niet het dashboard!
 
Alles is in orde als we op de dashboardpagina staan, maar probeer te navigeren naar een andere beheerderspagina om te zien wat er gebeurt.
Het gebruik van deze eenvoudige aanpak geeft ons nogal wat flexibiliteit bij het weergeven van beheerdersmeldingen op specifieke beheerderspagina's. We kunnen dit eenvoudig uitbreiden naar een willekeurig aantal beheerderspagina's waarop we kennisgevingen van beheerders willen weergeven.
Vervang opnieuw de specific_admin_pages () functie, deze keer met de volgende code:
/ ** * Geef een beheerderskennisgeving op een specifiek beheerdersscherm. * / public function specific_admin_page () $ whitelist_admin_pages = array ('dashboard', 'upload', 'edit-comments'); $ admin_page = get_current_screen (); if (in_array ($ admin_page-> base, $ whitelist_admin_pages)):?> 
We maakten het! Dit is de 'baseren; ?> 'beheerderspagina.
  
Niet op jouw nelly! Deze pagina staat niet op mijn lijst.
 
In plaats van te controleren op een enkele beheerderspagina, controleren we nu om te zien of de basisnaam voor de huidige beheerderspagina zich in de $ whitelist_admin_pages matrix. Wanneer we naar de dashboard-, mediabibliotheek- of pagina met reactiebeheerpagina's gaan, zien we onze melding van de succesbeheerder.
En wanneer we bezoeken ieder andere beheerderspagina (niet opgenomen in onze whitelist-array), zien we een alternatieve beheerderskennisgeving.
Hoe zit het met het weergeven van een beheerderskennisgeving op een pagina met plug-inopties? Hoe zouden we dat aanpakken? Voordat we hier ingaan, moeten we eerst een dummy-optiespagina instellen voor onze plug-in.
Maak een nieuw bestand met de naam plugin-options.php binnen in de admin-kennisgevingen plug-in map die we eerder hebben toegevoegd en voeg de volgende code toe:
 
 
Admin Notices Plugin
 
   
 
 
Voer wat tekst in
 
 
 
  
 
 in het(); 
Bovenop admin-notices.php (direct boven de klassendeclaratie), neemt u de klasse plugin-opties op in het hoofdinvoegbestand met:
require_once (dirname (__ FILE__). '/plugin-options.php');
Ik ga niet in te veel details over hoe de code erin zit plugin-options.php werkt als dat kan een hele tutorial op zichzelf zijn! Als je een opfriscursus wilt, raad ik je aan de WordPress Codex-pagina te bekijken op pagina's met invoegtoepassingen toevoegen.
Kortom, alles wat we doen is een nieuw toevoegen Beheerdersmeldingen subpagina van de instellingen menu. De pagina met pluginopties zelf bevat één tekstveld waarin u een tekenreeks kunt invoeren. Wanneer de Wijzigingen opslaan knop wordt geklikt, wordt de inhoud van het tekstveld opgeslagen in de WordPress-database.
Dit is slechts een kaal voorbeeld van een plugin-instellingenpagina alleen voor demonstratie. Het bevat niet de noodzakelijke sanerings- of vertaalfuncties die worden aanbevolen voor een productie-plug-in die bedoeld is voor algemene vrijgave.
Ga naar Instellingen> Beheerdersmeldingen om de pagina met plug-inopties te bekijken.
Zoals verwacht, wordt de beheerdersmelding die we eerder hebben toegevoegd weergegeven op onze pagina met plug-inopties. Het foutbericht wordt weergegeven omdat onze pagina met plug-inopties niet in de $ whitelist_admin_pages array van toegestane beheerderspagina's. Laten we dat nu oplossen.
Om onze opties-pagina aan de array toe te voegen, moeten we de naam van de base weten. Binnen specific_admin_page (), verander de fout administratiemelding div naar het volgende:
Niet op jouw nelly! Deze 'baseren; ?> 'pagina staat niet op mijn lijst.
We krijgen nog steeds dezelfde foutmelding van de beheerder als voorheen, maar deze keer bevat deze de basisnaam die we nodig hebben, wat blijkt te zijn settings_page_admin-notices / plugin-opties. Dat is geen naam die we gemakkelijk hadden kunnen raden, dus het was de moeite waard de tijd te nemen om het uit te voeren!
Voeg de basisnaam toe aan de $ whitelist_admin_pages array, die er nu als volgt uitziet:
$ whitelist_admin_pages = array ('settings_page_admin-notices / plugin-options', 'dashboard', 'upload', 'edit-comments');
Vernieuw de pagina met plug-inopties om de bijgewerkte beheerderskennisgeving te bekijken.
Nu we de basisnaam van de plugin-opties kennen, kunnen we eenvoudig een beheerderskennisgeving maken die alleen op die beheerderspagina wordt weergegeven. Verwijderen settings_page_admin-notices / plugin-opties van de $ whitelist_admin_pages matrix en commentaar uit de tweede add_action functieaanroep in het(). Voeg vervolgens een derde actie toe die we zullen gebruiken voor onze plugin-opties, alleen beheerderskennisgeving. Jouw in het() functie zou er nu als volgt uit moeten zien:
/ ** * Haken registreren. * / public function init () // add_action ('admin_notices', array ($ this, 'test_notice')); // add_action ('admin_notices', array ($ this, 'specific_admin_page')); add_action ('admin_notices', array ($ this, 'plugin_admin_notice'));  
Laten we het invullen plugin_admin_notice () callback-functie nu. Voeg deze nieuwe methode toe aan de Gwyer_Admin_Notices klasse:
/ ** * Geef een beheerderskennisgeving op de pagina met plug-inopties. * / public function plugin_admin_notice () $ whitelist_admin_pages = array ('settings_page_admin-notices / plugin-options'); $ admin_page = get_current_screen (); if (in_array ($ admin_page-> base, $ whitelist_admin_pages)):?> 
Welkom bij de plugin-pagina Beheerdersmeldingen!
 
Dit lijkt erg op specific_admin_page () behalve dat we de voorwaardelijke uitdrukking hebben verwijderd. We hebben ook een verwijderbare knop toegevoegd door de is-afgezet kunnen CSS-klasse, zodat de melding van de beheerder nu ook kan worden gesloten.

Probeer andere beheerderspagina's te laden om te bevestigen dat het beheerdersbericht alleen wordt weergegeven op de pagina met plug-inopties.
Conclusie
In deze zelfstudie hebben we meer informatie ontvangen over kennisgevingen van beheerders en de verschillende hooks die beschikbaar zijn om ze weer te geven. We hebben ook behandeld hoe u admin-meldingen alleen op specifieke pagina's van de WordPress-beheerder kunt weergeven. We hebben een speciale plug-in ontwikkeld om alle berichtencodes voor aangepaste beheerders te bevatten.
In deel drie breiden we de plug-in verder uit door te laten zien hoe beheerdersmeldingen kunnen worden geactiveerd wanneer bepaalde gebeurtenissen plaatsvinden. Vergeet niet dat het open-source karakter van WordPress het gemakkelijk maakt om te leren en uit te breiden. Daarom moeten we in Envato Market veel bekijken en bestuderen als je nieuwsgierig bent.
We gaan vervolgens onze aandacht richten op het oplossen van het probleem met de blijvende melding van beheerders, zodat ze niet opnieuw verschijnen wanneer de pagina wordt vernieuwd. We zullen verschillende methoden implementeren in onze aangepaste plug-in om ons dit te laten doen.



		
			
	   
	




Code