Nie mówię dużo o projektowaniu interfejsu użytkownika, ponieważ nie jest to moja mocna strona. Jestem dla osób pracujących w ramach swoich podstawowych mocnych stron, a następnie zatrudniających ich w razie potrzeby na podstawie projektu po projekcie (jeśli projekty nie są jeszcze dostarczone).
Ale jeśli chodzi o pracę z ekranami administracyjnymi WordPress, jest różnica, prawda?
Mam na myśli, że ponieważ obszar administracyjny WordPressa ma spójny wygląd i sposób działania, wszystko, co jest zbudowane do pracy na ekranie administracyjnym (takie jak ekran ustawień), powinno wyglądać jak najbliżej głównego interfejsu użytkownika.
Nie wszyscy się z tym zgadzają, co widać po szerokiej gamie dostępnych wtyczek. Ale takie jest moje stanowisko w tej sprawie.
Od czasu do czasu jestem pytany, jak organizuję interfejsy użytkownika projektów, gdy potrzebują ekranów administracyjnych i jak mapuję je do plików w projekcie.
Pomyślałem więc, że wezmę prosty przykład i opiszę go w tym krótkim poście.
Budowanie ekranów administracyjnych WordPress
W tym poście zachowam prostotę. Oznacza to, że ekran będzie składał się z minimum elementów sterujących, które zwykle tworzą ekran administracyjny.
To znaczy:
- Wiadomości (sukces, błędy lub powiadomienia),
- Nagłówki i treść
- Kontrola wprowadzania
- Pola nonce
Możesz nieco bardziej skomplikować się z zakładkami, ale powyższe obejmuje 99% ekranu podstawowych ustawień. W tym poście nie zagłębiam się w Settings API (zrobiłem już na ten temat całą serię ).
Zamiast tego chodzi wyłącznie o sposób organizowania plików tak, aby były możliwe do utrzymania przez cały czas trwania projektu,
Rozbijając to
Zanim przyjrzę się organizacji i wykorzystaniu plików, chcę naszkicować, jak zwykle konceptualizuję to, co widzę na ekranie, pracując nad tą częścią projektu.
Jak widać, wszystkie powyższe obszary są objęte. Ale sposób, w jaki te mapowanie do plików jest nieco inny. Na przykład struktura katalogów wygląda mniej więcej tak:
Teraz, w zależności od tego, jak wdrażasz swoje rozwiązanie, będzie zależeć od tego, jak wyświetlane są te ekrany.
Oznacza to, że czasami użyjesz settings_mesasages() ; innym razem możesz zdecydować się na ręczne użycie require_once, ponieważ wszystko zależy od tego, jak budujesz rozwiązanie.
Łatwo się spierać, że powinien być jeden sposób, aby to zrobić, ale w miarę jak zmieniają się wymagania ludzi dotyczące sposobu korzystania z WordPressa, podobnie jak wymagania i implementacja.
Jak może wyglądać Kodeks?
Jeśli zdecydujesz się wyjść poza interfejs Settings API i wykonać swoją implementację, znaczniki mogą wyglądać mniej więcej tak:
1 Pełny interfejs użytkownika
<?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 Dołączone wiadomości
<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 -->To jest kadłubki
„Zauważ, że nie obejmuje to internacjonalizacji ani innych rzeczy, które mogą być wymagane w twoim projekcie. To naprawdę absolutne minimum.
Ale jeśli nic więcej, to daje wyobrażenie, jak możesz wziąć pliki i złożyć je razem.