Создание экранов администрирования WordPress (компоненты, дизайн и т. д.)

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

Но когда дело доходит до работы с экранами администрирования WordPress, есть разница, верно?

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

Не все согласны, и это видно по огромному количеству доступных плагинов. Но это моя позиция по этому поводу.

Периодически меня спрашивают, как я структурирую пользовательские интерфейсы проектов, когда им нужны экраны администрирования, и как я сопоставляю их с файлами внутри проекта.

Поэтому я решил взять простой пример и разбить его в этом коротком посте.

Создание экранов администрирования WordPress

Для этого поста я буду простым. То есть экран будет состоять из минимума элементов управления, которые обычно составляют экран администрирования.

То есть:

• Обмен сообщениями (успех, ошибки или уведомления),
• Заголовки и содержание
• Элементы управления вводом
• Поля одноразового номера

С вкладками можно немного усложниться, но описанное выше покроет 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 -->

это бэрбоунс

‘Обратите внимание, что это не включает интернационализацию или другие вещи, которые могут потребоваться в вашем проекте. Это действительно минимум.

Но, по крайней мере, это дает представление о том, как вы можете взять файлы и собрать их вместе.