Om att skriva läsbara WordPress-funktioner

En av de saker som jag alltid tycker är intressant (både ur programmeringssynpunkt och ur WordPress-synpunkt), är detta:

Jag gillar att hålla koden åtskild så att koden som är ansvarig för att interagera med WordPress förpassas till dess namnområde medan resten av vår kod är lämpligt indelad någon annanstans.

Jag tror dock att detta är uppenbart.

När det kommer till att skriva kod betyder det dock inte att det bara måste överlåtas till hur vi skriver våra klasser och sedan organiserar dem. Hur är det med saker på en lite mer detaljerad nivå?

Det vill säga, tänk om vi skulle se på metoder som en del av den större helheten och se till att de också gör sitt jobb bra? Visst, människor som Bob Martin har skrivit om den här typen av saker under större delen av sin karriär och predikat det för människor som oss.

Men dessa begrepp är något som du helt enkelt börjar göra och sedan tillämpar dem för gott. Paradigm skiftar, vi är bättre idag än vi var igår, och det kan finnas flera sätt att uppnå samma typ av sak.

Så när det kommer till att skapa läsbara WordPress-funktioner för en specifik domän, hur kan det se ut?

Läsbara WordPress-funktioner

För dem som är bekanta med SOLID- principerna eller något som talar om att skriva bra kod, är en av de saker som många av de personerna skriver om hur lång en metod ska vara.

Jag tenderar att ta dem som regler snarare än lag, för ibland kan metoder helt enkelt inte vara så korta. Jag menar, jag antar att de skulle kunna, men någon gång känns det som mikrohantering av kod, eller hur?

Och att göra något för att göra något är en sak, men att göra något för en meningsfull programmering är en annan. Jag väljer det senare varje gång.

Hur som helst, så här är ett exempel: Låt oss säga att du har någon kod som anropas via Ajax och innan du fortsätter med operationen måste du veta om det finns en anpassad posttyp.

Stegen för att göra något liknande kan se ut som följer:

• initiera Ajax-samtalet,
• kontrollera säkerheten nonce för att verifiera att det är en giltig begäran,
• kontrollera om data finns,
• om det gör det, returnera ett framgångsmeddelande; Om inte, returnera ett felmeddelande.

Allt detta kan göras inom ett enda meddelande, visst, men låt oss anta att vi vill skriva detta i en serie samtal som är lätta att läsa där koden till viss del är självdokumenterande (det betyder inte att jag Jag är emot kommentarer – det är jag inte alls, men det betyder inte att vi vill att vår kod ska vara otydlig, eller hur?).

Först, Ajax-uppropet :

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

Sedan har vi en funktion på serversidan för att explicit verifiera säkerheten nonce (detta förutsätter naturligtvis att du ställer in den korrekt på front-end):

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

Efter det vill vi kontrollera om data finns:

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

Härifrån kan vi sedan arbeta med Ajax responsobjekt genom att utvärdera dess framgångsegenskap och reagera därefter.

Går ett steg längre

Låt oss dock ta detta ett steg längre och säga att produkter finns och att vi vill hämta alla deras post-ID. Att göra detta med WP_Query är ganska enkelt men låt oss säga, för kickar, vi vill gränssnittet med databasen direkt.

Observera att detta är mer en övning för att visa ett sätt att göra något snarare än att argumentera för att använda $wpdb över WP_Query. Det är innehåll för ett helt annat inlägg.

Hur som helst, så vi har fastställt att data finns. Så låt oss ta en uppsättning av alla inläggs-ID:n och returnera den eller en tom matris. Kanske skulle detta se ut ungefär så här:

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

När värdena har returnerats kan vi sedan operera på dem hur vi finner lämpligt.

Vad är syftet med allt detta?

Generellt sett är det för att hjälpa oss att tänka på kod på ett sådant sätt att vi kan läsa den nästan så nära det skrivna ordet som möjligt. Det vill säga, vi kan peka på en kodbit som att säga:

Först ska vi se om något finns. Om inte, skickar vi ett felmeddelande; annars tar vi tag i data och jobbar sedan med det.

Visst, jag pratar i mindre konkreta termer här, men det beror på att jag inte nödvändigtvis vet vad du jobbar med mer än du vet om mitt arbete. Men du fattar, eller hur?

Och dessutom, om du funderar på att enhetstesta kod som är frikopplad från WordPress, kan detta göras genom att använda gränssnitt som hånar funktionerna eller till och med som kör direkta frågor mot databasen utan att behöva använda WordPress.

Men, som med några av punkterna som nämns ovan, är det ämnet för ett annat inlägg.

Jag håller för närvarande på att skriva en e-bok (tillsammans med en mängd annat premiuminnehåll). Om du är intresserad, kolla in vad du får.