WordPress-mallit aloittelijoille: miten se on

Viimeisin päivitys marras 9, 2022

Sisältö

2 Saako kehittäjäorganisaatio suorituskykyä?

Kun aloin miettiä mallien luomista WordPressissä, ajattelin kahta asiaa:

sisältöä erityisesti jäsenille ,
sisältöä, joka voi hajota yhdeksi viestiksi.

Mutta mitä enemmän ajattelin sitä, sitä enemmän ymmärsin, että se voitaisiin (ja luultavasti pitäisi) selittää muutaman viestin aikana.

Joten aion purkaa WordPress-mallien nykytilan ja sitten käytännön tapoja, joilla voimme järjestää esimerkiksi laajennukset niin, että käytämme tavallista PHP:tä.

Sen jälkeen katson seuraavassa sarjassa, mitä tarkoittaa muiden mallinnuskoneiden käyttö (sekä PHP:n että JavaScriptin työssä).

Aluksi haluan kuitenkin katsoa, kuinka usein näemme malleja, jotka on kirjoitettu sekä WordPress-teemojen että laajennusten yhteydessä.

WordPress-malleja aloittelijoille

Riippuen kokemuksestasi WordPressistä ja muista PHP-pohjaisista järjestelmistä, sinun mallipohjasi määritelmä on erilainen kuin jonkun muun.

Joten yrittääkseni luoda yhteisen määritelmän, jota käytän tässä viestisarjassa, käytetään WordPress Codexista:

Mallit ovat tiedostoja, jotka säätelevät, miten WordPress-sivustosi näytetään verkossa.

Sivulla kerrotaan edelleen, kuinka se toimii yhdessä tietokannan ja muiden resurssien kanssa, ja suosittelen lukemaan siitä, jos et ole perehtynyt siihen.

Yllä oleva määritelmä toimii kuitenkin hyvin siihen, miten aion edetä ajattelussani.

1 Miten se on (tällä hetkellä)

Mitä tulee WordPress-mallien ajatteluun, mielestäni on hyödyllistä harkita yhtä mallia, jonka koodi näyttää tältä:

<div id="content-container">

  <p>
    Oh! The garbage chute was a really wonderful idea. What an incredible smell you've discovered! Let's get out of here! 
    Get away from there... No! wait! Will you forget it? I already tried it. It's magnetically sealed! Put that 
    thing away! You're going to get us all killed.
  </p>

  <h2>List of Post Titles For Acme Post Type</h2>
  <?php
  $args = array(
    'post_status'    => 'publish',
    'post_type'      => 'acme',
    'posts_per_page' => '10'
  );
  $custom_query = new WP_Query( $args );

  if ($custom_query->have_posts()) {
    echo '<ul>';
    while ($custom_query->have_posts()) {
      $custom_query->the_post();
      echo '<li>'. get_the_title(). '</li>';
    }
    echo '</ul>';
    wp_reset_postdata();
  }
  ?>

  <p>
    Absolutely, Your Worship. Look, I had everything under control until you led us down here. You know, it's not 
    going to take them long to figure out what happened to us. It could be worst... It's worst. 
    There's something alive in here! That's your imagination. Something just moves past my leg! 
    Look! Did you see that? What? Help!
  </p>

</div><!-- #content-container -->

Yllä olevan koodin pointti on, että näet, että siinä sekoitetaan PHP ja HTML.

Lisäksi on tärkeää huomata, että jokainen näistä tiedostoista on tyylitelty CSS:n avulla ja että niiden toimintaa voi ohjata JavaScriptin avulla. Tätä varten voit kuvitella sen seuraavasti:

Tämä edustaa yhtä mallia, joka sekoittaa sekä HTML:n että PHP:n yhdeksi malliksi. Ja tämä malli muotoillaan sitten CSS:llä ja ohjataan JavaScriptillä.

Kaikki nämä toimivat yhdessä ja tarjoavat sen, mitä käyttäjä näkee.

2 Saako kehittäjäorganisaatio suorituskykyä?

Mutta tapa, jolla tämä toimii, on tavallaan sotkuinen, ja vaikka se saattaa näyttää hyvältä käyttäjälle, se herättää kysymyksiä:

Onko se niin suorituskykyinen kuin se voi olla?
Kuinka helppoa on kehittäjän ylläpitää?
Mikä on rakennusprosessi?
miten omaisuutta ylläpidetään ja järjestetään?

Toki suurin osa yllä luetusta on hyvin kehittäjäkeskeistä, mutta huomaan, että kun koodi on järjestetty siten, että kehittäjien on helppo työskennellä sen kanssa, se voi usein olla helppoa jopa nopeampaa käyttäjälle.

Mitä se kuitenkin tarkoittaa?

Esittelemmekö Sassin?
Pienennämmekö JavaScriptiä?
Kuinka yhdistämme nämä varat ja tuomme ne?
Entä mukautetut PHP-kyselyt, jotka tapahtuvat kunkin mallin yhteydessä?

Ja vaikka ensimmäiset asiat ovat tärkeitä ja sen arvoisia (ja saatan käsitellä sarjassa tämän jälkeen), logiikan erottaminen mallin sisältä jopa ilman mallimoottoria voi auttaa tekemään koodista kehittäjäkeskeisemmän.

Nopeuttaako se asioita käyttäjän kannalta? Ei välttämättä. Mutta se auttaa meitä ottamaan ensimmäisen askeleen juuri siinä.

Järjestetään uudelleen

Tämän sarjan seuraavassa postauksessa puran esimerkin kautta sisältöön, jota olemme tottuneet näkemään WordPress-malleissa, ja alan organisoida sitä uudelleen niin, että se on paremmin organisoitu siten, että tekniikoita voidaan käyttää eri projekteissa.

Tämä tarkoittaa asioiden siirtämistä toimintoihinsa (tai jopa luokkiinsa ja siten toimintoihinsa) ja siihen, kuinka voimme kutsua niitä malliemme kontekstista.

Viime kädessä tämä johtaa koodiin, joka on helpompi lukea, erottelee huolenaiheet paremmin ja vie meidät kohti tapoja muuttaa tapaa, jolla tiedot lisätään malliin.

: tommcfarlin.com