Sur l’écriture de fonctions WordPress lisibles

L’une des choses que je trouve toujours intéressantes (à la fois du point de vue de la programmation et du point de vue de WordPress), est la suivante :

J’aime garder le code séparé de sorte que le code responsable de l’interaction avec WordPress soit relégué à son espace de noms tandis que le reste de notre code est placé de manière appropriée ailleurs.

Je pense que c’est pourtant évident .

Quand il s’agit d’écrire du code, cependant, cela ne veut pas dire qu’il faut se contenter de la façon dont nous écrivons nos classes et les organisons ensuite. Qu’en est-il des choses à un niveau légèrement plus granulaire ?

Autrement dit, que se passerait-il si nous devions considérer les méthodes comme faisant partie d’un ensemble plus large et nous assurer qu’elles font également bien leur travail ? Bien sûr, des gens comme Bob Martin ont écrit sur ce genre de choses pendant la majeure partie de leur carrière et l’ont prêché à des gens comme nous.

Mais ces concepts sont quelque chose que vous commencez simplement à faire et que vous les appliquez ensuite pour de bon. Les paradigmes changent, nous sommes meilleurs aujourd’hui qu’hier, et il peut y avoir plusieurs façons de réaliser le même genre de chose.

Ainsi, lorsqu’il s’agit de créer des fonctions WordPress lisibles pour un domaine spécifique, à quoi cela pourrait-il ressembler ?

Fonctions WordPress lisibles

Pour ceux qui connaissent les principes SOLID ou tout ce qui parle d’écrire un bon code, l’une des choses sur lesquelles beaucoup de ces gens écrivent est la longueur à laquelle une méthode devrait être.

J’ai tendance à les considérer comme des règles plutôt que comme des lois parce que parfois, les méthodes ne peuvent pas être aussi courtes. Je veux dire, je suppose qu’ils le pourraient, mais à un moment donné, cela ressemble à de la microgestion de code, non ?

Et faire quelque chose pour le plaisir de faire est une chose, mais faire quelque chose pour le plaisir d’une programmation significative en est une autre. Je choisirai le plus tard à chaque fois.

Quoi qu’il en soit, voici un exemple : disons que vous avez du code appelé via Ajax et avant de poursuivre l’opération, vous devez savoir si un type de publication personnalisé existe.

Les étapes pour faire quelque chose comme ça pourraient aller comme suit :

• lancer l’appel Ajax,
• vérifier la sécurité nonce pour vérifier qu’il s’agit d’une demande valide,
• vérifier si des données existent,
• si c’est le cas, renvoie un message de réussite ; sinon, renvoie un message d’erreur.

Tout cela peut être fait dans un seul message, bien sûr, mais supposons que nous voulions écrire cela dans une série d’appels faciles à lire où le code s’auto-documente, dans une certaine mesure (cela ne veut pas dire que je Je suis contre les commentaires – je ne le suis pas du tout, mais cela ne veut pas dire que nous voulons que notre code ne soit pas clair, n’est-ce pas ?).

Tout d’abord, l’appel 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.
});

Ensuite, nous avons une fonction côté serveur pour vérifier explicitement le nonce de sécurité (ceci, bien sûr, suppose que vous le configurez correctement sur le 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');
}

Après cela, nous voulons vérifier si les données existent :

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

À partir de là, nous sommes alors en mesure de travailler avec l’objet de réponse Ajax en évaluant sa propriété de succès et en réagissant en conséquence.

Aller plus loin

Allons un peu plus loin et disons que les produits existent et que nous voulons récupérer tous leurs identifiants de publication. Faire cela avec WP_Query est assez facile mais disons, pour le plaisir, nous voulons nous interfacer directement avec la base de données.

Notez qu’il s’agit davantage d’un exercice visant à montrer une manière de faire quelque chose plutôt que de plaider en faveur de l’utilisation de $wpdb sur WP_Query. C’est le contenu d’un tout autre article.

Quoi qu’il en soit, nous avons donc déterminé que les données existent. Prenons donc un tableau de tous les ID de publication et renvoyons-le ou un tableau vide. Cela ressemblerait peut-être à ceci :

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

Une fois les valeurs retournées, nous pouvons alors les opérer comme bon nous semble.

Quel est le but de tout cela ?

D’une manière générale, c’est pour nous aider à penser au code de telle manière que nous soyons capables de le lire presque aussi près que possible du mot écrit. C’est-à-dire que nous pouvons pointer vers un morceau de code comme par exemple :

D’abord, nous allons voir si quelque chose existe. Sinon, nous enverrons une erreur ; sinon, nous allons récupérer les données et ensuite travailler dessus.

Certes, je parle en termes moins concrets ici, mais c’est parce que je ne sais pas nécessairement sur quoi vous travaillez, pas plus que vous ne savez sur mon travail. Mais vous voyez l’idée, n’est-ce pas ?

Et de plus, si vous cherchez un code de test unitaire découplé de WordPress, cela peut être fait grâce à l’utilisation d’interfaces qui simulent les fonctions ou même qui exécutent des requêtes directes sur la base de données sans avoir besoin d’utiliser WordPress.

Mais, comme pour certains des points mentionnés ci-dessus, c’est le sujet d’un autre article.

J’écris actuellement un livre électronique (avec une variété d’autres contenus premium). Si vous êtes intéressé, regardez ce que vous obtenez.