Share
Välkommen till den andra delen av serien. I den första artikeln förklarade vi WordPress-kodningsstandarderna, hur man undviker navnebrottskollisioner, kommentarer i koden och några grundläggande säkerhetstips.
Idag ska vi gå lite djupare och skriva lite mer kod och lära oss några tekniker för att förbättra prestanda och säkerhet för våra plugins. De ämnen vi kommer att täcka är som följer:
Ta tag i kodredigeraren och gör dig redo att spela med WordPress!
Det första du måste tänka på är att WordPress har två underbara funktioner (wp_enqueue_script och wp_enqueue_style) för att låta dig inkludera dina skript och stilar. För det ändamålet, lägg till dem inte manuellt i rubriken eller använda wp_head åtgärdskrok.
Om du använder WordPress-metoderna, kan caching och minifiera plugins kunna inkludera dina skript i sina funktioner. Du kommer att kunna välja att placera dem i sidfot eller rubrik mycket enkelt. Du kommer att kunna lägga till beroende skript och även använda alla tricks förklaras nedan tillsammans med andra funktioner.
Felaktig:
Accentsconagua
add_action ('wp_head', 'my_custom_scripts'); funktion my_custom_scripts () echo ''; Korrekt:
add_action ('wp_enqueue_scripts', 'my_customs_scripts'); funktion my_customs_scripts () wp_enqueue_script ("script-handler", get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); Jag kommer inte att ge dig en fullständig handledning om hur du använder wp_enqueue_xxxx eftersom det finns många av dem tillgängliga (och Codex är en bra resurs!) Och jag försöker helt enkelt peka på hur du ska lägga till skript i dina teman eller plugins.
Vad du behöver alltid tänka på att lämna det lättaste fotavtrycket möjligt. Det betyder att du inte ska inkludera filer där de inte ska vara.
Du kanske tror att det bara är en fil, det kommer inte att påverka webbplatsen och det är som att kasta ett papper i marken i parken eftersom det bara är ett enda papper, men det är inte hur sakerna fungerar: Om alla utvecklare lämnar sina skript överallt, slutanvändaren kommer att sluta med en helt uppblåst webbplats och vi vill inte ha det.
Nu när vi har täckt det så får vi se några tips om hur du bara ska inkludera dina skript när det behövs.
// FRONT END END add_action ('wp_enqueue_scripts', 'my_front_customs_scripts'); funktion my_customs_scripts () wp_enqueue_script ("script-handler", get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); // BACKEND ONLY add_action ('admin_enqueue_scripts', 'my_back_customs_scripts'); funktion my_customs_scripts () wp_enqueue_script ("script-handler", get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); Men vänta! Låt oss gå ett steg längre och bara inkludera skript på de sidor du verkligen behöver dem. En bra metod är att registrera dem först och sedan enque på de sidor som behövs
// FRONT END END add_action ('wp_enqueue_scripts', 'my_front_customs_scripts'); funktion my_customs_scripts () wp_register_script ("script-handler", get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); om (is_page ('my-page')) wp_enqueue_script ('script-handler'); // Var kreativ att bara inkludera filer vid behov // om (is_single ()) // om (is_home ()) // om ('cpt-name' == get_post_type ()) // BACKENDEND ONLY add_action (' admin_enqueue_scripts ',' my_back_customs_scripts '); funktion my_customs_scripts ($ hook) wp_register_script ("script-handler", get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); // För att inkludera det endast när du redigerar ett inlägg om ('edit.php' == $ hook) wp_enqueue_script ('script-handler'); // Om du lagt till en alternativ sida som denna // $ plugin_screen_id = add_options_page (...) // du kan göra $ screen = get_current_screen (); om ($ plugin_screen_id == $ skärm-> id) wp_enqueue_script ('script-handler'); / * Ett annat sätt att använda skärm id * / add_action ('admin_print_styles-'. $ Plugin_screen_id, 'my_back_customs_scripts');// FRONT END END add_action ('wp_enqueue_scripts', 'my_front_customs_scripts'); funktion my_customs_scripts () wp_register_script ("script-handler", get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); // om du behöver ett skript som ska inkluderas för en kortnummer // Lägg inte till det överallt // Istället kan du bara inkludera det när det behövs globala $ posten; om (is_a ($ post, 'WP_Post') && has_shortcode ($ post-> post_content, 'custom-shortcode')) wp_enqueue_script ('script-handler'); Medan de andra kodavsnitten gäller både skript och format, fungerar följande endast med wp_enqueue_style (åtminstone för stunden).
// FRONT END ONLY add_action ('wp_enqueue_scripts', 'my_front_customs_styles'); funktion my_front_customs_styles () wp_register_style ('my-plugin-css', plugins_url ('my-plugin / css / plugin.css')); // Låt oss inkludera denna css bara för gamla (och skitliga) webbläsare wp_enqueue_style ('my-plugin-css'); globala $ wp_styles; $ wp_styles-> add_data ('my-plugin-css', 'conditional', 'lte IE 9'); Du kan se några fler exempel i Codex. Ett annat utmärkt exempel som du kan använda för att starta alla dina plugins är WordPress Plugin Boilerplate. Ta en titt på koden för att se hur skript och stilar ingår. Wpfavs-plugin (baserat på WordPress Plugin Boilerplate) är ett bra exempel på hur man skapar ett plugin för Wordpress-pluggen.
För det här ämnet delar jag några dåliga vanor som jag sett mycket vid Ajax i WordPress och de kunde delas i följande meningar:
wp_localize_scriptJag vet att jQuery gör Ajax samtal en bit tårta, och vi kan helt enkelt skapa en fil som heter ajax.php, inkluderawp-load.php på det och gör vår Ajax där. Men det är inte "WordPress-sättet" - det är inte framtidssäkert. Ännu mer, det är mindre säkert och du kommer att sakna mycket WordPress-funktionalitet.
Det rätta sättet är att använda wp_ajax_my_action och wp_ajax_nopriv_my_action action krokar. Huvudskillnaden mellan de två är att den första används för loggade användare och den andra används för icke-loggade användare.
Observera att "my_action" ska ändras för ditt åtgärdsnamn. Vi ska se hur det fungerar på ett ögonblick.
Låt oss se allt detta i ett enkelt exempel med lite kod och fantasi. Låt oss föreställa oss att vi vill visa 5 inlägg när någon användare (loggad eller inte) klickar på en knapp. Vi kommer att namnge denna åtgärd som cool_ajax_example, så låt oss börja lägga till Ajax-återuppringningsfunktionerna som kommer att returnera data.
Du kan inkludera den här koden på din functions.php eller inuti din plugin.
// Först lägger vi till handlingarna krokar add_action ('wp_ajax_cool_ajax_example', 'cool_ajax_example_callback'); add_action ('wp_ajax_nopriv_cool_ajax_example', 'cool_ajax_example_callback'); funktion cool_ajax_example_callback () ...Som du kan se använder båda krokarna samma återuppringningsfunktion som kommer att returnera data. Observera också att vårt åtgärdsnamn är i slutet av kroknamnet wp_ajax_cool_ajax_example
Det är väldigt viktigtatt skriva åtgärdsnamnet rätt överallt eller det kommer inte att fungera alls.
Innan vi fortsätter med återuppringningsfunktionen, går vi vidare till den jQuery som behövs för Ajax-samtalet. Skriptet jQuery kommer att elda när vi trycker på en enkel HTML-knapp, och vi måste skicka den förfrågan till admin-ajax.php filen som det är skriptet som hanterar alla AJAX-förfrågningar i Wordpress. Vi måste också lägga till en nonce som vi redan sa att vi vill göra det säkert så här kommer vi till handling wp_localize_script fungera.
Om du inkluderade dina skript på rätt sätt som förklarats i början av den här artikeln har du ett skripthanterarens namn (i våra exempel ovan "script-handler"), så låt oss använda det för att skicka våra PHP-värden till vår javascript-fil. Du kan inkludera denna bit kod direkt efter wp_enqueue_function brukade inkludera JavaScript.
wp_localize_script ("script-handler", "MyVarName", array ('ajax_url' => admin_url ('admin-ajax.php'), 'nonce' => wp_create_nonce ('return_posts')));Som du kan se wp_localize_script är ett ganska enkelt sätt att skicka någon PHP-variabel till våra JavaScript-filer och det kommer att skriva ut giltigt xhtml på grund av taggar. Koden ovan kommer att skrivas ut i rubriken när JavaScript-filen med script-hanterare som namn laddas och det kommer att se ut som om:
Nu är det dags att skapa vår javascriptfil, låt oss kalla det my.js och det kommer att se ut som:
(funktion ($) $ (funktion () $ ('# -knapp'). klicka (funktion (e) e.preventDefault (); $ .ajax (url: myVarName.ajax_url, data: action: ' cool_ajax_example ', nonce: myVarName.nonce, framgång: funktion (svar) $ (' # response-container '). html (svar);, typ: "POST",););); ) (jQuery);Observera hur vi använder nonce och ajax_url som vi passerade med wp_localize_script. Kontrollera även att vi skickar ett POST-värde som heter "action" som matchar det åtgärdsnamn vi använde i wp_ajax krokar.
Nu är det dags att slutföra vår återuppringningsfunktion. Det första vi behöver göra är att kontrollera att nonce är rätt och då kan vi returnera några inlägg.
funktion cool_ajax_example_callback () $ nonce = $ _POST ['nonce']; // Det första vi gör är att kontrollera nonce och döda skriptet om det är fel om (! Wp_verify_nonce ($ nonce, 'return_posts')) dö ('Wrong nonce!'); $ args = array ('post_type' => 'post', 'post_status' => 'publicera', 'posts_per_page' => 5,); // Query $ the_query = nya WP_Query ($ args); // Loop om ($ the_query-> have_posts ()) echo ''; medan ($ the_query-> have_posts ()) $ the_query-> the_post (); eko "'. get_the_title (). '
'; eko'; annars echo 'Inlägg hittades inte'; / * Återställ ursprungliga postdata * / wp_reset_postdata (); // glöm inte det här // Vi gör ett enkelt samtal vi vill inte ha något annat att springa dö (); Om du behöver något mer komplext, till exempel att radera ett inlägg, kontrollera alltid användarbehörigheter, som jag nämnde vid beredningen av det här ämnet. Till exempel, om du bara vill ha administratörer att göra vissa åtgärder kan du göra i ditt skript något som:
om (current_user_can ('administrator')) wp_delete_post ($ postid, $ force_delete); Med alla tips ovan är du nu en mästare i WordPress Ajax och du kan utföra alla åtgärder du vill ha. Försök spela med ovanstående och anpassa det till dina behov. Jag personligen gillar att använda json datatyp och jag gör det echo json_encode () istället för att göra enkla eko på mina skript, men det är en annan sak.
Syftet med det här avsnittet är inte att lära dig hur filter och åtgärder fungerar, det finns utmärkta handledning kring det ämnet som förklarar det i detalj. Vad jag ska förklara din här är varför du borde lägga till filter och åtgärder på dina pluginprogram och visa några exempel för enkel förståelse.
Men först låt oss göra en introduktion till dessa begrepp:
Kolla Plugin API för mer information om handtagskrokar och filter.
Det är enkelt: Eftersom det gör din plugin bättre. På det sättet kommer utvecklare och vanliga användare alla att kunna utöka, anpassa eller förbättra pluginet utöver det ursprungliga ändamålet utan att påverka kärnan i det.
Ta till exempel ett e-commerce-plugin. På grund av krokarna och filtren kan du skapa nya plugins som hakar i den, till exempel nya betalnings gateways, fraktfunktioner och mycket mer.
Bli inte galen att lägga till handlingar och filter överallt. I början kommer du att hitta det här lite svårt eller irriterande, så försök att tänka som om du var en annan utvecklare som tittar på ett nytt plugin och fråga dig själv "behöver jag här en åtgärdskrok?". Dessutom kommer en stor andel av åtgärd och filter att läggas på efterfrågan när du börjar få supportförfrågan (ja, du får dem alltid!) Eller feedback från dina användare.
Som allting i livet, så snart det blir en vana så ser du mycket tydligt var du ska inkludera dem.
Några rekommendationer för var du ska inkludera filter:
Låt oss använda återuppringningsfunktionen som används i den här artikeln för att se ett exempel på rekommendationerna ovan. För att skapa filterbara variabler i det här fallet använder vi apply_filters ()
funktion cool_ajax_example_callback () $ nonce = $ _POST ['nonce']; // Det första vi gör är att kontrollera nonce och döda skriptet om det är fel om (! Wp_verify_nonce ($ nonce, 'return_posts')) die ('Wrong nonce!'); $ args = array ('post_type' => 'post', 'post_status' => 'publicera', 'posts_per_page' => 5,); // Frågan $ the_query = nya WP_Query (apply_filters ('cool_ajax_query', $ args)); // Loop om ($ the_query-> have_posts ()) echo ''; medan ($ the_query-> have_posts ()) $ the_query-> the_post (); eko "'. get_the_title (). '
'; eko'; annars echo 'Inlägg hittades inte'; / * Återställ ursprungliga postdata * / wp_reset_postdata (); // glöm inte det här // Vi gör ett enkelt samtal vi vill inte ha något annat att springa dö (); Som du kan se har jag lagt till ett filter i $ args variabel som kommer att köras strax före WP_Query kör frågan. Med ett enkelt filter kan varje användare ändra hur många inlägg som returneras.
funktion wpt_alter_coolajax_query ($ args) $ args ['posts_per_page'] = 10; returnera $ args; add_filter ('cool_ajax_query', 'wpt_alter_coolajax_query');Du kan använda filter i olika scenarier, använd bara din fantasi. Till exempel på min plugin WordPress Social Inbjudningar låter jag användare ändra popup-stilarket med ett filter om de väger en helt annan stil.
Eller vid detta tillfälle när plugin skickar e-postmeddelanden ger jag möjlighet att ändra "From email" det wp_mail () kommer att använda.
funktion get_from_email () if (isset ($ this -> _ user_data)) return apply_filters ('wsi_from_email', $ this -> _ user_data-> user_email); returnera apply_filters ('wsi_from_email', get_bloginfo ('admin_email')); När det gäller åtgärder förändras det lite. Du vill lägga till åtgärdshooks i följande scenarier (inte begränsat till):
För att skapa dessa krokbara områden använder vi do_action () fungera. Låt oss tillämpa dem i vårt exempel.
funktion cool_ajax_example_callback () $ nonce = $ _POST ['nonce']; // Det första vi gör är att kontrollera nonce och döda skriptet om det är fel om (! Wp_verify_nonce ($ nonce, 'return_posts')) dö ('Wrong nonce!'); $ args = array ('post_type' => 'post', 'post_status' => 'publicera', 'posts_per_page' => 5,); // Frågan $ the_query = nya WP_Query (apply_filters ('cool_ajax_query', $ args)); // Loop om ($ the_query-> have_posts ()) // vi kör kroken innan loopen är proccesed do_action ('cool_ajax_before_loop', get_the_ID ()); eko "'; medan ($ the_query-> have_posts ()) $ the_query-> the_post (); // vi kör kroken innan titeln är tryckt do_action ('cool_ajax_before_title', get_the_ID ()); eko "'. get_the_title (). '
'; // vi kör kroken efter att titeln är tryckt do_action ('cool_ajax_after_title', get_the_ID ()); eko'; // vi kör kroken efter att slingan är proccesed do_action ('cool_ajax_after_loop', get_the_ID ()); annars echo 'Inlägg hittades inte'; / * Återställ ursprungliga postdata * / wp_reset_postdata (); // glöm inte det här // Vi gör ett enkelt samtal vi vill inte ha något annat att springa dö (); Som ni ser kan jag gå med ett argument till krokarna med get_the_ID () . Varje funktion som hakar i vår handtagskrok kommer att kunna använda det argumentet. Låt oss se några exempel:
/ ** * Visa inlägget presenterad bild före titel * / funktion wpt_show_post_image ($ post_id) echo get_the_post_thumbnail ($ post_id, 'thumbnail'); add_action ('cool_ajax_before_title', 'wpt_show_post_image'); / ** * Visa postkategorier efter titel * / funktion wpt_show_post_cats ($ post_id) echo get_the_category_list (",", $ post_id); add_action ("cool_ajax_after_title", "wpt_show_post_cats");Du kan också använda do_action () krokar för att köra andra åtgärder istället för att lägga till nya markeringar som exemplet ovan. Till exempel, i WordPress Social Invitationer har jag en åtgärdskrok som bränder varje gång ett meddelande skickas. Använd sedan myCRED plugin Jag kan koppla åtgärden att ge poäng till användaren som bara skickat meddelandet.
Som du kan se att lägga till krokar och filter kommer inte bara att gynna ditt plugin, det kommer också att gynna andra utvecklare och användare. Så varför inte börja du lägga till några filter och handlingar runt?
Idag lärde vi oss att inkludera skript och stilar, hur man gör Ajax kallar WordPress-sättet och några grundläggande tips för filter och åtgärder. Vi har redan mycket information för att utveckla ett bra plugin och jag kan nu säga att dessa serier är nära slutet.
I den kommande och slutliga artikeln ska jag prata om internationalisering, felsökning och dokumentation för att lägga upp saker på vad jag tycker är de bästa sakerna att överväga när man utvecklar ett plugin.
