Wie wir ACF Blocks mit Handlebars Templating einsetzen

Mittels Handlebars Templating trennen wir Logik sauber vom Inhalt. Auf diese Weise können wir übersichtliche, einfache und performante Templates für WordPress Editor Blocks erstellen, welche je nach Anwendugskontext server- oder clientseitig gerendert werden.

Einführung

Warum und wie wir in unserem Gutenbase Core auf das Advanced Custom Fields Pro Plugin setzen, haben wir bereits in einem früheren Blogbeitrag berichtet.

Die Verwendung von Handlebars als Templatesprache erlaubt uns eine saubere Trennung von Logik und Inhalt. Dies ermöglicht es uns einfache und klar verständliche Vorlagen zu schreiben, welche sich auch einfach von Projekt zu Projekt portieren lassen. Hier das Beispiel eines Galerie Blocks, der diverse Layout Optionen anbietet sowie allenfalls auch ein Fancybox Overlay unterstützt.

<section{{{ct-init}}} class="{{ct-classes}}" role="group">
  <div class="row">
    {{#each items}}
      <div class="{{../layout}}">
        <figure class="item" role="group">
          {{#if ../fancybox}}<a href="{{{display.images.full}}}" data-src="#{{{../galleryid}}}-{{id}}" data-fancybox="{{../galleryid}}">{{/if}}
          {{#if ../ct-admin}}
            {{{display.tags.adminpicture}}}
          {{else}}
            {{{display.tags.picture}}}
          {{/if}}
          {{#if download}}
            <a class="dl" href="{{download}}" target="_blank" download>{{{ct-fontawesome "fa-solid fa-download"}}}</a>
          {{/if}}
          {{#if ../fancybox}}</a>{{/if}}
          {{#if ../fancybox}}
            <div class="ct_gallery_overlay" id="{{{../galleryid}}}-{{id}}">
              {{{overlay.tags.picture}}}
            </div>
          {{/if}}
        </figure>
      </div>
    {{/each}}
  </div>
</section>

Um dies zu ermöglichen stehen uns eine Vielzahl von Helferfunktionen zur Verfügung. In der Render Funktion des Blockes sammeln wir sämtliche per ACF definierten Felder sowie einige der Standard Gutenberg Blockeigenschaften (z. B. optional definierbare Block-ID’s oder Klassen) in einem Array. Dieses wird auf Block sowie Template Ebene gefiltert und erlaubt es uns so die Daten konkret, wie wir sie benötigen aufzubereiten. Diese Ergänzungen reichen von simpel, wie im obigen Beispiel die galleryid, bis zu der Generierung unserer Bilder. Die galleryid ist nichts weiteres als ein Präfix und die PHP Funktion uniqid(). Bei den Bildern hingegen, gehen wir von einer einfachen Bild-ID aus und generieren diverse HTML Elemente (so unterscheidet sich z. B. das benötigte Element im Editor/Backend von jenem im Frontend), die weiter unser voll responsives Bildhandling unterstützen. Unser hochperfomanter Handlebars Compiler rendert im Anschluss das Templates mit den Daten aus dem Array.

Performance

Zur Optimierung unserer Server-Antwortzeiten setzen wir an verschiedenen Orten dieser Prozesse auf Caching. Dazu nutzen wir die natives WordPress Transient Caching um beispielsweise den Rückgabewert unseres Bildhelfers zu sichern. Dies basierend auf den gegebenen Funktionswerten, so werden die Bildtags jeweils nur einmal, üblicherweise während der Bearbeitung im Editor, generiert, bei allen weiteren Calls, wird dann der Transient geladen. Auf höchster Ebene schreiben wir das Resultat des HBS Compilers basierend auf dem Datenarray in die Transienten. Die Kompilierung sowie eventuell server-intensive Zusammenstellung der nötigen Daten, erfolgt also meist bloss zweimal (einmal für die Editoransicht, einmal im Frontend).

Frontend Rendering

Für einige unserer Komponenten nutzen wir dynamisches Rendering von HBS Templates im Frontend, basierend auf Daten, welche wir per AJAX laden. Im Hintergrund funktioniert dies identisch zum Prozess bei den normalen Blocks. Im Callback eines benutzerdefinierten WordPress REST Endpoints, stellen wir die benötigten Daten fürs Rendering in einem Array zusammen. Dies wird im zurückgeschickt und im Frontend mit einem vorkompilierten HBS Template gerendert. Auf dieser Basis ist es uns möglich, Inhalte wie beispielsweise einen Überblick von Teammitgliedern oder Shop Produkte dynamisch zu filtern und/oder paginieren («mehr laden» Button). Aber auch andere dynamische Elemente, wie die Variantenauswahl (Halsband, Zubehör) beim oben verlinkten Shop, lassen sich so umsetzen.

Diese Anwendung bringt uns verschiedene Vorteile. Wir verwenden dieselben Templates unabhängig davon ob diese Server oder Client seitig gerendert werden. Ebenfalls minimieren wir die Datenmenge, welche in der REST Antwort mitgeschickt werden muss. Nehmen wir an, die Profile der Teammitglieder aus dem obigen Beispiel würden serverseitig gerendert, müssten wir für jede neue geladene Person den kompletten HTML Code mitschicken. Mit unserer Umsetzung wird lediglich das Bild, der Name und das Icon zurückgeschickt, das Template mit allem HTML Code wurde beim Seitenaufruf einmal initial mitgeschickt und kann im Anschluss für das Rendering jedes geladenen Angestellten verwendet werden.

Über mehr Details zum Frontendhbs, wie wir diese Tools in unserer Gutenbase nennen, sowie die Ideen, welche wir zur Weiterentwicklung haben, werden wir in einem späteren Blogbeitrag berichten. Abonniere unseren Newsletter, um sicherzustellen, dass Du diesen nicht verpasst.