Anos atrás, escrevi um post no qual compartilhei uma função pública para determinar se o usuário tinha permissão para salvar informações no banco de dados do WordPress. Você pode ver a essência original em toda a sua glória envelhecida (junto com os comentários sólidos) aqui (tem cinco anos, até – uau).
Como acontece com qualquer coisa relacionada à programação, o tempo passa, as coisas são refinadas e as coisas [espero] ficam melhores do que eram antes.
Embora eu ainda use e recomende uma variante da função user_can_save (ou userCanSave ), também acho importante passar pelo processo de separação do processo de verificação da solicitação.
Portanto, agora não se trata apenas de determinar se o usuário tem permissões, mas de verificar as informações de segurança vindas do cliente – seja por meio de um post de volta ao servidor ou uma solicitação feita via Ajax – e fazê-lo usando boas técnicas de programação que se alinhem tanto com WordPress quanto com PHP.
Para ser claro, isso é mais sobre o envio seguro de formulários do WordPress a partir de uma página de opções ou uma página de configurações do que, digamos, um formulário proveniente de um modelo. Esse é outro post para outro momento.
Mas ainda assim, há muitos de nós trabalhando na construção de aplicativos no WordPress e que exigem o seguinte.
Envio seguro de formulários WordPress
Neste post, não vou me preocupar em passar pelos detalhes para determinar se algo é um salvamento automático ou uma revisão de postagem.
No entanto, vou percorrer o processo de pegar uma função responsável por validar as informações recebidas e fazê-lo usando uma abordagem moderna usando práticas orientadas a objetos e APIs do WordPress e funções PHP.
1 Começando em um nível genérico
A partir do nível fundamental, vamos supor que há uma classe base da qual existem outras subclasses que aproveitam essa função. Isso nos diz que precisamos usar o modificador de visibilidade protegido.
Também sabemos que vamos lidar com um valor nonce do WordPress e uma ação relacionada. Isso significa que a assinatura da função será algo assim :
2 Higienize os dados, verifique o Nonce
De acordo com qualquer coisa que seja postada no servidor, sabemos que precisaremos verificar se os dados estão definidos e, em caso afirmativo, precisaremos limpar as informações.
Isso significa que vamos precisar das seguintes funções:
E também sabemos que precisaremos verificar o nonce, então também precisaremos de wp_verify_nonce.
3 Um Primeiro Passe de Trabalho
Uma primeira passagem funcional desta função pode ser algo assim:
Mas e se alguém estiver compartilhando dados que enviaram uma solicitação POST (versus uma solicitação GET )? Então poderíamos modificar a função para ficar assim:
E isso seria suficiente. Mas se realmente queremos que uma determinada função seja a mais pura possível, podemos decompô-la ainda mais.
4 Uma Função Para Cada Propósito
Dado o código acima, sabemos que precisamos lidar com solicitações GET e solicitações POST. O PHP oferece uma função filter_input que é útil, mais fácil de ler (bem, isso é subjetivo), mas também passa por várias inspeções de qualidade de código.
Além disso, podemos usar uma função simples de fábrica para separar a lógica em funções separadas como esta:
Primeiro, precisamos escrever duas funções separadas – uma para uma solicitação POST:
E um para uma solicitação GET:
Então podemos juntá-lo na função original assim:
Gerenciando de forma limpa as solicitações recebidas
Talvez isso pareça uma maneira complicada de lidar com uma solução simples, dado o conjunto inicial de código que foi compartilhado.
Isso é certamente possível, especialmente se você estiver sob as restrições de tempo ou não se importar tanto em dividir as coisas nos menores componentes atômicos possíveis (ou mesmo testáveis).
Mas se você deseja escrever código orientado a objetos com o mais alto grau de precisão, talvez esse processo ajude exatamente nisso.