WordPress-hallintanäyttöjen rakentaminen (komponentit, suunnittelu jne.)

En puhu paljon käyttöliittymäsuunnittelusta, koska se ei ole vahvuuteni. Olen ihmisten puolesta, jotka työskentelevät ydinvahvuuksiensa puitteissa ja palkkaan heidät tarvittaessa projektikohtaisesti (jos suunnitelmia ei ole jo toimitettu).

Mutta kun se tulee työskentelemään WordPressin hallintaruutujen kanssa, on ero, eikö?

Olen sitä mieltä, että koska WordPressin hallinta-alueella on yhtenäinen ulkoasu ja tuntuma, kaiken, mikä on rakennettu toimimaan hallintanäytössä (kuten asetusnäytössä), pitäisi näyttää mahdollisimman läheltä ydinkäyttöliittymää.

Kaikki eivät ole samaa mieltä, ja se käy ilmi saatavilla olevien laajennusten laajasta valikoimasta. Mutta tämä on minun kantani asiaan.

Ajoittain minulta kysytään, kuinka rakennan projektien käyttöliittymät, kun ne tarvitsevat hallintaruutuja, ja kuinka yhdistän ne tiedostoihin projektin sisällä.

Joten ajattelin ottaa yksinkertaisen esimerkin ja purkaa sen tässä lyhyessä viestissä.

WordPress-hallintanäyttöjen rakentaminen

Tätä viestiä varten aion pitää asian yksinkertaisena. Toisin sanoen näyttö tulee koostumaan vähimmäismäärästä säätimiä, jotka yleensä muodostavat hallintanäytön.

Tuo on:

• Viestit (menestys, virheet tai ilmoitukset),
• Otsikot ja sisältö
• Syöttöohjaimet
• Nonce- kentät

Välilehtien kanssa voi tulla hieman monimutkaisempi, mutta yllä oleva kattaa 99 % perusasetusnäytöstä. En sukeltaa Asetukset-sovellusliittymään tässä viestissä (olen tehnyt siitä koko sarjan aiemmin).

Sen sijaan tässä on kyse vain tavasta järjestää tiedostot niin, että niitä voidaan ylläpitää koko projektin elinkaaren ajan,

Breaking It Down

Ennen kuin tarkastelen tiedostojen järjestämistä ja käyttöä, haluan hahmotella, kuinka yleensä käsitän sen, mitä näen näytöllä työskentelemässä projektin tässä osassa.

Kuten näet, kaikki yllä mainitut alueet ovat katettuja. Mutta kuinka nämä yhdistävät tiedostot, on hieman erilainen. Esimerkiksi hakemistorakenne näyttää tältä:

Nyt riippuen siitä, kuinka toteutat ratkaisusi, riippuu siitä, miten nämä näytöt näytetään.

Toisin sanoen joskus käytät asetusta settings_mesasages() ; muina aikoina voit valita vaatimuksen_once-käytön manuaalisesti, koska tämä kaikki riippuu siitä, miten rakennat ratkaisua.

On helppo väittää, että sen pitäisi olla yksi tapa, mutta ihmisten WordPressin käyttöä koskevat vaatimukset muuttuvat, samoin kuin vaatimukset ja toteutus.

Miltä koodi voi näyttää?

Jos päätät astua asetusten sovellusliittymän ulkopuolelle ja toteuttaa, merkintä voi näyttää suunnilleen tältä:

1 Koko käyttöliittymä

<?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 Mukana tulevat viestit

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

Tämä on Barebone

’Huomaa, että tämä ei sisällä kansainvälistymistä tai muita asioita, joita projektissasi saatetaan vaatia. Se on todellakin minimi.

Mutta jos ei muuta, se antaa idean siitä, kuinka voit ottaa tiedostot ja koota ne.