Suurin osa tällä hetkellä tekemästäni työstä keskittyy mukautettuihin laajennuksiin tai apuohjelmiin, jotka toimivat WordPressin päällä.
Jos käsittelisit kuinka monta rakentamistani projekteista on koottu, tarkastelisit WordPressin (ja kaiken sen sisältämän) perustana, ja sitten koodissa on kerros, joka kommunikoi WordPressin kanssa ja joka saattaa kommunikoida. kolmannen osapuolen sovellusliittymien kanssa.
Tätä tehtäessä on kuitenkin usein käyttöliittymäkomponentti, joka edellyttää tietojen muuntamista malleiksi. Vaikka WordPressin mallien luominen ei ole luonnostaan vaikeita (vaikka toivoisin, että meillä olisi enemmän kuin mallitunnisteita – kuten mallimoottori, se on toinen viesti), mielestäni kannattaa tarkastella paria tapaa, joilla voimme käsitellä mukautettuja malleja, jotka niputimme lisäosien kanssa.
Yksi ensimmäisistä kysymyksistä, joka usein herää tämän lausunnon yhteydessä, on kuitenkin
Miksi sisällytät mukautettuja malleja laajennukseen?
Ja ymmärrän sen jollain tasolla.
- Mallien pitäminen laajennuksessa hämärtää hieman teemojen ja laajennusten välisiä rajoja varsinkin kun jätät teemoja esittelyyn ja laajennuksia liiketoimintalogiikkaan,
- Käyttäjien pyytäminen kopioimaan teematiedostoja paikasta toiseen on huono käyttökokemus.
Mutta yllä oleviin tapauksiin on olemassa joitain vastalauseita tai kenties suoria poikkeuksia.
WordPress template_redirect -koukku
Ennen kuin puhun WordPress template_redirect -koukusta, haluan puhua hieman edellä mainituista kohdista.
1 Mallit laajennuksissa
Jos olet rakentamassa mukautettua laajennusta, joka on käyttöliittymä sekä WordPressin että kolmannen osapuolen API:n kanssa tai joka käyttää jonkin tyyppistä tietovarastojen, tehtaiden, mallien ja näkymien yhdistelmää, sinun on näytettävä nämä tiedot etupuolella. -loppu, ja sen on oltava teemaagnostikko.
Tämä ei tarkoita, että joku ei voisi tyylittää sivun elementtejä tai sisällyttää mallia työhönsä, mutta se tarkoittaa, että laajennuksen tulee tarjota käyttäjälle hahmonnettavia perustietoja.
2 Käyttäjien pyytäminen kopioimaan tiedostoja on väärin
Muista slogan, jota Apple mainosti kerran ja usein nimellä " Se vain toimii? Vaikka se ei ehkä olekaan asia, jota he huusivat niin paljon kuin ennen (jos ollenkaan, enää), pidän ajatuksesta, että käyttäjälle on "vain työtä", ja se on jotain, johon yritän pyrkiä työ.
Joten kun on kyse mukautettujen mallien tai näkymien luomisesta laajennuksille, en halua pyytää käyttäjää kopioimaan tiedostoja. Haluan heidän vain:
- asenna laajennus,
- napsauta aktivoida.
Ja siinä se. Loput tulee olla joko itsestään selviä tai hyvin dokumentoituja.
Takaisin Koukkuun
Okei, oletetaan hetkeksi, että olemme rakentaneet laajennuksen, joka sisältää useita perusmalleja (tai näkymiä käyttämästäsi kielestä riippuen) ja että mallit on kirjoitettava aktiivisen teeman hakemiston juureen.
Voit käyttää template_redirect – koukkua (ja monet suositut laajennukset tekevät niin). Voit lukea siitä lisää täältä, mutta sen ydin on seuraava:
Tämä toimintokoukku suoritetaan juuri ennen kuin WordPress määrittää, mikä mallisivu ladataan. Se on hyvä koukku käytettäväksi, jos sinun on tehtävä uudelleenohjaus täysin tietäen kyselyn kohteena olevasta sisällöstä.
Ja selvyyden vuoksi, en estä tämän koukun käyttöä. Tarjoan vain vaihtoehdon. Ja se on tämä (kuten sen pitäisi toimia seuraavasti):
- aktivoi plugin,
- etsi aktiivinen teema,
- Jos niitä ei vielä ole, kopioi mallitiedostot laajennuksesta aktiivisen teeman juurihakemistoon
Viimeinen vaihe on kriittinen, koska jos mallitiedostot ovat olemassa, on tärkeää, että niitä ei korvata ensisijaisesti siksi, että käyttäjä olisi voinut kirjoittaa mukautuksensa.
Näin voit tehdä sen yhdellä toiminnolla (täydennettynä kommenteilla, jotka osoittavat, mitä käytät).
<?php
add_action('plugins_loaded', __NAMESPACE__. 'acmeCopyTemplates');
/**
* Copies the template files from the `assets/templates` directory to the root directory
* of the currently active theme (if they do not already exist).
*/
function acmeCopyTemplates()
{
// Find the currently active theme.
$activeThemeDir = get_template_directory();
/**
* Read all of the template files from assets/templates into an array but
* exclude the '.' and the '..' from the array.
*/
$templates = array_slice(scandir(dirname(__FILE__).'/assets/templates'), 2);
/**
* Now copy all of these files to the active theme directory.
* If the file already exists, then don't do it.
*/
foreach ($templates as $template) {
if (!file_exists($destination = trailingslashit($activeThemeDir).$template)) {
continue;
}
$source = dirname(__FILE__).'/assets/templates/'.$template;
$destination = trailingslashit($activeThemeDir).$template;
copy($source, $destination);
}
}
Huomaa, että tämä käyttää useita PHP-toimintoja. Nimittäin:
Kaikki ne ovat mielestäni käteviä ja tärkeitä tietää riippumatta luonteesta, jossa käytät niitä.
Tukevatko isännät tätä?
Jotkut isännät tekevät. Tiedän varsinaisesti, että WPEnginen kaltaiset isännät eivät sitä tee, eikä tämäkään ole isäntäkritiikkiä. Jotkut tekevät sen turvallisuussyistä; toiset sallivat sen, mutta se ei tarkoita, että he ovat vähemmän turvallisia – se tarkoittaa vain, että heidän infrastruktuurinsa on määritetty eri tavalla.
Viime kädessä tämä osoittaa, että on olemassa muita tapoja saada malleja käyttäjien saataville, kun laajennusta käytetään, mutta se ei ole ainoa tapa, eikä se välttämättä aina toimi.
Vaihtoehdot on kuitenkin hyvä, varsinkin jos haluat tietyn laajennuksen arkkitehtuurin toisen sijaan.