Loetavate WordPressi funktsioonide kirjutamisest

Viimati uuendatud dets. 6, 2022

Sisu

Üks asi, mis mulle pidevalt huvi pakub (nii programmeerimise kui ka WordPressi seisukohast), on järgmine:

Mulle meeldib koodi eraldamine nii, et WordPressiga suhtlemise eest vastutav kood nihutatakse selle nimeruumi, samas kui ülejäänud kood on mujal sobivalt nimeruumi paigutatud.

Ma arvan, et see on siiski ilmne.

Mis aga puutub koodi kirjutamisse, siis see ei tähenda, et see peaks jääma lihtsalt klasside kirjutamise ja seejärel korraldamise otsustada. Kuidas on lood asjadega veidi detailsemal tasemel?

See tähendab, mis siis, kui me vaataksime meetodeid suurema terviku osana ja veenduksime, et ka need teevad oma tööd hästi? Muidugi on sellised inimesed nagu Bob Martin kirjutanud sellistest asjadest suurema osa oma karjäärist ja jutlustanud seda meiesugustele inimestele.

Kuid need kontseptsioonid on midagi, mida te lihtsalt alustate ja seejärel rakendate neid lõplikult. Paradigmad muutuvad, oleme täna paremad kui eile ja sama eesmärgi saavutamiseks võib olla mitu võimalust.

Kui rääkida konkreetse domeeni jaoks loetavate WordPressi funktsioonide loomisest, siis milline see võib välja näha?

Loetavad WordPressi funktsioonid

Neile, kes tunnevad SOLIDi põhimõtteid või kõike, mis räägib hea koodi kirjutamisest, on üks asi, millest paljud neist inimestest kirjutavad, meetodi pikkus.

Ma kipun võtma neid pigem reeglite kui seadusena, sest mõnikord ei saa meetodid nii lühikesed olla. Ma arvan, et nad võiksid, aga mingil hetkel tundub see koodi mikrohaldusena, eks?

Ja teha midagi tegemise pärast, on üks asi, aga teha midagi mõtestatud programmeerimise pärast on teine. Iga kord valin hilisema.

Igatahes, siin on näide: Oletame, et teil on mõni kood, mida kutsutakse Ajaxi kaudu ja enne toiminguga jätkamist peate teadma, kas kohandatud postituse tüüp on olemas.

Sellise tegevuse toimingud võivad olla järgmised:

algatada Ajaxi kõne,
kontrollige turvalisust, et veenduda, et see taotlus on kehtiv,
kontrollige, kas andmed on olemas,
kui jah, saatke eduteade; kui ei, tagastage veateade.

Seda kõike saab kindlasti teha ühe sõnumiga, kuid oletame, et tahame seda kirjutada hõlpsasti loetavate kõnede seeriana, kus kood on teatud määral isedokumenteeruv (see ei tähenda, et ma Olen kommentaaride vastu – ma ei ole üldse, aga see ei tähenda, et me tahame, et meie kood oleks ebaselge, eks?).

Esiteks Ajaxi kõne :

$.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.
});

Seejärel on meil serveri poolel funktsioon turvalisuse otseseks kontrollimiseks (see muidugi eeldab, et olete selle esiotsas õigesti seadistanud):

<?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');
}

Pärast seda tahame kontrollida, kas andmed on olemas:

<?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();
}

Siit edasi saame seejärel töötada Ajaxi vastuseobjektiga, hinnates selle edukust ja reageerides sellele vastavalt.

Minnes sammu edasi

Astume sellest siiski sammu edasi ja ütleme, et tooted on olemas ja me tahame hankida kõik nende postituste ID-d. Seda on WP_Query abil üsna lihtne teha, kuid oletame, et me tahame otse andmebaasiga liidestada.

Pange tähele, et see on pigem harjutus, mille eesmärk on näidata, kuidas midagi teha, selle asemel, et vaielda $wpdb kasutamise üle WP_Query kaudu. See on sisu hoopis teisele postitusele.

Igatahes tegime kindlaks, et andmed on olemas. Haarame siis kõigi postituste ID-de massiivi ja tagastame selle või tühja massiivi. Võib-olla näeks see välja umbes selline:

<?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;
}

Kui väärtused on tagastatud, saame nendega töötada nii, nagu me õigeks peame.

Mis on selle kõige eesmärk?

Üldiselt on see selleks, et aidata meil koodist mõelda nii, et suudaksime lugeda seda peaaegu kirjasõnale võimalikult lähedalt. See tähendab, et saame osutada koodijupile järgmiselt:

Esiteks vaatame, kas midagi on olemas. Kui ei, saadame veateate; vastasel juhul võtame andmed kokku ja töötame siis nende kallal.

Tõsi, ma räägin siin vähem konkreetselt, kuid selle põhjuseks on asjaolu, et ma ei tea tingimata, millega te töötate, rohkem kui minu tööst. Aga saate ideest aru, eks?

Ja lisaks, kui otsite WordPressist lahti ühendatud testikoodi, saate seda teha liideste abil, mis pilkavad funktsioone või isegi käivitavad otsepäringuid andmebaasist ilma WordPressi kasutamata.

Kuid nagu mõnede ülalmainitud punktide puhul, on see teise postituse teema.

Kirjutan praegu e-raamatut (koos mitme muu esmaklassilise sisuga). Kui olete huvitatud, vaadake, mida saate.

: tommcfarlin.com