Creazione di schermate di amministrazione di WordPress (componenti, design, ecc.)

Non parlo molto del design dell’interfaccia utente perché non è il mio forte. Sono tutto per le persone che lavorano all’interno dei loro punti di forza principali e poi le assumono quando necessario, progetto per progetto (se i progetti non sono già forniti).

Ma quando si tratta di lavorare con le schermate di amministrazione di WordPress, c’è una differenza, giusto?

Sono convinto che, poiché l’area di amministrazione di WordPress ha un aspetto coerente, tutto ciò che è costruito per funzionare all’interno della schermata di amministrazione (come una schermata delle impostazioni) dovrebbe apparire il più vicino possibile all’interfaccia utente principale.

Non tutti sono d’accordo, ed è evidente dalla vasta gamma di plugin disponibili. Ma questa è la mia posizione al riguardo.

Periodicamente, mi viene chiesto come strutturo le UI dei progetti quando necessitano di schermate di amministrazione e come le mappo ai file all’interno del progetto.

Quindi ho pensato di fare un semplice esempio e di scomporlo in questo breve post.

Creazione di schermate di amministrazione di WordPress

Per questo post, lo manterrò semplice. Cioè, lo schermo consisterà nel minimo indispensabile di controlli che di solito costituiscono una schermata di amministrazione.

Questo è:

• Messaggistica (successo, errori o avvisi),
• Intestazioni e contenuti
• Controlli di input
• Campi Nonce

Puoi diventare leggermente più complicato con le schede, ma quanto sopra coprirà il 99% di una schermata delle impostazioni di base. Non mi sto immergendo nell’API delle impostazioni in questo post (ho già fatto un’intera serie su questo).

Invece, si tratta semplicemente di un modo per organizzare i file in modo che siano gestibili per tutta la durata di un progetto,

Scomponendolo

Prima di vedere come sono organizzati e utilizzati i file, voglio abbozzare come concettualizzare normalmente ciò che vedo sullo schermo lavorando su questa parte di un progetto.

Come puoi vedere, tutte le aree sopra sono coperte. Ma il modo in cui questi vengono mappati sui file è leggermente diverso. Caso in questione, la struttura della directory è simile a questa:

Ora, a seconda di come stai implementando la tua soluzione, dipenderà da come vengono visualizzate queste schermate.

Cioè, a volte  userai settings_mesasages() ; altre volte, puoi scegliere di utilizzare manualmente require_once poiché tutto dipende da come stai creando la soluzione.

È facile sostenere che dovrebbe esserci un modo per farlo, ma poiché le richieste delle persone su come utilizzano WordPress cambiano, così come i requisiti e l’implementazione.

Come potrebbe apparire il codice?

Se scegli di uscire dall’API delle impostazioni e di eseguire la tua implementazione, il markup potrebbe assomigliare a questo:

1 L’interfaccia utente 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 La messaggistica inclusa

<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 -->

Questo è Barebones

‘Nota che questo non include l’internazionalizzazione o altre cose che potrebbero essere richieste nel tuo progetto. È davvero il minimo indispensabile.

Ma, se non altro, dà un’idea di come prendere i file e metterli insieme.