Construindo telas de administração do WordPress (componentes, design, etc.)

Eu não falo muito sobre design de interface de usuário porque não é meu forte. Sou a favor de pessoas que trabalham dentro de seus principais pontos fortes e, em seguida, contratam-nas quando necessário, projeto a projeto (se os designs ainda não tiverem sido fornecidos).

Mas quando se trata de trabalhar com telas de administração do WordPress, há uma diferença, certo?

Estou na mentalidade de que, como a área de administração do WordPress tem uma aparência consistente, qualquer coisa criada para funcionar na tela de administração (como uma tela de configurações) deve parecer o mais próximo possível da interface do usuário principal.

Nem todos concordam, e isso é evidente pela vasta gama de plugins disponíveis. Mas essa é a minha posição sobre isso.

Periodicamente, me perguntam como eu estruturo as UIs de projetos quando eles precisam de telas de administração e como eu as mapeio para arquivos dentro do projeto.

Então eu pensei em pegar um exemplo simples e dividi-lo neste post curto.

Criando telas de administração do WordPress

Para este post, vou mantê-lo simples. Ou seja, a tela consistirá no mínimo de controles que geralmente compõem uma tela de administração.

Aquilo é:

• Mensagens (sucesso, erros ou avisos),
• Títulos e conteúdo
• Controles de entrada
• Campos Nonce

Você pode ficar um pouco mais complicado com guias, mas o acima cobrirá 99% de uma tela de configurações básicas. Eu não estou mergulhando na API de configurações neste post (eu fiz uma série inteira sobre isso antes).

Em vez disso, trata-se puramente de uma maneira de organizar os arquivos para que possam ser mantidos ao longo da vida útil de um projeto,

Quebrá-lo

Antes de ver como os arquivos são organizados e usados, quero esboçar como normalmente conceituo o que vejo na tela trabalhando nesta parte de um projeto.

Como você pode ver, todas as áreas acima são cobertas. Mas como eles mapeiam para arquivos é um pouco diferente. Caso em questão, a estrutura de diretórios se parece com isso:

Agora, dependendo de como você está implementando sua solução, dependerá de como essas telas são exibidas.

Ou seja, algumas vezes usar settings_mesasages() é o que você vai usar; outras vezes, você pode optar por usar manualmente require_once, pois tudo depende de como você está construindo a solução.

É fácil argumentar que deveria haver uma maneira de fazer isso, mas conforme as demandas das pessoas sobre como elas usam o WordPress mudam, assim como os requisitos e a implementação.

Como pode ser o código?

Se você optar por sair da API de configurações e fazer sua implementação, a marcação pode ser algo assim:

1 A IU completa

<?php
/**
 * This is the parent administration UI. This includes a single partial for the messaging.
 */
?>
<div class="wrap">
    <h1 class="wp-heading-inline">Import New Item</h1>
    <?php include_once 'partials/error-invalid-file.php'; ?>
    <div id="acme-upload-new-item-pdf">
        <form action="" enctype="multipart/form-data" method="post">
            <p>Upload a PDF</p>
            <input type="file" />
            <?php submit_button( 'Upload' ); ?>
            <?php wp_nonce_field( 'acme-upload', 'acme-importer' ); ?>
        </form>
    </div><!-- #acme-upload-new-item-pdf -->
</div><!-- .wrap -->

2 As mensagens incluídas

<div id="invalid-file-message" class="error notice is-dismissible">
    <p>You have attempted to upload an invalid file type.</p>
    <button type="button" class="notice-dismiss">
        <span class="screen-reader-text">Dismiss this notice.</span>
    </button>
</div><!-- #invalid-file-message -->

Isso é Barebones

‘Observe que isso não inclui internacionalização ou outras coisas que possam ser necessárias em seu projeto. É realmente o mínimo.

Mas, se nada mais, dá uma idéia de como você pode pegar os arquivos e juntá-los.