Luettavien WordPress-toimintojen kirjoittamisesta

Viimeisin päivitys joulu 6, 2022

Sisältö

Yksi asia, jota pidän jatkuvasti mielenkiintoisena (sekä ohjelmoinnin että WordPressin näkökulmasta), on tämä:

Pidän koodin pitämisestä erillään siten, että WordPressin kanssa vuorovaikutuksesta vastaava koodi siirretään sen nimiavaruuteen, kun taas muu koodimme on nimiavaroitu asianmukaisesti muualle.

Mielestäni tämä on kuitenkin ilmeistä.

Mitä tulee koodin kirjoittamiseen, tämä ei kuitenkaan tarkoita, että se on jätettävä yksinkertaisesti siihen, miten kirjoitamme ja organisoimme ne. Entä asiat hieman yksityiskohtaisemmalla tasolla?

Eli entä jos katsoisimme menetelmiä osana suurempaa kokonaisuutta ja varmistaisimme, että nekin tekevät työnsä hyvin? Toki Bob Martinin kaltaiset ihmiset ovat kirjoittaneet tällaisista asioista suurimman osan urastaan ja saarnaaneet sitä kaltaisillemme ihmisille.

Mutta nämä käsitteet ovat jotain, mitä vain alat tehdä ja sitten soveltaa niitä lopullisesti. Paradigmat muuttuvat, olemme tänään parempia kuin eilen, ja voi olla useita tapoja saavuttaa samanlainen asia.

Joten kun on kyse luettavien WordPress-toimintojen luomisesta tietylle verkkotunnukselle, miltä se voisi näyttää?

Luettavat WordPress-toiminnot

Niille, jotka tuntevat SOLID – periaatteet tai kaikki, mikä puhuu hyvän koodin kirjoittamisesta, yksi niistä asioista, joista monet kirjoittavat, on menetelmän pituus.

Minulla on tapana ottaa ne sääntöinä enkä lakina, koska joskus menetelmät eivät vain voi olla niin lyhyitä. Tarkoitan, että he voisivat, mutta jossain vaiheessa se tuntuu koodin mikrohallinnolta, eikö?

Ja tehdä jotain tekemisen vuoksi on yksi asia, mutta tehdä jotain mielekkään ohjelmoinnin vuoksi on toinen. Valitsen joka kerta myöhemmin.

Joka tapauksessa, tässä on esimerkki: Oletetaan, että sinulla on jokin koodi, jota kutsutaan Ajaxin kautta, ja ennen kuin jatkat toimintoa, sinun on tiedettävä, onko mukautettua viestityyppiä olemassa.

Tämänkaltaisen tekemisen vaiheet voivat mennä seuraavasti:

aloittaa Ajax-puhelun,
tarkista suojaus varmistaaksesi, että se on kelvollinen pyyntö,
tarkista, onko tietoja olemassa,
jos on, palauta onnistumisviesti; jos ei, palauta virheilmoitus.

Kaikki tämä voidaan tehdä yhdessä viestissä, toki, mutta oletetaan, että haluamme kirjoittaa tämän sarjassa helposti luettavia kutsuja, joissa koodi on jossain määrin itsedokumentoiva (tämä ei tarkoita sitä, että Vastustan kommentteja – en ollenkaan, mutta se ei tarkoita, että haluamme koodimme olevan epäselvä, vai mitä?).

Ensinnäkin Ajax-puhelu :

$.get(ajaxurl, {
    'action': 'getDetails',
    'security': $('input[name="acme-security-nonce"]').val()
}, function(response) {
    if (false === response.success) {
        // Handle the case when the request wasn't successful.
    }

    // Work with the information that was returned in the response.data property.
});

Sitten meillä on palvelinpuolella toiminto, jolla varmistetaan nimenomaisesti suojaus (tämä tietysti edellyttää, että olet määrittänyt sen oikein käyttöliittymässä):

<?php
/**
 * @return bool true if we're able to make Ajax requests; otherwise, false
 */
private function verifyRequest()
{
    return
        isset($_GET['security']) &&
        wp_verify_nonce(strip_tags(stripslashes($_GET['security'])), 'getDetails');
}

Tämän jälkeen haluamme tarkistaa, onko tietoja olemassa:

<?php

/**
 * @return bool true if there are details; false, otherwise
 *
 * @access private
 */
private function doDetailsExist()
{
    return (new WP_Query([
        'post_type' => 'acme_post_type',
        'post_status' => 'publish',
    ]))->have_posts();
}

Tästä eteenpäin voimme työskennellä Ajax-vastausobjektin kanssa arvioimalla sen onnistumisominaisuuden ja reagoimalla sen mukaisesti.

Askeleen pidemmälle

Otetaan tämä kuitenkin askel pidemmälle ja sanotaan, että tuotteita on olemassa ja haluamme noutaa kaikki niiden viestitunnukset. Tämän tekeminen WP_Queryn avulla on melko helppoa, mutta sanotaanpa, että haluamme olla suoraan yhteydessä tietokantaan.

Huomaa, että tämä on pikemminkin harjoitus, jossa näytetään tapa tehdä jotain sen sijaan, että väittelet $wpdb :n käytöstä WP_Queryn kanssa. Siinä sisältöä aivan toiseen postaukseen.

Joka tapauksessa olemme päättäneet, että dataa on olemassa. Tartutaan siis joukkoon kaikista viestitunnuksista ja palautetaan se tai tyhjä taulukko. Ehkä tämä näyttäisi jotakuinkin tältä:

<?php
/**
 * @return array a numerically indexed array of all detail IDs
*/
private function getDetailIds(): array
{
    global $wpdb;
    $results = $wpdb->get_results(
        $wpdb->prepare("
        SELECT meta_value
        FROM $wpdb->postmeta
        WHERE meta_key = %s
        ORDER BY meta_value ASC
        ", 'acme_detail_number'),
        ARRAY_N
    );

    $detailIds = [];
    array_push($detailIds, array_map(function ($result) {
        return $result[0];
    }, $results));

    return $detailIds[0] ?? $detailIds;
}

Kun arvot on palautettu, voimme käyttää niitä haluamallamme tavalla.

Mikä on tämän kaiken tarkoitus?

Yleisesti ottaen sen tarkoituksena on auttaa meitä ajattelemaan koodia siten, että pystymme lukemaan sen melkein mahdollisimman lähellä kirjoitettua sanaa. Eli voimme osoittaa koodinpätkälle sanomalla:

Ensin katsotaan, onko jotain olemassa. Jos ei, lähetämme virheilmoituksen. muussa tapauksessa nappaamme tiedot ja käsittelemme niitä.

Myönnettäköön, että puhun tässä vähemmän konkreettisesti, mutta se johtuu siitä, etten välttämättä tiedä, minkä kanssa työskentelet, sen enempää kuin tiedät työstäni. Mutta ymmärrät idean, eikö?

Ja lisäksi, jos haluat yksikkötestikoodin, joka on irrotettu WordPressistä, se voidaan tehdä käyttämällä rajapintoja, jotka pilkkaavat toimintoja tai jopa suorittavat suoria kyselyitä tietokannasta ilman, että tarvitset käyttää WordPressiä.

Mutta kuten joidenkin edellä mainittujen seikkojen kohdalla, se on toisen postauksen aihe.

Kirjoitan tällä hetkellä e-kirjaa (monenlaisen muun premium-sisällön ohella). Jos olet kiinnostunut, katso mitä saat.

: tommcfarlin.com