Mukautettujen mallien sisällyttäminen WordPress-laajennuksiin

Mielestäni yksi aliarvostetuimmista näkökohdista – tai ehkä yksi harvoin käsitellyistä mukautettujen laajennusten kehittämisen näkökohdista – on kyky sisällyttää mukautettuja malleja WordPress-laajennuksiin.

Ja ollakseni rehellinen, ymmärrän sen: olen aika vankka sen suhteen, minkä laajennuksen pitäisi olla ja mikä teema.

Tuo on:

• teemat ovat esittelyä varten,
• laajennukset ovat toimintoja.

Jos sisällytän malleja laajennukseen, enkö tee samaa kuin silloin, kun kehittäjät sisällyttävät toimintoja teemoihinsa?

Kuten monen muunkin kehitystyön kohdalla, mielestäni se riippuu. Tarkoitan, että en ole fani, jos lisäät paljon toimintoja, jotka lukitsevat sinut teemaan. Vastaavasti, jos sinulla on laajennus, joka on tarkoitettu esittelemään tietoja käyttöliittymässä ja joka on teemaagnostikko, se on järkevää.

Joten sinun on oltava harkittuja päätöksissäsi.

Siitä huolimatta voimme käyttää yleisiä vaiheita sisällyttäessämme mukautettuja malleja WordPress-laajennuksiin.

Ja sen tämä postaus tulee näyttämään.

Jos aiot sisällyttää laajennukseen mukautettuja malleja, oletan, että käytät sekä yksittäisiä että arkistomalleja. Jos ei, käytä vain alla olevia koukkuja ja koodia, joita tarvitset.

Molemmille, mutta tiedä nämä:

• yksi_malli
• archive_template

Näiden koukkujen avulla voit kertoa WordPressille, missä mukautetut mallit ovat laajennuksessasi.

Mallien järjestäminen

Minulla on yleensä  laajennuksessani mallihakemisto, joka sijaitsee samalla tasolla kuin omaisuus-, src- ja toimittajahakemistot.

Tämän ansiosta on helppo tietää, missä ne sijaitsevat, ja tarjoaa johdonmukaisen tavan sisällyttää ne kaikkiin rakentamiisi laajennuksiin. Loppujen lopuksi käyttämiemme käytäntöjen johdonmukaisuudesta on sanottavaa.

Mallit mukaan lukien

Olettaen, että sinulla on single-acme.php- ja archive-acme.php- malli, se on helppo sisällyttää. Ja vaikka olen enemmän olio-ohjelmoinnin fani, näytän, että sisällytän nämä mallit prosessikoodin avulla.

Tämä koodi on helppo muuntaa oliopohjaiseksi koodiksi, jos haluat. Lisäksi oletan, että sisällytät tämän myös mukautetuille viestityypeille.

Voit aina jättää pois ehdollisen muokatun viestityypin, jos haluat yksinkertaisesti sisällyttää nämä mallit, mutta kokemukseni mukaan on harvinaista, että näissä tilanteissa ei käytetä mukautettuja viestityyppejä, mutta en tiedä tilannettasi.

Se sanoi, tässä on koodi.

Koukkujen määrittely

Ensinnäkin meidän on määritettävä koukut. Tämä on suhteellisen yksinkertaista, koska aiomme käyttää yllä kuvattuja koukkuja.

Ensinnäkin yksi malli :

<?php

add_action('single_template', 'acmeIncludeSingleTemplate');
/**
 * Includes a custom, single template as included in a plugin. If
 * the template is being viewed for a custom post type then use it;
 * otherwise, use the template that's provided by WordPress at runtime.
 *
 * @param  string $originalTemplate the path to the original template
 *
 * @return string the path to the original template or the custom template.
 */
function acmeIncludeSingleTemplate($originalTemplate)
{
   // More to come...
}

Ja sitten arkistomalli :

<?php

add_action('archive_template', 'acmeIncludeArchiveTemplate');
/**
 * Includes a custom, archive template as included in a plugin. If
 * the template is being viewed for a custom post type then use it;
 * otherwise, use the template that's provided by WordPress at runtime.
 *
 * @param  string $originalArchiveTemplate the path to the original template
 *
 * @return string the path to the original template or the custom template.
 */
function acmeIncludeArchiveTemplate($originalArchiveTemplate)
{
  // More to come...
}

Ja nyt voimme toteuttaa koodin jokaiselle toiminnolle.

Koodin lisääminen

Joten ensin tarkastellaan yksittäistä mallia :

<?php

add_action('single_template', 'acmeIncludeSingleTemplate');
/**
 * Includes a custom, single template as included in a plugin. If
 * the template is being viewed for a custom post type then use it;
 * otherwise, use the template that's provided by WordPress at runtime.
 *
 * @param  string $originalTemplate the path to the original template
 *
 * @return string the path to the original template or the custom template.
 */
function acmeIncludeSingleTemplate($originalTemplate)
{
  $singleTemplate = plugin_dir_path(
    dirname(
      __DIR__) );
  $singleTemplate .= '/templates/single-acme.php';

  if ('acme-cpt' === get_post_type(get_the_ID())) {
      if (file_exists($singleTemplate)) {
          return $singleTemplate;
      }
  }

  return $originalTemplate;
}

Ja nyt arkistomalli :

<?php

add_action('archive_template', 'acmeIncludeArchiveTemplate');
/**
 * Includes a custom, archive template as included in a plugin. If
 * the template is being viewed for a custom post type then use it;
 * otherwise, use the template that's provided by WordPress at runtime.
 *
 * @param  string $originalArchiveTemplate the path to the original template
 *
 * @return string the path to the original template or the custom template.
 */
function acmeIncludeArchiveTemplate($originalArchiveTemplate)
{
  $archiveTemplate = plugin_dir_path(
    dirname(
      __DIR__) );
  $archiveTemplate .= '/templates/archive-acme.php';

  if ('acme-cpt' === get_post_type(get_the_ID())) {
      if (file_exists($archiveTemplate)) {
          return $archiveTemplate;
      }
  }

  return $originalArchiveTemplate;
}

Jos olet kiinnittänyt huomiota koodiin, tiedät, että siinä on hyvin vähän eroja. Itse asiassa yleinen prosessi voidaan hahmotella seuraavasti:

1. määrittele koukku,
2. etsi malli,
3. tarkista mukautettu viestityyppi,
4. malli on olemassa, käytä sitä
5. muussa tapauksessa käytä oletusmallia

Tämä on prosessi sekä yksittäisille että arkistomalleille.

Yhteensopivien mallien kirjoittaminen

Ja lopuksi, ja tämä on tärkeää varsinkin, jos haluat tehdä mallista mahdollisimman agnostisen, yritän käyttää mahdollisimman monia sisäänrakennettuja WordPress-mallitunnisteita, kun näytän laajennukseen liittyvää sisältöä. Tämän ansiosta teeman kehittäjät voivat helposti muokata sitä teemaansa sopivaksi.

Ei, et voi majoittaa jokaista teemaa, mutta sellainen on WordPress-teemojen luonne. Tarkoituksena on tehdä mahdollisimman paljon työtä tietojen hakemiseen ja hahmontamiseen mallista, jotta käyttöliittymäkehittäjät voivat helposti hallita sitä.