Sobre como escrever funções legíveis do WordPress
Uma das coisas que considero consistentemente interessantes (tanto do ponto de vista da programação quanto do ponto de vista do WordPress), é isso:
Eu gosto de manter o código separado de forma que o código responsável por interagir com o WordPress seja relegado ao seu namespace enquanto o resto do nosso código é namespaced apropriadamente em outro lugar.
Eu acho que isso é óbvio, no entanto.
No entanto, quando se trata de escrever código, isso não significa que deva ser deixado simplesmente para a forma como escrevemos nossas classes e depois as organizamos. E as coisas em um nível um pouco mais granular?
Ou seja, e se observássemos os métodos como parte de um todo maior e tivéssemos certeza de que eles também estão fazendo seu trabalho bem? Claro, pessoas como Bob Martin têm escrito sobre esse tipo de coisa durante a maior parte de sua carreira e pregado para pessoas como nós.
Mas esses conceitos são algo que você simplesmente começa a fazer e depois os aplica para sempre. Os paradigmas mudam, somos melhores hoje do que ontem, e pode haver várias maneiras de alcançar o mesmo tipo de coisa.
Então, quando se trata de criar funções legíveis do WordPress para um domínio específico, como isso pode ser?
Funções legíveis do WordPress
Para aqueles que estão familiarizados com os princípios SOLID ou qualquer coisa que fale sobre escrever um bom código, uma das coisas sobre as quais muitas dessas pessoas escrevem é sobre o tamanho que um método deve ter.
Eu tendo a considerá-los como regras ao invés de leis porque, às vezes, os métodos simplesmente não podem ser tão curtos. Quer dizer, eu acho que eles poderiam, mas em algum momento parece microgerenciamento de código, certo?
E fazer algo por fazer é uma coisa, mas fazer algo por uma programação significativa é outra. Eu vou escolher o mais tarde de cada vez.
De qualquer forma, aqui está um exemplo: Digamos que você tenha algum código que é chamado via Ajax e antes de prosseguir com a operação, você precisa saber se existe um tipo de postagem personalizado.
As etapas para fazer algo assim podem ser as seguintes:
- iniciar a chamada Ajax,
- verifique o nonce de segurança para verificar se é uma solicitação válida,
- verifique se existem dados,
- se isso acontecer, retorne uma mensagem de sucesso; caso contrário, retorne uma mensagem de erro.
Tudo isso pode ser feito em uma única mensagem, claro, mas vamos supor que queremos escrever isso em uma série de chamadas que são fáceis de ler onde o código é autodocumentado, até certo ponto (isso não significa que eu sou contra comentários – não sou nada disso, mas isso não significa que queremos que nosso código não seja claro, não é?).
Primeiro, a chamada 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.
});
Em seguida , temos uma função no lado do servidor para verificar explicitamente o nonce de segurança (isso, é claro, pressupõe que você o esteja configurando corretamente no 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');
}
Depois disso, queremos verificar se os dados existem:
<?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();
}
A partir daqui, podemos trabalhar com o objeto de resposta Ajax avaliando sua propriedade de sucesso e reagindo de acordo.
Indo um passo além
Vamos dar um passo adiante e dizer que os produtos existem e queremos recuperar todos os seus IDs de postagem. Fazer isso com WP_Query é bem fácil, mas digamos, por diversão, queremos fazer interface com o banco de dados diretamente.
Observe que este é mais um exercício de mostrar uma maneira de fazer algo em vez de argumentar pelo uso de $wpdb em vez de WP_Query. Isso é conteúdo para um outro post.
De qualquer forma, determinamos que os dados existem. Então, vamos pegar uma matriz de todos os IDs de postagem e devolvê-la ou uma matriz vazia. Talvez isso se parecesse com isso:
<?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;
}
Uma vez que os valores são retornados, podemos então operá-los da maneira que acharmos melhor.
Qual é o propósito de tudo isso?
De um modo geral, é para nos ajudar a pensar sobre o código de tal forma que possamos lê-lo quase o mais próximo possível da palavra escrita. Ou seja, podemos apontar para um pedaço de código como digamos:
Primeiro, veremos se algo existe. Caso contrário, enviaremos um erro; caso contrário, pegaremos os dados e trabalharemos neles.
Concedido, estou falando em termos menos concretos aqui, mas isso é porque eu não sei necessariamente com o que você está trabalhando mais do que você sabe sobre o meu trabalho. Mas você entendeu a ideia, certo?
E além disso, se você estiver procurando um código de teste de unidade desacoplado do WordPress, isso pode ser feito através do uso de interfaces que simulam as funções ou até mesmo que executam consultas diretas no banco de dados sem precisar usar o WordPress.
Mas, como em alguns dos pontos mencionados acima, isso é assunto para um post diferente.
Atualmente estou escrevendo um eBook (junto com uma variedade de outros conteúdos premium). Se você estiver interessado, confira o que você recebe.
