Створення екранів адміністрування WordPress (компоненти, дизайн тощо)

Я не говорю багато про дизайн інтерфейсу користувача, тому що це не моя сильна сторона. Я підтримую людей, які працюють у межах своїх основних сильних сторін, а потім наймають їх, коли це необхідно, для кожного окремого проекту (якщо проекти ще не надані).

Але коли справа доходить до роботи з екранами адміністрування WordPress, різниця є, чи не так?

Я вважаю, що оскільки область адміністрування WordPress має узгоджений вигляд і відчуття, то все, що створено для роботи на екрані адміністрування (наприклад, екран налаштувань), має виглядати якомога ближче до основного інтерфейсу користувача.

Не всі погоджуються, і це видно з великої кількості доступних плагінів. Але це моя позиція щодо цього.

Періодично мене запитують, як я структурую інтерфейси користувача проектів, коли їм потрібні екрани адміністрування, і як зіставляти їх із файлами в проекті.

Тож я вирішив взяти простий приклад і розбити його в цій короткій публікації.

Створення екранів адміністрування WordPress

У цьому дописі я буду простіше. Тобто екран складатиметься з мінімуму елементів керування, які зазвичай складають екран адміністрування.

Це:

• Повідомлення (успіх, помилки або повідомлення),
• Заголовки та зміст
• Елементи керування введенням
• Nonce поля

Ви можете зробити трохи складніше з вкладками, але вищезазначене охопить 99% екрана основних налаштувань. У цьому дописі я не занурююся в API налаштувань (раніше я робив цілу серію про це).

Замість цього йдеться виключно про спосіб організації файлів, щоб їх можна було підтримувати протягом усього життя проекту,

Розбиваємо це

Перш ніж дивитися на те, як файли організовані та використовуються, я хочу зобразити, як я зазвичай концептуалізую те, що бачу на екрані, працюючи над цією частиною проекту.

Як бачите, усі перераховані вище сфери охоплено. Але спосіб відображення файлів дещо інший. У цьому випадку структура каталогу виглядає приблизно так:

Тепер залежно від того, як ви реалізуєте своє рішення, буде залежати те, як відображатимуться ці екрани.

Тобто іноді ви будете використовувати settings_mesasages() ; в інших випадках ви можете вручну використовувати require_once, оскільки все залежить від того, як ви створюєте рішення.

Легко стверджувати, що має бути один спосіб зробити це, але оскільки вимоги людей до того, як вони використовують WordPress, змінюються, як і вимоги та впровадження.

Як може виглядати код?

Якщо ви вирішите вийти за межі API налаштувань і виконати свою реалізацію, розмітка може виглядати приблизно так:

1 Повний інтерфейс користувача

<?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 Включений обмін повідомленнями

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

Це Barebones

«Зверніть увагу, що це не включає інтернаціоналізацію чи інші речі, які можуть знадобитися у вашому проекті. Це справді необхідний мінімум.

Але, якщо нічого іншого, це дає уявлення про те, як ви можете взяти файли та зібрати їх разом.