O pisaniu czytelnych funkcji WordPress

Jedną z rzeczy, które są dla mnie niezmiennie interesujące (zarówno z punktu widzenia programowania, jak i z punktu widzenia WordPressa), jest to:

Podoba mi się oddzielanie kodu w taki sposób, że kod odpowiedzialny za interakcję z WordPressem jest przenoszony do jego przestrzeni nazw, podczas gdy reszta naszego kodu ma odpowiednią przestrzeń nazw w innym miejscu.

Myślę, że to jednak oczywiste.

Jeśli chodzi o pisanie kodu, nie oznacza to jednak, że należy pozostawić go po prostu temu, jak piszemy nasze klasy, a następnie je organizujemy. A co z rzeczami na nieco bardziej szczegółowym poziomie?

To znaczy, co by było, gdybyśmy spojrzeli na metody jako część większej całości i upewnili się, że również dobrze wykonują swoją pracę? Jasne, ludzie tacy jak Bob Martin pisali o tego rodzaju rzeczach przez większość swojej kariery i głosili to ludziom takim jak my.

Ale te koncepcje są czymś, co po prostu zaczynasz robić, a następnie stosujesz je na dobre. Zmieniają się paradygmaty, dziś jesteśmy lepsi niż wczoraj i może istnieć wiele sposobów na osiągnięcie tego samego rodzaju.

Więc jeśli chodzi o tworzenie czytelnych funkcji WordPress dla określonej domeny, jak to może wyglądać?

Czytelne funkcje WordPress

Dla tych, którzy znają zasady SOLID lub cokolwiek, co mówi o pisaniu dobrego kodu, jedną z rzeczy, o których pisze wiele z tych osób, jest długość, jaką powinna być metoda.

Zwykle traktuję je jako zasady, a nie prawo, ponieważ czasami metody po prostu nie mogą być tak krótkie. To znaczy, myślę, że mogliby, ale w pewnym momencie wydaje się to jak mikrozarządzanie kodem, prawda?

Robienie czegoś dla samego robienia to jedno, ale robienie czegoś dla sensownego programowania to co innego. Za każdym razem wybiorę później.

W każdym razie, oto przykład: Powiedzmy, że masz jakiś kod, który jest wywoływany przez Ajax i zanim przejdziesz do operacji, musisz wiedzieć, czy istnieje niestandardowy typ postu.

Kroki, aby zrobić coś takiego, mogą wyglądać następująco:

• zainicjować wywołanie Ajax,
• sprawdź bezpieczeństwo nonce, aby upewnić się, że jest to poprawna prośba,
• sprawdź, czy dane istnieją,
• jeśli tak, zwróć komunikat o powodzeniu; jeśli nie, zwróć komunikat o błędzie.

Wszystko to można oczywiście zrobić w jednej wiadomości, ale załóżmy, że chcemy napisać to w serii łatwych do odczytania wywołań, w których kod jest do pewnego stopnia samodokumentujący (nie oznacza to, że Jestem przeciwko komentarzom – wcale nie, ale to nie znaczy, że chcemy, aby nasz kod był niejasny, prawda?).

Najpierw wywołanie Ajaksu :

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

Następnie mamy funkcję po stronie serwera do jawnej weryfikacji nonce bezpieczeństwa (to oczywiście zakłada, że ​​poprawnie konfigurujesz go na interfejsie):

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

Następnie chcemy sprawdzić, czy dane istnieją:

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

Stąd jesteśmy w stanie pracować z obiektem odpowiedzi Ajax, oceniając jego właściwość success i odpowiednio reagując.

Krok dalej

Pójdźmy jednak o krok dalej i powiedzmy, że produkty istnieją i chcemy odzyskać wszystkie ich identyfikatory postów. Robienie tego za pomocą WP_Query jest dość łatwe, ale powiedzmy, dla wykopów, chcemy bezpośrednio połączyć się z bazą danych.

Zauważ, że jest to bardziej ćwiczenie polegające na pokazaniu sposobu na zrobienie czegoś, a nie argumentowaniu za używaniem $wpdb przez WP_Query. To jest treść na cały inny post.

W każdym razie ustaliliśmy, że dane istnieją. Więc weźmy tablicę wszystkich identyfikatorów postów i zwróćmy ją lub pustą tablicę. Być może wyglądałoby to mniej więcej tak:

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

Gdy wartości zostaną zwrócone, możemy na nich operować w dowolny sposób.

Jaki jest cel tego wszystkiego?

Ogólnie rzecz biorąc, ma nam pomóc myśleć o kodzie w taki sposób, abyśmy byli w stanie odczytać go prawie tak blisko słowa pisanego, jak to tylko możliwe. Oznacza to, że jesteśmy w stanie wskazać fragment kodu, jak powiedzmy:

Najpierw zobaczymy, czy coś istnieje. Jeśli nie, wyślemy błąd; w przeciwnym razie przechwycimy dane i będziemy nad nimi pracować.

To prawda, mówię tutaj mniej konkretnie, ale to dlatego, że niekoniecznie wiem, z czym pracujesz, tak samo jak ty o mojej pracy. Ale masz pomysł, prawda?

Co więcej, jeśli szukasz kodu testów jednostkowych, który jest oddzielony od WordPressa, możesz to zrobić za pomocą interfejsów, które symulują funkcje, a nawet uruchamiają bezpośrednie zapytania w bazie danych bez konieczności korzystania z WordPressa.

Ale, podobnie jak w przypadku niektórych punktów wymienionych powyżej, jest to temat na inny post.

Obecnie piszę e-booka (wraz z wieloma innymi treściami premium). Jeśli jesteś zainteresowany, sprawdź co otrzymujesz.