Erstellen von WordPress-Verwaltungsbildschirmen (Komponenten, Design usw.)

Ich rede nicht viel über User Interface Design, weil es nicht meine Stärke ist. Ich bin für Leute, die innerhalb ihrer Kernkompetenzen arbeiten und sie dann bei Bedarf projektweise einstellen (wenn die Entwürfe nicht bereits bereitgestellt wurden).

Aber wenn es um die Arbeit mit WordPress-Verwaltungsbildschirmen geht, gibt es einen Unterschied, oder?

Ich bin der Meinung, dass, weil der WordPress-Administrationsbereich ein konsistentes Erscheinungsbild hat, alles, was für die Arbeit innerhalb des Administrationsbildschirms (z. B. ein Einstellungsbildschirm) erstellt wurde, so nah wie möglich an der Kernbenutzeroberfläche aussehen sollte.

Nicht jeder stimmt zu, und es ist offensichtlich durch die große Auswahl an Plugins, die verfügbar sind. Aber das ist meine Position dazu.

In regelmäßigen Abständen werde ich gefragt, wie ich die Benutzeroberflächen von Projekten strukturiere, wenn sie Verwaltungsbildschirme benötigen, und wie ich sie Dateien innerhalb des Projekts zuordne.

Also dachte ich, ich würde ein einfaches Beispiel nehmen und es in diesem kurzen Beitrag aufschlüsseln.

Erstellen von WordPress-Verwaltungsbildschirmen

Für diesen Beitrag werde ich es einfach halten. Das heißt, der Bildschirm besteht aus dem absoluten Minimum an Steuerelementen, die normalerweise einen Verwaltungsbildschirm ausmachen.

Das ist:

• Nachrichten (Erfolg, Fehler oder Hinweise),
• Überschriften und Inhalt
• Eingabesteuerelemente
• Nonce- Felder

Mit Registerkarten kann es etwas komplizierter werden, aber das oben Genannte deckt 99 % eines Grundeinstellungsbildschirms ab. Ich tauche in diesem Beitrag nicht in die Einstellungs-API ein (dazu habe ich schon eine ganze Serie gemacht ).

Stattdessen geht es hier nur um eine Möglichkeit, Dateien so zu organisieren, dass sie während der gesamten Lebensdauer eines Projekts gewartet werden können.

Brechen sie ab

Bevor ich mir anschaue, wie die Dateien organisiert und verwendet werden, möchte ich skizzieren, wie ich normalerweise konzeptualisiere, was ich auf dem Bildschirm sehe, wenn ich an diesem Teil eines Projekts arbeite.

Wie Sie sehen können, sind alle oben genannten Bereiche abgedeckt. Aber wie diese auf Dateien abgebildet werden, ist ein bisschen anders. In diesem Fall sieht die Verzeichnisstruktur in etwa so aus:

Nun, je nachdem, wie Sie Ihre Lösung implementieren, hängt davon ab, wie diese Bildschirme angezeigt werden.

Das heißt, manchmal verwenden  Sie settings_mesasages(), was Sie verwenden werden; In anderen Fällen können Sie sich für die manuelle Verwendung  von require_once entscheiden, da dies alles davon abhängt, wie Sie die Lösung erstellen.

Es ist leicht zu argumentieren, dass es einen Weg geben sollte, aber wenn sich die Anforderungen der Leute an die Art und Weise, wie sie WordPress verwenden, ändern, ändern sich auch die Anforderungen und die Implementierung.

Wie könnte der Kodex aussehen?

Wenn Sie sich dafür entscheiden, die Einstellungs-API zu verlassen und Ihre Implementierung vorzunehmen, kann das Markup in etwa so aussehen:

1 Die vollständige Benutzeroberfläche

<?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 Das enthaltene Messaging

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

Das ist Barebone

„Beachten Sie, dass dies keine Internationalisierung oder andere Dinge beinhaltet, die in Ihrem Projekt erforderlich sein könnten. Es ist wirklich das absolute Minimum.

Aber nicht zuletzt gibt es eine Vorstellung davon, wie Sie die Dateien nehmen und zusammenstellen können.