Organizando as telas de configurações do WordPress
Como muitos de nós continuamos avançando com o PHP7+, podemos continuar aproveitando muitos novos recursos que a linguagem oferece.
Enquanto isso, porém, ainda existem recursos do PHP e softwares relacionados que podemos usar para ajudar a agilizar nosso desenvolvimento. O menos deles (e o que eu escrevi e falei um pouco) são os namespaces.
Aqui está a coisa, no entanto: eu gosto de ter os arquivos e diretórios do meu plugin estruturados para que eles sejam organizados para espelhar as convenções de namespace que eles seguem. E isso pode ser feito para taxonomias, meta boxes, objetos de domínio, funcionalidades relacionadas a banco de dados e assim por diante.
Neste post, porém, quero falar sobre uma maneira de organizar as telas de configurações do WordPress a partir das estruturas organizacionais lógicas – ou seja, a localização do sistema de arquivos – e as virtuais – ou seja, seus namespaces.
Organizando as telas de configurações do WordPress
O primeiro ponto que quero fazer é o seguinte: embora eu esteja falando sobre organizar as telas de configurações do WordPress, não estou falando nada sobre a API. Em vez disso, assuma que para este post estou falando sobre o seguinte:
- um menu personalizado que tem uma página de menu associada,
- uma página de menu que processa os requisitos para uma página de configurações (como o campo nonce e assim por diante)
- uma parcial que contém as configurações reais (ou várias parciais se você deseja incluir várias configurações).
Não vou falar sobre o processo de sanitização, serialização, recuperação, validação e exibição. Isso é puramente organizacional.
Pensando no processo
Dado que vamos organizar nossos arquivos por meio de diretórios que também mapeiam 1:1 com namespaces, vamos pensar exatamente no que vamos precisar. A forma como abordo é esta:
- Estamos criando algo especificamente para o aplicativo WordPress de contexto. Isso indica um namespace.
- Vamos criar um menu de administração, o que significa que estamos trabalhando na área de administração do WordPress, portanto, outro namespace, e com menus, que são outro namespace.
- Em seguida, precisamos de arquivos para exibir a tela padrão do WordPress, então precisaremos de um namespace Views,
- E então precisaremos de um código específico de domínio para cair na exibição, então, em última análise, precisaremos de um diretório Partials (e, portanto, de um namespace).
Portanto, a organização lógica final dos dados seria algo assim:
Talvez a coisa mais importante a ser observada sobre essa organização específica de arquivos é que a classe AdminMenu é uma classe base da qual todas as classes específicas (ou mais concretas) podem herdar.
Isso significa que a classe AcmeAdminMenu herda certas propriedades e funções dela e então implementa sua lógica ou adiciona sua lógica também.
Espaçamento entre nomes de cada arquivo
Quando você organiza seus arquivos dessa maneira, os namespaces se tornam quase auto-evidentes, não é? Aqui está o namespace para cada um dos arquivos:
- WordPressAdminMenuAdminMenu
- WordPressAdminMenuAcmeAdminMenu
- WordPressAdminMenuViewsSettings
- WordPressAdminMenuViewsSettingsPartials
Observe que, como o acme-settings.php é tecnicamente apenas uma marcação para opções de renderização, ele não precisa necessariamente ter namespace porque está incluído na View que o renderiza.
Independentemente disso, se você é fã de manter as coisas o mais organizadas possível, só faz sentido aninhar uma parcial dentro de um diretório chamado exatamente isso.
E quanto ao código?
Se você estiver interessado em ver o código para algo assim, estou pensando em montar um pequeno plugin que demonstre como tudo isso se encaixa. Afinal, isso é um pouco de alto nível, não é? Quero dizer, não há implementação.
Então, novamente, se isso ajudar a apontar a direção certa para um projeto atual ou futuro, pode ser suficiente.