Share
Nyckeln till WordPress 'flexibla foundation är i användningen av krokar. Det är i teman, plugins eller kärnan, krokarna ger oöverträffad tillväxt samtidigt som du säkerställer kompatibilitet med framtida versioner av WordPress. Som ett resultat borde förstå dem utan tvekan vara en del av någon utvecklares repertoar. Bli med när vi upptäcker det här enkelt, men ändå avancerade systemet från insidan.
Som en färdplan för denna artikel kommer vi att gå över konceptet bakom krokar, deras genomförande och, givetvis, exempel.
"Enkelt sagt, en krok är en platshållare för en handling."
Bakom alla välskrivna program är ett solidt koncept som svarar på frågorna om vad och varför. Krokar är inget undantag. Enkelt sagt, en krok är en platshållare för en handling. När en signifikant händelse inträffar, t.ex. publicering av ett inlägg, aktiveras en krok, vilket möjliggör att relevanta reaktioner äger rum. I utvecklingsvillkor kan man tänka på krokar som genomförandet av ett händelsestyrt system.
Mer än bara en definition kräver ett koncept resonemang som belyser varför det är användbart. Krokarna spelar en viktig roll i WordPress på grund av projektets ständigt utvecklande natur. Med hundratals utvecklare som kontinuerligt uppdaterar systemet är det inte möjligt att redigera kärnfilerna för varje plugin, tema eller speciell anpassning, eftersom de ofta ändras. I stället behövs ett ramverk för att förlänga systemet, så att extern funktionalitet kan ha lika stor effekt som intern manipulation. Krokar är nyckeln till denna ram.
Som utvecklare utvidgas rollen att inte bara förstå vad något gör eller varför det är gjort, men också att inse hur det skapas. Med andra ord, för att kunna förstå kroksystemet, måste man förstå hur de implementeras.
Precis som i ett multipelprovstest, är det dock inte nödvändigtvis att titta direkt på svaren, den bästa ideen. Såsom många teststrategier föreslår, är det ofta bättre att läsa frågan, formulera egna tankar om svaret och sedan välja det val som liknar din resonemang mest. En liknande metod kan genomföras när man förstår implementering av mjukvaruutveckling. snarare än att titta på någon annans kod för att förstå hur en funktion realiseras är det ofta ännu mer användbar att först implementera det själv och sedan återvända för att undersöka hur det verkligen görs. Det här är precis vad vi ska göra.
Snarare än att titta på någon annans kod för att förstå hur en funktion realiseras är det ofta ännu mer användbar att först implementera det själv och sedan återvända för att undersöka hur det verkligen görs.
För att få insikt om hur ett system implementeras är dokumentation ofta en användbar start. Låt oss undersöka sammanfattningarna av de två kärnan WordPress-krokfunktionerna enligt Codex:
Accentsconagua
add_action ($ hook, $ function [, $ priority [, $ numArgs]]) - Anger en funktionshanterare, $ funktion, att kallas en gång en viss krok, $ krok, aktiveras på grund av händelsens händelse. $ prioritet avgör om denna funktionshanterare kallas före eller efter andra funktionshanterare och som standard till 10. Lägre prioriteringar resulterar i att en funktion kallas tidigare och vice versa. $ numArgs är antalet argument som funktionshanteraren tar och standardinställningar till 1.do_action ($ hook [, $ arg1 [, $ arg2 [, $ arg3 [,?]]]]) - Aktiverar en viss krok, $ krok, genom att ringa alla hanteringsfunktioner med valfria argument $ arg1, $ ARG2, $ ARG3, etc.Med dokumentationen i handen är det dags att göra några slutsatser om dessa två funktioner. add_action behöver bara associera en funktion, prioritet och antal argument med en sträng. Det här verkar som det perfekta jobbet för en PHP-array, som fungerar som en hashkarta som lagrar nyckelvärdespar. do_action är ännu mer trivial, vilket kräver en enkel blick upp i samma matris för att hitta motsvarande funktionshanterare och därefter ringa dem. Med våra insikter i åtanke är det dags att gå vidare till vår implementering.
Eftersom vi gör detta för att få insikt i WordPress-kroksystemet, behöver vi inte implementera dessa två funktioner ordentligt från dokumentationen. Låt oss istället fokusera på deras implementeringar utan de valfria argumenten för att spara tid och fortfarande få kärnan av det.
Innan vi börjar, låt oss lägga en skiss:
add_action kommer att lagra det angivna kroknamnet och en uppsättning motsvarande funktionshanterare som en nyckelvärdespar i matrisen.do_action kommer att hämta motsvarande funktionshanterare för ett visst kroknamn och ringa var och en.Detta ger följande kod:
$ actions = array (); funktion add_action ($ hook, $ function) global $ actions; // skapa en rad funktionshanterare om den inte redan existerar om (! isset ($ actions [$ hook])) $ actions [$ hook] = array (); // lägg till den aktuella funktionen i listan över funktionshanterare $ actions [$ hook] [] = $ function; funktion do_action ($ hook) global $ actions; om isset ($ actions [$ hook])) // ringa varje funktionshanterare förknippad med den här kroken ($ actions [$ hook] som $ -funktionen) call_user_func ($ function);
Det är inte dåligt; Vi implementerade ett mångsidigt kroksystem i cirka 20 linjer kod. Nu när vi har fått en uppfattning om hur krokar fungerar, låt oss dyka in i WordPress-kärnkoden för att bekräfta vår hypotes.
Ett verktyg för att snabbt navigera genom den här koden är Yoasts PHP Cross Reference i WordPress Source. Söker efter add_action ger följande kod:
funktion add_action ($ tag, $ function_to_add, $ priority = 10, $ accepted_args = 1) return add_filter ($ tag, $ function_to_add, $ priority, $ accepted_args); funktion add_filter ($ tag, $ function_to_add, $ priority = 10, $ accepted_args = 1) global $ wp_filter, $ merged_filters; $ idx = _wp_filter_build_unique_id ($ tag, $ function_to_add, $ priority); $ wp_filter [$ tag] [$ prioritet] [$ idx] = array ('function' => $ function_to_add, 'accepted_args' => $ accepted_args); unset ($ merged_filters [$ tag]); återvänd sant; add_action samtal add_filter vilket, överraskande, lägger till den angivna funktionen i en array som är märkt av kroknamnet, $ tag. Även om det är lite mer involverat på grund av $ prioritet och $ accepted_args parametrar, motsvarar denna funktion i huvudsak vår egen, bekräftar våra misstankar. do_action, om än längre och lite mer komplicerat, kokar ner till följande kod:
funktionen do_action ($ tag, $ arg = ") [Ta bort kod som registrerar statistik, hanterar argument och hanterar filter] gör foreach ((array) current ($ wp_filter [$ tag]) som $ the_) if is_null ($ _ _''funktionen '])) call_user_func_array ($ the _ [' function '], array_slice ($ args, 0, (int) $ the _ [' accepted_args '])); medan (nästa ($ wp_filter [$ tagg])! == false); [Utelämnad kod som rensar upp]
Looping genom de tillhörande funktionerna och kallar var och en är inte konstigt för oss alla; Det är faktiskt precis vad vi förutsåg i vår implementering. Därför hjälpte vi, med början av våra egna tankar om koden, inte bara oss bättre förståelse utan krävde också kritiskt tänkande och problemlösning som är väsentligt för mjukvaruutveckling.
Med vår förståelse av vad, varför och hur bra är det dags att gå vidare till två exempel. Den första är ett spel på RSS; istället för att tillhandahålla anmälningar via syndikering, varför använd inte e-post istället?
För att implementera vårt system måste vi leta efter när ett inlägg publiceras. Men vilken krok borde vi använda? API-åtgärdsreferensen ger en lista med krokar tillsammans med beskrivningar av de associerade händelser som kan hjälpa oss att identifiera exakt detta. Faktum är att publish_post krokens beskrivning passar vad vi behöver, så låt oss lägga till en funktionshanterare till den:
add_action ('publish_post', 'notify_via_email'); Allt som är kvar är att skicka en e-postmeddelande till någon i notify_via_email funktionshanterare. Observera att API-åtgärdsreferensen anger att publish_post krok passerar post-ID som ett argument för vår hanteringsfunktion. Detta gör det möjligt för oss att få information om posten via get_post funktion, som så:
funktion notify_via_email ($ post_id) $ post = get_post ($ post_id); $ till = '[email protected]'; $ subject = 'Post publicerad på'. get_bloginfo ('name'); $ message = $ post-> post_title. "publicerades på". get_bloginfo ('name'). ' från och med ' . $ post-> post_date. '. Du kan se den på '. get_permalink ($ post_id). ''; wp_mail ($ till, $ subject, $ message);
Efter att ha hämtat inlägget använder vi dess titel, datum och permalink i vårt e-postmeddelande. Den skickas sedan via wp_mail funktion som kräver en mottagare, ett ämne och ett meddelande som dess parametrar. Därmed är vårt enkla e-postmeddelande system komplett. Observera att det inte rekommenderas att ringa wp_mail flera gånger på en gång, eftersom det är bunden att presentera en signifikant fördröjning i sidladdningstiden när publiceringspostknappen trycks in.
Först kan det tyckas att ett tema är ett lämpligare medium för en sådan kod. Tvärtom, genom att temat är temat mottagligt för revision och förändring. Som ett resultat kan analyskoden lätt gå vilse i en övergång från ett tema till ett annat.
Om än lite konstruerad, vår första ansökan var en snabb introduktion till användning av krokar. Det här andra exemplet kommer emellertid att låna sig mycket mer för användning i verkligheten. Vi skapar ett enkelt Google Analytics-plugin som automatiskt sätter in spårningskoden i sidfoten på en sida.
Först kan det tyckas att ett tema är ett lämpligare medium för en sådan kod. Tvärtom, genom att temat är temat mottagligt för revision och förändring. Som ett resultat kan analyskoden lätt gå vilse i en övergång från ett tema till ett annat. Att skapa ett plugin omger denna nackdel; eftersom det kommer att förbli aktivt oavsett vilket tema som används, kommer analysekoden fortfarande att finnas och eliminera behovet av teman underhåll.
Men hur pluggar vi koden i sidfoten på en webbplats? Detta görs också via krokar. Om du har arbetat med WordPress-teman innan har du förmodligen kallat wp_head och wp_footer Fungerar i respektive sidans huvud och sidfot. Båda dessa funktioner är närvarande för att enkelt aktivera krokar så att plugins enkelt kan infoga koden i dessa viktiga områden på sidan. Följaktligen lägger vi helt enkelt en åtgärd till wp_footer krok:
add_action ('wp_footer', 'add_google_analytics_code'); Vår add_google_analytics_code funktion, som namnet antyder, skriver ut Google Analytics-koden:
Kom ihåg att ändra UA-XXXXX-X till ditt sajtspecifika ID och du är helt klar! Lägg bara till den här koden i en fil och ladda upp den till din WordPress plugins katalog. Var noga med att lägga in en pluginhuvud, så här:
Glöm inte att byta namn på författaren, författaren URI, och aktivera självklart pluginprogrammet!
Genom att dela upp krokar i ett koncept, ett genomförande och exempel har vi effektivt granskat dem från insidan av WordPress-kärnan till utsidan i en verklig applikation. I stället för att bara titta på WordPress-kärnkoden implementerade vi vår egen version av krokar genom inferens, så att vi kunde få en djupare utvecklareliknande förståelse för detta kraftfulla system. Slutligen, med en verklig Google Analytics Plugin-applikation, fick vi preliminära insikter om hur användbara krokar verkligen kan vara. Var noga med att gå med oss nästa gång och gärna dela dina egna innovativa användningsområden av krokar i kommentarerna nedan!
