Creación de pantallas de administración de WordPress (componentes, diseño, etc.)
No hablo mucho sobre el diseño de la interfaz de usuario porque no es mi fuerte. Estoy totalmente a favor de las personas que trabajan dentro de sus fortalezas principales y luego las contratan cuando es necesario, proyecto por proyecto (si los diseños aún no se han proporcionado).
Pero cuando se trata de trabajar con las pantallas de administración de WordPress, hay una diferencia, ¿no?
Tengo la mentalidad de que debido a que el área de administración de WordPress tiene una apariencia uniforme, cualquier cosa que esté diseñada para funcionar dentro de la pantalla de administración (como una pantalla de configuración) debe verse lo más cerca posible de la interfaz de usuario central.
No todos están de acuerdo, y es evidente por la gran variedad de complementos disponibles. Pero esa es mi posición al respecto.
Periódicamente, me preguntan cómo estructuro las interfaces de usuario de los proyectos cuando necesitan pantallas de administración y cómo las asigno a archivos dentro del proyecto.
Así que pensé en tomar un ejemplo simple y desglosarlo en esta breve publicación.
Creación de pantallas de administración de WordPress
Para esta publicación, voy a mantenerlo simple. Es decir, la pantalla consistirá en el mínimo de controles que normalmente componen una pantalla de administración.
Eso es:
- Mensajería (éxito, errores o avisos),
- Encabezados y contenido
- Controles de entrada
- Campos nonce
Puede volverse un poco más complicado con las pestañas, pero lo anterior cubrirá el 99% de una pantalla de configuración básica. No me estoy sumergiendo en la API de configuración en esta publicación (he hecho una serie completa sobre eso antes).
En cambio, se trata simplemente de una forma de organizar los archivos para que se puedan mantener durante la vida útil de un proyecto.
Rompiéndolo
Antes de ver cómo se organizan y utilizan los archivos, quiero esbozar cómo conceptualizo normalmente lo que veo en la pantalla trabajando en esta parte de un proyecto.
Como puede ver, todas las áreas anteriores están cubiertas. Pero la forma en que estos se asignan a los archivos es un poco diferente. Por ejemplo, la estructura del directorio se parece a esto:
Ahora, dependiendo de cómo esté implementando su solución, dependerá de cómo se muestren estas pantallas.
Es decir, a veces usar settings_mesasages() es lo que usará; otras veces, puede optar por usar require_once manualmente, ya que todo depende de cómo esté creando la solución.
Es fácil argumentar que debería haber una forma de hacerlo, pero a medida que cambian las demandas de las personas sobre cómo usan WordPress, también cambian los requisitos y la implementación.
¿Cómo podría verse el código?
Si opta por salir de la API de configuración y hacer su implementación, el marcado puede verse así:
1 La interfaz de usuario completa
<?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 La mensajería incluida
<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 -->esto es barebones
‘Tenga en cuenta que esto no incluye la internacionalización u otras cosas que pueden ser necesarias en su proyecto. Es realmente el mínimo indispensable.
Pero, al menos, da una idea de cómo puede tomar los archivos y armarlos.