WordPressin toimintakoukkujen perusteet
Aina kun joskus alkaa päästä edistyneempään ohjelmointiin – olipa se sitten WordPressissä tai missä tahansa muussa viitekehyksessä, kirjastossa, perustassa tai ohjelmointikielessä – on aikoja, jolloin uudet käsitteet voivat usein olla vaikeampia ymmärtää kuin toiset.
Olen yleensä havainnut tämän olevan totta aina, kun henkilö on oppinut esimerkiksi olioohjelmoinnin perusteet, mutta ei ole altistunut tiettyjen asioiden, kuten suunnittelumallien, vivahteille.
Esimerkkitapaus: Olen kirjoittanut tapahtumalähtöisestä suunnittelumallista (tai julkaisu-tilauksesta tai Pub/Subista, kuten jotkut haluavat viitata siihen) muissa viesteissä.
Kyllä, jokaisessa on eroja, mutta yleinen ajatus on, että jotain tapahtuu ja tapahtuma nostetaan ja kaikki, joka kuuntelee tätä tapahtumaa tai tilaa tapahtuman, reagoi.
Kuva: Claus Grünstäudl Unsplashista
Tämä on WordPressin ensisijainen malli, jonka avulla voimme kirjaimellisesti liittyä tiettyihin suorituskohtiin. Voimme yleensä käsittää nämä toimintakoukut WordPressissä.
Joka tapauksessa sovellus tarjoaa tiettyjä kohtia, joiden avulla voimme lisätä omia toimintojamme. Kun tämä toiminto on rekisteröity, WordPress jättää niin sanotusti koodikantansa, hyppää omaan ja palaa sitten takaisin omaan.
Se on tarpeeksi helppo ymmärtää, mutta entä jos haluat paljastaa koodissasi alueita, joiden avulla muut voivat tarttua koodiisi?
Toimintakoukut WordPressissä
Ennen kuin tarkastellaan, kuinka WordPress toteuttaa nämä mallit, on tärkeää ymmärtää tämän mallin perusteet. Vaikka tämä ei suinkaan ole kattava, sen tarkoituksena on antaa perustavanlaatuinen käsitys mallista, jotta on mahdollista lukea ja kirjoittaa WordPress-keskeistä koodia.
Joten mikä on hyvä tapa ajatella Pub/Sub-mallia? Wikipedia määrittelee sen seuraavasti:
Ohjelmistoarkkitehtuurissa publish-subscribe on viestimalli, jossa viestien lähettäjät, joita kutsutaan julkaisijoiksi, eivät ohjelmoi viestejä lähetettäväksi suoraan tietyille vastaanottajille, joita kutsutaan tilaajiksi, vaan luokittelevat julkaistut viestit luokkiin tietämättä, ketkä tilaajat, jos sellaisia on., siellä voi olla. Vastaavasti tilaajat ilmaisevat kiinnostuksensa yhteen tai useampaan luokkaan ja saavat vain kiinnostavia viestejä tietämättä, mitä julkaisijoita on olemassa.
Kuvion ymmärtäminen
Tämä saattaa olla aluksi paljon huomioitavaa. En tiedä, mutta puretaan se:
- On olemassa palvelu, meidän tapauksessamme WordPress, joka vastaa viestien julkaisemisesta tilaajalle (se ei välttämättä tiedä kuka kuuntelee).
- Kun tilaaja kuuntelee, se ryhtyy toimiin aina, kun se kuulee sen.
- Kun tilaajan koodi on suoritettu, ohjelma palaa takaisin alkuperäiseen suorituspisteeseen (johon julkaisija lähetti viestin).
Tässä on vivahteita, kuten asynkroninen toiminnallisuus ja muut asiat, mutta se on edistyneempää kuin haluaisin tässä viestissä. Loppujen lopuksi tämän tarkoituksena on luoda pohja toiminnallisuuden ymmärtämiselle ja toteuttamiselle.
Asynkroninen toiminnallisuus voi päästä ketjutukseen tai Ajaxiin ja ne ovat tärkeitä aiheita, tämä ei ole se viesti.
Miltä tämä näyttää WordPressissä?
Ehkä helpoin tapa kuvata tätä tiettyä mallia WordPressissä on käyttää funktiokutsuja:
- do_action
- add_action
Joskus nimikkeistö voi olla hämmentävää, mutta yksinkertaisesti sanottuna do_action publishes ja tapahtuma ja add_action- tilaajat tapahtumaan. Tai ehkä parempi tapa ajatella asiaa on:
do_action käskee WordPressiä suorittamaan kaikki lisätyt toiminnot.
Joskus on hyödyllistä muistaa yksinkertaiset lauseet, joilla asiat toimivat. En tiedä, onko yllä oleva ilmaus tarttuvin vai mieleenpainuvin, mutta se on jotain, eikö?
Huomaa lisäksi, että do_action ja add_action ovat asioita, jotka ovat WordPressin ydin ja ovat myös kehitystyömme käytettävissä. Ennen kuin jatkat, katsotaanpa, mitä kukin tarkoittaa:
Tämä toiminto käynnistää kaikki toimintakoukkuun liittyvät toiminnot
$tag. On mahdollista luoda uusia toimintakoukkuja yksinkertaisesti kutsumalla tätä funktiota ja määrittämällä uuden koukun nimi$tagparametrilla.
Tai vielä yksinkertaisemmin sanottuna:
Suorita toimintoja, jotka on kiinnitetty tiettyyn toimintakoukkuun.
Kun viitataan koukkuihin, ne voivat olla joko WordPressin määrittämiä koukkuja tai mukautettuja koukkuja, jotka määrität teemassasi tai laajennuksessasi.
Mitä tulee add_actioniin :
Toiminnot ovat koukkuja, jotka WordPress-ydin käynnistää tietyissä kohdissa suorituksen aikana tai kun tiettyjä tapahtumia tapahtuu. Lisäosat voivat määrittää, että yksi tai useampi PHP-toiminto suoritetaan näissä kohdissa Action API:n avulla.
Ja vastaavasti yksinkertaisemmin sanottuna:
Kytkee toiminnon tiettyyn toimintoon.
Käytännössä tämän asettaminen on hieman erilainen, koska käytämme yleensä add_action -toimintoa lisätäksemme oman koodimme WordPressiin.
Käytännön esimerkki
Olet ehkä esimerkiksi kirjoittanut jotain tällaista:
<?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;
}
Tässä tapauksessa jossain WordPress-koodikannassa on do_action – kutsu wp_insert_post_data -koukalle ja se hyväksyy funktion ja välittää sille ainakin yhden parametrin.
Omien koukkujen lisääminen
Mutta entä jos haluat antaa muille kehittäjille mahdollisuuden liittyä laajennukseen tai teemaan? Siinä tapauksessa sinun tulee käyttää do_action-toimintoa, ja aiemmin tässä asiakirjassa linkitetty sivu tarjoaa kaiken, mitä tarvitset tämän määrittämiseen.
Se on mielestäni itse asiassa paljon yksinkertaisempaa kuin add_action -toiminnon käyttäminen, koska add_action edellyttää, että emme vain liity olemassa olevaan julkaisijaan, vaan lisäämme oman mukautetun logiikkamme.
do_action toisaalta edellyttää, että annamme suoritettavan funktion nimen ja sitten listan argumenteista, jotka välitetään suoritettavalle funktiolle.
Se siitä?
Suunnilleen niin yksinkertaisilla sanoilla kuin voin tehdä sen, kyllä. Prioriteettiin, argumenttien määrään sekä nimiavaruuksien ja olioohjelmoinnin kanssa työskentelemiseen liittyy joitain vivahteita. Mutta jälleen kerran, se ei kuulu tämän postauksen soveltamisalaan. Ehkä käsittelen sitä tarkemmin jossain toisessa postauksessa.
Mutta toistaiseksi, jos et ole perehtynyt seuraaviin perusasioihin:
- Pub/Sub-malli,
- do_action,
- ja add_action
Olet nyt tarpeeksi mukava lukea käsittelemääsi koodia, ymmärtää koodin toimintaa ja jopa toteuttaa omia ratkaisujasi tarvittaessa.
Kirjoitan tällä hetkellä e-kirjaa (monenlaisen muun premium-sisällön ohella). Jos olet kiinnostunut, katso mitä saat.



