Bygga WordPress-administrationsskärmar (komponenter, design, etc.)

Jag pratar inte så mycket om design av användargränssnitt eftersom det inte är min starka sida. Jag är helt för människor som arbetar inom sina kärnstyrkor och sedan anställer dem vid behov på projekt-för-projekt-basis (om designen inte redan finns).

Men när det kommer till att arbeta med WordPress administrationsskärmar är det en skillnad, eller hur?

Jag tänker på att eftersom WordPress-administrationsområdet har ett konsekvent utseende och känsla, bör allt som är byggt för att fungera inom administrationsskärmen (som en inställningsskärm) se så nära kärnanvändargränssnittet som möjligt.

Alla håller inte med, och det framgår av det stora utbudet av plugins som finns tillgängliga. Men det är min inställning till det.

Med jämna mellanrum får jag frågan hur jag strukturerar projektens användargränssnitt när de behöver administrationsskärmar och hur jag mappar dem till filer inom projektet.

Så jag tänkte ta ett enkelt exempel och bryta ner det i detta korta inlägg.

Bygga WordPress administrationsskärmar

För det här inlägget ska jag hålla det enkelt. Det vill säga, skärmen kommer att bestå av det absoluta minimum av kontroller som vanligtvis utgör en administrationsskärm.

Det är:

• Meddelanden (framgång, fel eller meddelanden),
• Rubriker och innehåll
• Ingångskontroller
• Nonce- fält

Du kan bli lite mer komplicerad med flikar, men ovanstående kommer att täcka 99% av en grundläggande inställningsskärm. Jag dyker inte in i Settings API i det här inlägget (jag har gjort en hel serie om det tidigare).

Istället handlar det enbart om ett sätt att organisera filer så att de kan underhållas under hela projektets livstid,

Bryter ner det

Innan jag tittar på hur filerna är organiserade och används vill jag skissa på hur jag normalt begreppsmässigt det jag ser på skärmen som arbetar med den här delen av ett projekt.

Som du kan se är alla områden ovan täckta. Men hur dessa mappar till filer är lite annorlunda. Som ett exempel ser katalogstrukturen ut ungefär så här:

Nu, beroende på hur du implementerar din lösning, beror på hur dessa skärmar visas.

Det vill säga, ibland är det att använda settings_mesasages() vad du kommer att använda; andra gånger kan du välja att manuellt använda require_once eftersom allt beror på hur du bygger lösningen.

Det är lätt att argumentera för att det borde finnas ett sätt att göra det på, men i takt med att människors krav på hur de använder WordPress förändras, liksom kraven och implementeringen.

Hur kan koden se ut?

Om du väljer att gå utanför Settings API och genomföra din implementering kan uppmärkningen se ut ungefär så här:

1 Det fullständiga användargränssnittet

<?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 Inkluderade meddelanden

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

Det här är Barebones

’Observera att detta inte inkluderar internationalisering eller andra saker som kan krävas i ditt projekt. Det är verkligen ett minimum.

Men om inte annat ger det en idé om hur du kan ta filerna och sätta ihop dem.