Widget WordPress: refactoring, parte 12

Per quanto riguarda il refactoring del Widget Boilerplate di WordPress, soprattutto considerando quanto siamo arrivati ​​lontano da quando il progetto è iniziato otto anni fa, abbiamo lavorato molto.

L’abbiamo portato a uno standard molto più moderno e stiamo rendendo molto più semplice lavorare con esso in modo tale che la creazione di widget futuri dovrebbe essere più semplice. E questo non deriva solo dallo standard del boilerplate, ma da uno standard orientato agli oggetti in modo che la manutenzione e la qualità del codice siano più elevate.

Nell’ultimo post, abbiamo concluso gran parte del lavoro per l’area di amministrazione e siamo pronti per iniziare il nostro lavoro sul codice per il front-end.

Noi abbiamo detto:

Successivamente, esamineremo il rendering dei contenuti sul front-end. Ci stiamo avvicinando alla fine, del refactoring di Boilerplate, ma c’è solo un po’ di più da fare prima di essere pronti per unirlo al ramo principale della codebase.

Quindi, in questo post, riprenderemo da lì. Ora, se hai seguito fino a questo punto, dovresti avere tutto ciò di cui hai bisogno dal ramo di sviluppo.

In caso contrario, assicurati di tirarlo perché è lì che riprenderemo nel resto del post.

The WordPress Widget Boilerplate: Refactoring Parte 12

Ora, quando si tratta di front-end, è facile pensare al front-end come a qualsiasi cosa l’utente veda davanti a sé, indipendentemente dal fatto che si trovi nell’area amministrativa o meno.

Tuttavia, questa serie è stata chiara sul fatto che stiamo dividendo ciò che l’utente vede tra l’area amministrativa e l’area pubblica del sito.

Quindi quello che faremo è lavorare sull’area del codice che rende le informazioni per l’utente nell’area pubblica del sito. Inizieremo semplicemente leggendo le informazioni e visualizzandole.

Quindi nel prossimo post, esamineremo il lavoro con la logica condizionale per quanto riguarda alcune delle opzioni per vedere se c’è qualcosa che dobbiamo fare.

Detto questo, entriamo nel codice.

Sui dati che mostreremo

Ricorda, il widget, a questo punto, ha tre cose che influenzano la sua visualizzazione:

1. il titolo del widget,
2. il contenuto del widget,
3. un interruttore per decidere se visualizzare o meno il titolo

La terza opzione consiste principalmente nel mostrare come utilizzare un diverso tipo di elemento. Perché, tecnicamente, se non volessimo mostrare il titolo del widget, non inseriremmo nulla nel widget.

Ma penso che aiuti a mostrare come utilizzare diversi tipi di elementi e i loro valori in modo pratico (o semi-pratico).

Ad ogni modo, detto questo, sappiamo che per ogni data istanza del widget, i dati vengono archiviati con il titolo ,  il contenuto e  il nome del titolo visualizzato e gli ID forniti da WordPress.

Pertanto, utilizzeremo quelli nel nostro codice front-end per visualizzare i valori.

Preparazione delle funzioni di visualizzazione

In genere, la  funzione widget è responsabile della visualizzazione dell’output del widget. Ma una delle cose che abbiamo cercato di fare è separare le preoccupazioni del nostro widget in un insieme più mirato di classi e funzioni.

La prima cosa che vogliamo fare è scrivere una  classe WidgetDisplay che si occuperà, come è sicuramente evidente, di visualizzare il contenuto del widget.

Per ora, questo includerà incondizionatamente il titolo, il contenuto e il valore di includere o meno il titolo. WordPress rende disponibili anche alcuni contenuti come il markup che dovrebbero apparire prima del widget e dopo il widget, quindi ci assicureremo di includere anche quello.

Ma prima, interrompiamo la classe :

<?php

namespace WordPressWidgetBoilerplateWordPress;

class WidgetDisplay
{
  private $widgetSlug;

  public function __construct(string $widgetSlug)
  {
      $this->widgetSlug = $widgetSlug;
  }

  public function show($args, $instance)
  {
    // More to come
  }
}

Dopodiché, dobbiamo assicurarci di scriverlo anche per le altre classi. Innanzitutto, ci assicureremo di includerlo nella nostra classe Widget :

<?php
public function widget($args, $instance)
{
    return $this->widgetDisplay->show($args, $instance);
}

E poi lo aggiungeremo alla classe WidgetAdmin (poiché è qui che risiedono le funzioni principali dell’API Widget – delega semplicemente la responsabilità alla classe corretta):

<?php

public function __construct($widgetSlug)
{
    parent::__construct($widgetSlug);
    $this->widgetSerializer = new WidgetSerializer($this->getWidgetSlug());
    $this->widgetDisplay = new WidgetDisplay($this->getWidgetSlug());
}

A questo punto, non stiamo ancora visualizzando nulla. Siamo vicini e su questo ci concentreremo presto.

Visualizzazione dei dati

Supponendo che tu sia in grado di aggiungere il codice sopra senza errori, è ora di visualizzare il contenuto del widget.

Possiamo farlo in molti modi, da un semplice var_dump a lavorare effettivamente per visualizzare il contenuto in un modo più intuitivo. E io sono molto più un fan di quest’ultimo.

Quindi facciamolo.

Nella  funzione show della tua  classe WidgetDisplay, aggiungi il codice seguente :

<?php
public function show($args, $instance)
{
    include_once 'Views/Widget.php';
}

E quindi la vista per il modello può essere semplice come questa :

<div id="<?php echo $args['id']; ?>">
    <h3 class="widget-title"><?php echo $instance['title']; ?></h3>
    <p><?php echo $instance['content']; ?></p>
    <pre><?php echo $instance['display-title']; ?></pre>
</div><!-- #<?php echo $args['id']; ?>-->

Ciò assicurerà che il markup corretto per tutto il contenuto prima del widget, il contenuto del widget e il contenuto siano visualizzati correttamente.

Ancora una volta, ricorda che stiamo visualizzando alcuni contenuti che non saranno nella versione finale di questo, ma ci stiamo avvicinando e ne parleremo nel prossimo post.

Consiglierei di giocare con l’  opzione Visualizza titolo per vedere come viene visualizzato sul front-end dato il markup che abbiamo fornito.

Per ora, l’output del widget dovrebbe assomigliare a questo:

Ma questo è tutto quello che c’è da coprire in questo post.

Nel Refactor finale

L’ultima cosa che esamineremo dopo questo è il rafforzamento di parte della logica condizionale insieme a una parola sulla memorizzazione nella cache dei dati (dal momento che ne stiamo già facendo un po’ nei post precedenti).

Per ora, però, sentiti libero di giocare con ciò che abbiamo qui insieme al codice che non abbiamo incluso (come ciò che può essere visualizzato prima o dopo il widget.

Sono stati deliberatamente esclusi da questo esempio, ma potrebbero non essere sempre esclusi a seconda del lavoro che stai facendo.