Ma ei räägi palju kasutajaliidese disainist, sest see pole minu forté. Olen inimeste jaoks, kes töötavad oma põhiliste tugevuste piires ja palkavad neid siis vajadusel projektipõhiselt (kui kujundusi pole juba esitatud).
Kuid WordPressi haldusekraanidega töötamisel on vahe, eks?
Olen seisukohal, et kuna WordPressi haldusalal on ühtlane välimus ja tunnetus, peaks kõik, mis on loodud haldusekraanil töötama (nt seadete ekraan), välja nägema võimalikult lähedal kasutajaliidesele.
Kõik ei ole sellega nõus ja see on ilmne saadaolevate pistikprogrammide suurest hulgast. Aga see on minu seisukoht selles.
Aeg-ajalt küsitakse minult, kuidas struktureerin projektide kasutajaliideseid, kui neil on vaja haldusekraane, ja kuidas ma vastan need projektisiseselt failidele.
Seega mõtlesin, et võtan lihtsa näite ja võtan selle selles lühikeses postituses lahti.
WordPressi haldusekraanide loomine
Selle postituse puhul jätan selle lihtsaks. See tähendab, et ekraan koosneb minimaalsetest juhtnuppudest, mis tavaliselt moodustavad haldusekraani.
See on:
- Sõnumid (edu, vead või teated),
- Pealkirjad ja sisu
- Sisendjuhtelemendid
- Nonce väljad
Vahelehtedega saate pisut keerulisemaks minna, kuid ülaltoodud katab 99% põhiseadete ekraanist. Ma ei sukeldu selles postituses seadete API -sse (olen sellest varem terve seeria teinud ).
Selle asemel on tegemist ainult viisiga, kuidas korraldada faile nii, et neid saaks kogu projekti eluea jooksul hooldada,
Selle lõhkumine
Enne kui vaatan, kuidas failid on korraldatud ja kasutatud, tahan visandada, kuidas ma tavaliselt kujutan ette seda, mida ma projekti selle osa kallal ekraanil näen.
Nagu näete, on kõik ülaltoodud valdkonnad kaetud. Kuid see, kuidas need failid kaardistatakse, on veidi erinev. Näiteks näeb kataloogistruktuur välja umbes selline:
Olenevalt sellest, kuidas te oma lahendust rakendate, sõltub nüüd sellest, kuidas neid ekraane kuvatakse.
See tähendab, et mõnikord kasutatakse seadet settings_mesasages() ; muul ajal võite valida nõudmise_once käsitsi kasutamise, kuna see kõik sõltub sellest, kuidas te lahendust koostate.
Lihtne vaielda, et seda teha peaks olema üks viis, kuid kuna inimeste nõudmised WordPressi kasutamisele muutuvad, muutuvad ka nõuded ja rakendamine.
Kuidas võib kood välja näha?
Kui otsustate seadete API-st välja astuda ja juurutada, võib märgistus välja näha umbes selline:
1 Täielik kasutajaliides
<?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 Kaasasolev sõnumside
<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 -->See on Barebone
„Pange tähele, et see ei hõlma rahvusvahelistumist ega muid asju, mida teie projekt võib nõuda. See on tõesti miinimum.
Aga kui mitte midagi muud, siis annab see aimu, kuidas failid võtta ja kokku panna.