WordPress-widgets: Refactoring, del 12

När det gäller omstruktureringen av WordPress Widget Boilerplate – särskilt med tanke på hur långt vi har kommit sedan projektet startade för åtta år sedan – har vi gjort mycket arbete.

Vi har tagit upp det till en mycket modernare standard och vi gör det mycket lättare att arbeta med det så att det borde vara lättare att bygga framtida widgets. Och detta är inte bara från standarden för pannplattan utan från en objektorienterad standard så att underhåll och kodkvalitet är högre.

I förra inlägget avslutade vi mycket av arbetet för administrationsområdet och är redo att påbörja vårt arbete med kod för front-end.

Vi sa:

Därefter ska vi titta på rendering av innehåll på front-end. Vi närmar oss slutet, av omstruktureringen av Boilerplate, men det finns bara lite mer att göra innan vi är redo att slå samman den i kodbasens huvudgren.

Så i det här inlägget ska vi plocka upp där. Om du nu har följt med fram till denna punkt bör du ha allt du behöver från utvecklingsgrenen.

Om inte, var noga med att dra det eftersom det är där vi kommer att ta upp i resten av inlägget.

WordPress Widget Boilerplate: Refactoring del 12

Nu när det kommer till gränssnittet är det lätt att tänka på gränssnittet som allt som användaren ser framför sig, oavsett om det är i det administrativa området eller inte.

Den här serien har dock varit tydlig med att vi delar upp vad användaren ser mellan det administrativa området och det offentliga området på webbplatsen.

Så vad vi kommer att göra är att arbeta med området för koden som återger information för användaren på det offentliga området på webbplatsen. Vi kommer att börja med att helt enkelt läsa informationen och visa den.

Sedan i nästa inlägg kommer vi att titta på att arbeta med villkorlig logik angående några av alternativen för att se om det är något vi behöver göra.

Med det sagt, låt oss gå in i koden.

På data vi kommer att visa

Kom ihåg att widgeten vid det här laget har tre saker som påverkar dess visning:

1. widgettiteln,
2. widgetinnehållet,
3. en växel om vi ska visa titeln eller inte

Det tredje alternativet är i första hand att visa hur man använder en annan typ av element. För tekniskt sett, om vi inte ville visa widgettiteln, skulle vi helt enkelt inte lägga in något i widgeten.

Men jag tror att det hjälper att visa att använda olika elementtyper och deras värden på ett praktiskt (eller semi-praktiskt) sätt.

Hur som helst, med det sagt, vi vet att för varje given instans av widgeten lagras data med titeln, innehållet och visningstitelns namn och ID som tillhandahålls av WordPress.

Därför kommer vi att använda dem i vår front-end-kod för att visa värdena.

Förbereder displayfunktionerna

Vanligtvis är widgetfunktionen ansvarig för att visa utdata från widgeten. Men en av sakerna vi har försökt göra är att dela upp problemen med vår widget i en mer fokuserad uppsättning klasser och funktioner.

Det första vi vill göra är att skriva en WidgetDisplay- klass som kommer att ansvara för, vilket säkert är uppenbart, visa innehållet i widgeten.

För närvarande kommer detta ovillkorligen att inkludera titeln, innehållet och värdet av om titeln ska inkluderas eller inte. WordPress gör också tillgängligt visst innehåll som uppmärkning som ska visas före widgeten och efter widgeten, så vi kommer att se till att inkludera det också.

Men först, låt oss bara slänga ut klassen :

<?php

namespace WordPressWidgetBoilerplateWordPress;

class WidgetDisplay
{
  private $widgetSlug;

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

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

Efter det måste vi se till att vi skriver upp det till de andra klasserna också. Först ska vi se till att inkludera det i vår Widget-klass :

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

Och sedan lägger vi till den i WidgetAdmin-klassen (eftersom det är här de centrala Widget API-funktionerna finns – den delegerar bara ansvaret till rätt klass):

<?php

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

För närvarande visar vi ingenting ännu. Vi är nära och vi kommer att fokusera på det snart.

Visar data

Förutsatt att du kan lägga till ovanstående kod utan fel, är det dags att visa innehållet i widgeten.

Vi kan göra detta på valfritt antal sätt från en enkel var_dump till att faktiskt arbeta för att visa innehållet på ett mer användarvänligt sätt. Och jag är mycket mer ett fan av det sistnämnda.

Så låt oss göra det.

Lägg till följande kod i showfunktionen för din WidgetDisplay- klass :

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

Och då kan vyn för mallen vara så enkel som denna :

<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']; ?>-->

Detta säkerställer att rätt uppmärkning för allt innehåll före widgeten, innehållet i widgeten och innehållet är korrekt renderat.

Återigen, kom ihåg att vi visar en del innehåll som inte kommer att finnas i den slutliga versionen av detta, men vi närmar oss och vi kommer att ta upp det i nästa inlägg.

Jag skulle rekommendera att leka med  alternativet Visa titel för att se hur det renderas på front-end med tanke på uppmärkningen vi har tillhandahållit.

För närvarande bör utdata från widgeten se ut ungefär så här:

Men det är allt som finns att ta upp i det här inlägget.

In i Final Refactor

Det sista vi kommer att titta på efter detta är att skärpa upp en del av den villkorliga logiken tillsammans med ett ord om cachning av data (eftersom vi redan gör lite av det i tidigare inlägg).

Än så länge kan du dock leka med vad vi har här tillsammans med koden som vi inte har inkluderat (som vad som kan visas före eller efter widgeten.

De har medvetet utelämnats från det här exemplet men de kanske inte alltid utelämnas beroende på vilket arbete du utför.