Share
Welkom bij onze serie over aanhoudende WordPress-beheerdersmeldingen. We zijn nu in een goede positie om onze functionaliteit voor beheerdersmeldingen en controle te kunnen uitbreiden wanneer ze verschijnen op de pagina.
Hierna gaan we verder met persistente beheerdersmeldingen en zien we hoe u ervoor kunt zorgen dat ze worden verwijderd op een manier dat ze niet opnieuw verschijnen wanneer beheerderspagina's opnieuw worden geladen.
Dit is vooral belangrijk omdat aangepaste beheerdersmeldingen geïmplementeerd in plug-ins en thema's alleen echt handig zijn als u ze permanent kunt negeren. Het is niet genoeg om gewoon het is-afgezet kunnen CSS-klasse.
Tot nu toe werden alle beheerdersmeldingen getoond zodra de pagina werd geladen. Er kunnen momenten zijn dat dit onhandig is en u wilt dat het beheerdersbericht wordt weergegeven na een bepaalde gebeurtenis is geactiveerd.
Wat dacht je van als we wilden dat een aangepast beheerdersbericht op de pagina met plug-inopties wordt weergegeven die we eerder hebben gemaakt, maar enkel en alleen na de Wijzigingen opslaan knop is geklikt?
We weten al van deel twee hoe je een beheerderskennisgeving kunt beperken tot de pagina met plug-inopties. Laten we kijken hoe we het kunnen activeren nadat de plugin-opties zijn opgeslagen.
Begin met het commentariëren van de add_action functie oproep voor plugin_admin_notice. Voeg vervolgens een vierde toe add_action inbellen in het als volgt:
Accentsconagua
add_action ('admin_notices', array ($ this, 'conditional_plugin_admin_notice'));Wanneer plug-inopties worden opgeslagen, Instellingen-update waarde van waar is toegevoegd aan de super global $ _GET matrixvariabele. We kunnen dit gebruiken om te bepalen of we onze beheerderskennisgeving moeten weergeven.
Voeg een nieuwe toe conditional_plugin_admin_notice methode om Gwyer_Admin_Notices die de waarde van uitvoert $ _GET naar het scherm.
/ ** * Geef een beheerderskennisgeving op de pagina met opties voor invoegtoepassingen weer wanneer instellingen zijn opgeslagen. * / public function conditional_plugin_admin_notice () echo ""; print_r ($ _ GET); echo"";
Wanneer de pagina met plugin-opties normaal is geladen, zien we geen ingestelde waarde voor instellingen-bijgewerkt.
Voer nu wat tekst in de Voer wat tekst in veld en klik Wijzigingen opslaan. Deze keer zien we het Instellingen-update ingesteld op waar, die we goed kunnen gebruiken.
Vervang de conditional_plugin_admin_notice met:
/ ** * Geef een beheerderskennisgeving op de pagina met opties voor invoegtoepassingen weer wanneer instellingen zijn opgeslagen. * / public function conditional_plugin_admin_notice () $ whitelist_admin_pages = array ('settings_page_admin-notices / plugin-options'); $ admin_page = get_current_screen (); $ current_user = wp_get_current_user (); if (in_array ($ admin_page-> base, $ whitelist_admin_pages) && isset ($ _GET ['settings-updated']) && $ _GET ['settings-updated']):?> Plugin-opties zojuist opgeslagen. Weergavenaam; ?>, je bent gewoon zo geweldig!
Inmiddels zou deze code u bekend moeten voorkomen. Een aantal nieuwe functies zijn echter toegevoegd. Ten eerste is de voorwaardelijke uitdrukking uitgebreid om te testen op de aanwezigheid van instellingen update. Het beheerdersbericht wordt nu alleen weergegeven als we op de pagina met plug-inopties staan en als Instellingen-update ingesteld op waar.
Ook wordt de huidige weergavenaam van de gebruiker uitgevoerd om de beheerder iets persoonlijker te maken.
De wp_get_current_user () functie retourneert informatie over de huidig aangemelde gebruiker. Dit object is opgeslagen in $ current_user en bevat details zoals gebruikers-e-mail, ID, voornaam, achternaam en weergavenaam, de specifieke eigenschap waarin we geïnteresseerd zijn.
Eindelijk, voor een beetje extra Pools, hebben we voorkomen dat de standaard beheerdersboodschap wordt weergegeven, dus onze aangepaste is de enige die zichtbaar is voor de gebruiker. Om dit te bereiken, hebben we zojuist een enkele regel code toegevoegd aan conditional_plugin_admin_notice () om CSS uit te voeren om de ongewenste beheerderskennisgeving te verbergen.
echo "";
Het eindresultaat wanneer plugin-opties worden opgeslagen, wordt hieronder weergegeven.
Hoewel dit prima werkt voor demonstratiedoeleinden, is het een betere (en schonere) methode om stijlen aan een afzonderlijke stylesheet toe te voegen en deze alleen in te stellen op de pagina met plug-inopties..
Onze aangepaste beheerderskennisgeving kan op een aantal manieren nog verder worden uitgebreid. Een mogelijkheid zou kunnen zijn om een logboek bij te houden dat de huidige datum / tijd samen met gebruikersinformatie opslaat telkens wanneer de plug-inopties werden opgeslagen.
Of hoe zit het met het krijgen van de admin-melding om weer te geven hoe vaak de plugin-opties zijn opgeslagen die dag, week, maand, enz.? Ik weet zeker dat je ook meer voorbeelden kunt bedenken!
Persisted Admin-meldingen effectief stopzetten
Het is tijd om onze handen nu vies te maken en meer diepgaande code in te voeren, terwijl we onze aandacht richten op het afwijzen van aanhoudende kennisgevingen van beheerders. Tot nu toe is de enige manier om dit te doen het toevoegen van de .is-afgezet kunnen CSS-klasse naar onze admin-melding div-container. Hiermee wordt de beheerderskennisgeving voor de huidige pagina verworpen, maar in de praktijk wordt deze niet veel gebruikt, omdat deze opnieuw wordt weergegeven wanneer een beheerderspagina opnieuw wordt geladen.
Dus hoe kunnen we dit oplossen? We zullen verschillende methoden bekijken voor het afwijzen van aanhoudende kennisgevingen van beheerders, waaronder:
Voordat we beginnen met de implementatie van elk van deze voorbeelden, moet u ervoor zorgen dat alles werkt add_action () roept in Gwyer_Admin_Notices :: init () zijn becommentarieerd. Voeg vervolgens een nieuw toe weggeklikt-admin-notices.php bestand naar de admin_notices plug-in map. Open dit nieuwe bestand en voeg een nieuwe klassedefinitie toe:
in het();
In admin_notices.php, nog een toevoegen eenmalig benodigd() bel om onze nieuwe klas te importeren:
require_once (dirname (__ FILE__). '/dismissible-admin-notices.php');
De Gwyer_Dismissible_Admin_Notices klasse zal alle code bevatten die gerelateerd is aan het verwijderen van aanhoudende beheerdersmeldingen.
De eerste methode die we zullen bekijken, is hoe u een admin-melding slechts één keer weergeeft, zodat deze niet meer verschijnt bij het laden van de pagina. U kunt deze methode gebruiken om een gebruiker op de hoogte te stellen wanneer een plug-in of thema zojuist is geactiveerd.
Laten we dit doen voor onze Admin Notices plugin. We beginnen met het registreren van een tijdelijke Wordpress-optie bij activering van de plug-in die bijna onmiddellijk verloopt.
In de Gwyer_Dismissible_Admin_Notices class, voeg een oproep toe aan register_activation_hook ():
register_activation_hook (plugin_dir_path (__FILE__). 'admin-notices.php', array ($ this, 'set_admin_notice_transient'));
De register_activation_hook () functie vereist dat u het pad naar het hoofdinvoegbestand opgeeft, maar we zijn er momenteel weggeklikt-admin-notices.php. We kunnen dus niet alleen de PHP-magische constante gebruiken __HET DOSSIER__ we eerder hebben gebruikt omdat dit altijd verwijst naar het huidige PHP-bestand.
In plaats daarvan moeten we zelf het pad naar het hoofdplugin-bestand bouwen plugin_dir_path (__FILE__). 'Admin-notices.php'.
Wanneer de Admin Notices-plug-in is geactiveerd, wordt er code toegevoegd aan a set_admin_notice_transient klassemethode, die we hierna zullen definiëren.
public function set_admin_notice_transient () set_transient ('admin-notice-transient', true, 5); Met deze methode wordt een nieuwe tijdelijke naam opgeroepen 'Admin-bericht-van voorbijgaande aard' met een waarde van waar, en is ingesteld om na vijf seconden te vervallen.
Laten we gebruik maken van deze tijdelijke situatie door voorwaardelijk een beheerderskennisgeving weer te geven als we op de juiste beheerderspagina staan en onze overgang nog steeds bestaat.
Voeg een nieuwe toe add_action () bellen naar in het().
add_action ('admin_notices', array (& $ this, 'display_admin_notice'));Voeg vervolgens de display_admin_notice callback-functie als een nieuwe klassemethode:
openbare functie display_admin_notice () $ current_user = wp_get_current_user (); $ whitelist_admin_pages = array ('plug-ins'); $ admin_page = get_current_screen (); if (in_array ($ admin_page-> base, $ whitelist_admin_pages) && get_transient ('admin-notice-transient')):?> De Beheerdersmeldingen plugin was zojuist geactiveerd. Bedankt voor uw steun Weergavenaam; ?>!
Net als bij eerdere voorbeelden wordt de beheerderskennisgeving alleen weergegeven als we op een specifieke pagina staan, in dit geval de hoofdpagina voor beheerdersplug-ins. Maar we hebben een extra voorwaarde dat de 'Admin-bericht-van voorbijgaande aard' moet ook bestaan, anders wordt de melding van de beheerder niet weergegeven.
Nadat de beheerderskennisgeving is uitgevoerd, wordt de transiënt onmiddellijk verwijderd, ook al stellen we deze in eerste instantie na slechts vijf seconden af. Dit zorgt er alleen voor dat het niet opnieuw getoond wordt. Dit kan mogelijk gebeuren als een gebruiker de pagina met plug-ins erg snel heeft vernieuwd. Maar door opzettelijk de transient te verwijderen, kunnen we er zeker van zijn dat dit nooit het geval zal zijn.
Om de code te testen die we zojuist hebben toegevoegd, gaat u naar de pagina met de belangrijkste plug-ins en deactiveert u de plugin Admin Notices..
De sleutel hier is de 'Admin-bericht-van voorbijgaande aard' tijdelijke instelling. Zonder dit zou de admin-melding verschijnen elke keer dat de plug-ins-pagina werd geladen (nadat de plug-in was geactiveerd), wat niet is wat we willen.
Kennisgevingsteller voor beheerders
De volgende is een beheerderskennisgeving die slechts een bepaald aantal keren wordt weergegeven, waarna deze niet meer zichtbaar is. Ook deze keer zal het niet worden beperkt tot een bepaalde admin-pagina.
Voordat we beginnen, in de Gwyer_Dismissible_Admin_Notices klas, geef commentaar op de register_activation_hook () en add_action () functie-oproepen. Laten we nu een eenvoudige beheerderskennisgeving instellen waarin we binnenkort de functionaliteit uitbreiden.
Voeg een nieuwe toe add_action () inbellen in het():
add_action ('admin_notices', array (& $ this, 'display_admin_notice_counter'));En vult dan de callback-functie in display_admin_notice_counter ():
openbare functie display_admin_notice_counter () ?> Teller admin-melding.
Hierdoor wordt een standaard beheerdersbericht weergegeven dat op elke WordPress-beheerderspagina wordt weergegeven.
Laten we nadenken over wat we moeten doen. Onze admin-melding moet een vast aantal keren worden weergegeven en elke keer dat een interne teller wordt weergegeven, wordt deze met één verhoogd. Zodra de tellerlimiet is bereikt, zou de beheerderskennisgeving niet opnieuw moeten verschijnen.
We willen dat het beheerdersbericht wordt weergegeven op elke beheerderspagina en dus moet de tellerwaarde tussen het laden van pagina's blijven bestaan. Een goede manier om dit te doen is om een databaseoptie te gebruiken om de tellerwaarde op te slaan.
Voeg een tellerklasse-eigenschap toe om de tellergrenswaarde op te slaan:
public $ counter_limit = 5;
Dit wordt binnenkort gebruikt om te beheren hoe vaak het beheerdersbericht wordt weergegeven. Binnen display_admin_notice_counter (), update de code als volgt:
openbare functie display_admin_notice_counter () $ counter = get_option ('admin_notice_counter', 1); ?> Deze beheerderskennisgeving is weergegeven tijd (s).
Voordat de beheerdersmelding wordt weergegeven, halen we de tellermogelijkheid op en wordt een standaardwaarde geretourneerd als deze nog niet bestaat. Nadat de beheerdersmelding is gegenereerd, wordt de telleroptie met één verhoogd en bijgewerkt. Als het niet bestaat, wordt een nieuwe optie gemaakt om de huidige waarde op te slaan.
We hebben de CSS-klasse ook bijgewerkt als informatiemanager-melding.
Probeer verschillende beheerderspagina's te bezoeken en zie elke keer dat de teller toeneemt.
De ++$ teller code is een voorbeeld van een pre-increment-operator. Het voegt een waarde toe aan $ teller voor het wordt opgeslagen in de database. Als we een post-incrementele operator (d.w.z.. $ teller++) dan de waarde van $ teller zou eerst worden opgeslagen en dan verhoogd, wat niet zou werken.
Laten we het opnemen $ counter_limit nu om te voorkomen dat de admin-melding te vaak verschijnt. Voeg dit toe aan display_admin_notice_counter () onder de verklaring voor $ teller:
if ($ counter> $ this-> counter_limit) return;
Nu, nadat de beheerderskennisgeving vijf keer is weergegeven, is deze niet zichtbaar op volgende beheerderspagina's. Het zou echter leuk kunnen zijn om een bericht weer te geven wanneer de admin-melding voor het laatst verschijnt, zodat de gebruiker weet dat deze niet meer zal verschijnen. Verleng de voorwaardelijke uitdrukking en voer een extra bericht uit:
openbare functie display_admin_notice_counter () $ counter = get_option ('admin_notice_counter', 1); if ($ counter> $ this-> counter_limit) return; else if ($ counter == $ this-> counter_limit) $ extra_message = "Het is tijd om nu afscheid te nemen."; ?> Deze beheerderskennisgeving is weergegeven tijd (s).
Het bericht wordt echter niet weergegeven als u de tellerlimiet al hebt overschreden. Je kunt dit tijdelijk oplossen door de $ counter_limit veranderlijk.
Voor testdoeleinden is het beter om de tellerlimiet opnieuw in te stellen. Als u weet hoe u de database moet bewerken, kunt u naar binnen gaan en de optie direct wijzigen, maar dit kan vervelend zijn om meerdere keren te doen. Dus laten we onze eigen resetfunctie implementeren.
Ten eerste, verander $ counter_limit terug naar 5 en voeg een nieuwe klasse-eigenschap toe:
public $ counter_reset = false;
Dan, binnen in het() vervangen
add_action ('admin_notices', array (& $ this, 'display_admin_notice_counter'));met
$ This-> reset_counter_check ();
De reset-functie zou onze teller admin melding moeten tonen of de admin_notice_counter database-optie en geef in plaats hiervan een waarschuwing voor beheerdersadministratie weer.
openbare functie reset_counter_check () if (! $ this-> counter_reset) add_action ('admin_notices', array (& $ this, 'display_admin_notice_counter')); else delete_option ('admin_notice_counter'); ?> Admin-berichtenteller is gereset! Verandering $ counter_reset naar vals om de admin-kennisgevingsteller opnieuw te starten.
Om de nieuwe reset-functie te gebruiken, hoeft u alleen maar te veranderen $ counter_reset naar waar en laad een beheerderspagina.
Verander het daarna terug naar vals nog een keer.
Opmerking: deze methode kan eenvoudig worden gebruikt om een beheerderskennisgeving slechts eenmaal weer te geven, zoals we in het vorige voorbeeld hebben gedaan, maar het is iets gecompliceerder om in te stellen. Het hangt echt af van uw vereisten.
Als u alleen een beheerderskennisgeving voor één gebruik nodig hebt, zal de vorige methode waarschijnlijk beter aan uw behoeften voldoen en sneller worden geïmplementeerd. Maar de tellermethode is flexibeler en eenmaal ingesteld, is deze net zo gemakkelijk te gebruiken in uw eigen projecten.
Conclusie
In deel drie van deze tutorialserie hebben we behoorlijk veel aandacht besteed. We hebben gezien hoe besturingselementen moeten worden weergegeven wanneer beheerdersmeldingen worden weergegeven in plaats van dat ze altijd worden weergegeven zodra een beheerderspagina is geladen. Dit is op veel manieren nuttig, maar ons voorbeeld liet zien hoe een aangepast beheerdersbericht kon worden weergegeven nadat de plugin-opties waren opgeslagen.
Daarna gingen we verder met twee verschillende voorbeelden van het afwijzen van aanhoudende kennisgevingen van beheerders. Dit geeft u veel flexibiliteit bij het presenteren van beheerdersmeldingen aan de gebruiker. En in het volgende en laatste deel van deze zelfstudiegroep gaan we op zoek naar meer manieren om aanhoudende kennisgevingen van beheerders ongedaan te maken.
En voor een beetje plezier maken we onze eigen aangepaste soorten meldingen voor beheerders en voegen we pictogramdecoraties toe.
