О написании читаемых функций WordPress

Одна из вещей, которые я нахожу неизменно интересными (как с точки зрения программирования, так и с точки зрения WordPress), заключается в следующем:

Мне нравится разделять код таким образом, чтобы код, отвечающий за взаимодействие с WordPress, относился к его пространству имен, а остальная часть нашего кода соответствующим образом размещалась в другом месте.

Хотя, думаю, это очевидно.

Однако когда дело доходит до написания кода, это не означает, что его нужно оставить просто тому, как мы пишем наши классы, а затем организуем их. Как насчет вещей на несколько более детальном уровне?

То есть, что если бы мы рассматривали методы как часть большего целого и удостоверялись, что они тоже хорошо выполняют свою работу? Конечно, такие люди, как Боб Мартин, писали об этом большую часть своей карьеры и проповедовали это таким людям, как мы.

Но эти концепции — это то, что вы просто начинаете делать, а затем применяете их навсегда. Парадигмы меняются, сегодня мы лучше, чем были вчера, и может быть несколько способов добиться того же самого.

Итак, когда дело доходит до создания удобочитаемых функций WordPress для определенного домена, как это может выглядеть?

Читаемые функции WordPress

Для тех, кто знаком с принципами SOLID или чем-либо, что говорит о написании хорошего кода, одна из вещей, о которых пишут многие из этих людей, — это длина, которой должен быть метод.

Я склонен воспринимать их как правила, а не как закон, потому что иногда методы просто не могут быть такими короткими. Я имею в виду, я думаю, они могли бы, но в какой-то момент это похоже на микроуправление кодом, верно?

И делать что-то ради дела — это одно, а делать что-то ради осмысленного программирования — совсем другое. Я буду выбирать позже каждый раз.

В любом случае, вот пример: допустим, у вас есть код, который вызывается через Ajax, и прежде чем приступить к операции, вам нужно знать, существует ли пользовательский тип записи.

Шаги для выполнения чего-то подобного могут быть следующими:

• инициировать вызов Ajax,
• проверьте одноразовый номер безопасности, чтобы убедиться, что это действительный запрос,
• проверить, существуют ли данные,
• если это так, то вернуть сообщение об успехе; если нет, вернуть сообщение об ошибке.

Конечно, все это можно сделать в одном сообщении, но давайте предположим, что мы хотим написать это в виде серии вызовов, которые легко читать, а код в определенной степени самодокументируется (это не значит, что я я против комментариев — совсем нет, но это не значит, что мы хотим, чтобы наш код был непонятным, не так ли?).

Во- первых, вызов Ajax :

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

Затем у нас есть функция на стороне сервера для явной проверки одноразового номера безопасности (это, конечно, предполагает, что вы правильно настраиваете его на внешнем интерфейсе):

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

После этого мы хотим проверить, существуют ли данные:

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

Отсюда мы можем работать с объектом ответа Ajax, оценивая его свойство успеха и реагируя соответствующим образом.

Шаг вперед

Давайте сделаем еще один шаг и скажем, что продукты существуют, и мы хотим получить все их идентификаторы сообщений. Сделать это с помощью WP_Query довольно просто, но, скажем, для удовольствия, мы хотим напрямую взаимодействовать с базой данных.

Обратите внимание, что это больше похоже на демонстрацию того, как что-то сделать, а не на аргументы в пользу использования $wpdb вместо WP_Query. Это содержание для целого другого поста.

В любом случае, мы определили, что данные существуют. Итак, давайте возьмем массив всех идентификаторов сообщений и вернем его или пустой массив. Возможно, это будет выглядеть примерно так:

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

После того, как значения возвращены, мы можем работать с ними так, как считаем нужным.

Какова цель всего этого?

Вообще говоря, это помогает нам думать о коде таким образом, чтобы мы могли читать его как можно ближе к написанному слову. То есть мы можем указать на кусок кода, например:

Во-первых, мы посмотрим, существует ли что-то. Если нет, мы отправим сообщение об ошибке; в противном случае мы получим данные, а затем обработаем их.

Конечно, здесь я говорю менее конкретно, но это потому, что я не обязательно знаю, с чем вы работаете, не больше, чем вы знаете о моей работе. Но вы поняли идею, верно?

И, кроме того, если вы ищете код модульного тестирования, отделенный от WordPress, это можно сделать с помощью интерфейсов, которые имитируют функции или даже запускают прямые запросы к базе данных без необходимости использования WordPress.

Но, как и в случае с некоторыми пунктами, упомянутыми выше, это тема для отдельного поста.

В настоящее время я пишу электронную книгу (наряду с другим премиальным контентом). Если вам интересно, посмотрите, что вы получите.