Grunderna för Action Hooks i WordPress

När som helst någon gång börjar komma in i mer avancerad programmering – vare sig det är i WordPress eller något annat ramverk, bibliotek, grund eller programmeringsspråk – det finns tillfällen då nya koncept ofta kan vara svårare att förstå än andra.

Jag har i allmänhet tyckt att detta är sant när en person har lärt sig grunderna i till exempel objektorienterad programmering men inte har blivit utsatt för nyanserna i vissa saker som designmönster.

Exempel: Jag har skrivit om det händelsedrivna designmönstret (eller publicera-prenumerera eller Pub/Sub som vissa gillar att hänvisa till det) i andra inlägg.

Ja, det finns vissa skillnader för var och en, men den allmänna idén är att något händer och en händelse tas upp och allt som lyssnar på den händelsen, eller prenumererar på den händelsen, kommer att svara.

Foto av Claus Grünstäudl på Unsplash

Detta är det primära mönstret som WordPress använder som gör att vi bokstavligen kan ansluta till vissa exekveringspunkter. Vi kan generellt föreställa dessa som actionhooks i WordPress.

Hur som helst, applikationen gör vissa punkter tillgängliga för oss att lägga till vår egen funktionalitet. När den funktionen är registrerad kommer WordPress att lämna sin kodbas, så att säga, hoppa in i vår och sedan återvända till vår.

Det är lätt nog att förstå, men vad händer om du vill exponera områden i din kod som låter andra haka in i din kod?

Action Hooks i WordPress

Innan du tittar på hur WordPress implementerar detta mönster är det viktigt att förstå grunderna i detta mönster. Även om detta inte på något sätt är heltäckande, är det tänkt att ge en grundläggande förståelse för mönstret så att det är möjligt att läsa och skriva WordPress-centrerad kod.

Så vad är ett bra sätt att tänka på Pub/Sub-mönstret? Wikipedia definierar det som:

Inom mjukvaruarkitektur är publicera–prenumerera ett meddelandemönster där avsändare av meddelanden, kallade publicister, inte programmerar meddelandena för att skickas direkt till specifika mottagare, kallade prenumeranter, utan istället kategoriserar publicerade meddelanden i klasser utan att veta vilka prenumeranter, om några., det kan finnas. På samma sätt uttrycker prenumeranter intresse för en eller flera klasser och får endast meddelanden som är av intresse, utan att veta vilka utgivare, om några, det finns.

Förstå mönstret

Det här kan vara mycket att ta in i början. Jag vet inte, men låt oss dela upp det:

1. Det finns en tjänst, i vårt fall WordPress, som ansvarar för att publicera meddelanden till den som prenumererar (den vet inte nödvändigtvis vem som lyssnar).
2. När en abonnent lyssnar, kommer den att vidta åtgärder närhelst den hör den åtgärden.
3. När abonnentens kod är klar kommer programmet att återgå till den ursprungliga exekveringspunkten (som är dit utgivaren skickade meddelandet).

Det finns nyanser i detta som asynkron funktionalitet och sånt, men det är mer avancerat än jag skulle föredra att få i just det här inlägget. Syftet med detta är trots allt att lägga en grund för att förstå och implementera funktionalitet.

Asynkron funktionalitet kan komma in i trådning eller Ajax och genom dessa är viktiga ämnen, det här är inte det inlägget.

Hur ser det här ut i WordPress?

Det kanske enklaste sättet att beskriva just detta mönster i WordPress är genom att använda funktionsanropen:

• do_action
• add_action

Ibland kan nomenklaturen vara förvirrande men enkelt uttryckt, do_action publicerar och en händelse och add_action- prenumeranter till en händelse. Eller kanske ett bättre sätt att tänka på det är:

do_action säger åt WordPress att utföra de åtgärder som har lagts till.

Ibland är det bra att ha enkla fraser för att komma ihåg hur saker fungerar. Jag vet inte om ovanstående är den mest catchy frasen eller mest minnesvärd, men det är något, eller hur?

Observera dessutom att do_action och add_action är saker som är kärnan i WordPress och även är tillgängliga för vår utveckling. Innan vi går vidare, låt oss ta en titt på vad var och en betyder:

För do_action :

Den här funktionen anropar alla funktioner som är kopplade till actionkroken $tag. Det är möjligt att skapa nya actionkrokar genom att helt enkelt anropa denna funktion, ange namnet på den nya kroken med $tagparametern.

Eller ännu enklare uttryckt:

Utför funktioner kopplade till en specifik actionkrok.

När du hänvisar till krokar kan detta antingen vara krokar definierade av WordPress eller anpassade krokar som du anger i ditt tema eller din plugin.

När det gäller add_action :

Åtgärder är de krokar som WordPress-kärnan lanserar vid specifika punkter under exekvering, eller när specifika händelser inträffar. Plugins kan ange att en eller flera av dess PHP-funktioner exekveras vid dessa punkter, med hjälp av Action API.

Och på liknande sätt, enklare uttryckt:

Kopplar en funktion till en specifik åtgärd.

Att ställa in detta praktiskt är lite annorlunda eftersom vi vanligtvis använder add_action för att lägga till vår egen kod till WordPress.

Ett praktiskt exempel

Till exempel kanske du har skrivit något så här:

<?php
add_action('wp_insert_post_data', __NAMESPACE__. 'processPermalink');
/**
 * Processes the permalink so we can remove any characters that may cause a problem when communicating
 * with the API.
 *
 * @param  array $data The array of information about the post.
 * @return array $data The data without the malformed information in the post name for the URL.
 */
public function processPermalink($data)
{
    if (!in_array($data['post_status'], array('draft', 'pending', 'auto-draft'))) {
        $data['post_name'] =
            preg_replace(
                '/(%ef%b8%8f|™|®|©|™|®|©|™|®|©)/',
                '',
                $data['post_name']
            );
    }
    return $data;
}

I det här fallet, någonstans i WordPress-kodbasen finns det ett do_action -anrop för wp_insert_post_data- kroken och den accepterar en funktion och skickar den minst en enda parameter.

Lägga till dina egna krokar

Men vad händer om du vill ge andra utvecklare möjlighet att ansluta till ditt plugin eller tema? I så fall bör du bry dig om att använda do_action och sidan som länkades tidigare i detta dokument ger allt du behöver för att ställa in detta.

Det är faktiskt mycket enklare, enligt min mening, än att arbeta med add_action eftersom add_action ger att vi inte bara kopplar in oss i en befintlig utgivare, utan att vi lägger till vår egen anpassade logik.

do_action å andra sidan kräver att vi anger ett namn på funktionen som ska köras och sedan listan med argument som ska skickas till funktionen som ska köras.

Det är allt?

I ungefär så enkla termer som jag kan göra det, ja. Det finns en del nyanser kring prioritet, antal argument och att arbeta med namnrymder och objektorienterad programmering. Men återigen, det ligger utanför ramen för detta inlägg. Jag kanske ska gå in på det mer ingående i ett annat inlägg.

Men för nu, om du inte är bekant med grunderna i:

• Pub/Sub-mönstret,
• do_action,
• och add_action

Du är nu bekväm nog att läsa koden du arbetar med, förstå hur koden fungerar och till och med implementera dina egna lösningar när det behövs.

Jag håller för närvarande på att skriva en e-bok (tillsammans med en mängd annat premiuminnehåll). Om du är intresserad, kolla in vad du får.