Das Video ist auf englisch, hat aber manuell erstellte deutsche Untertitel. Die deutsche Transkription befindet sich unter dem Video.
Links
Transcript auf deutsch
Hallo mein Name ist Marco. In diesem Video geht es wieder um die Erstellung von Custom WordPress Blocks mit Pinegrow.
Pinegrow bietet vier verschiedene Blocktypen an. Daher stellt sich die Frage, wann man welchen Blocktyp verwenden sollte.
Zwischen folgenden Blocktypen können wir wählen:
Regulärer Block: Diese Blocks funktionieren mit React Code und erlauben das Inline-Editing des Inhalts. Der Nachteil ist, dass die Struktur zusammen mit dem Blockinhalt gespeichert wird. Ändert sich die Struktur – zum Beispiel wenn eine neue CSS Klasse oder ein visuelles Element im Template hinzugefügt wird – muss man das Block Recovery durchführen. Und zwar bei jeder einzelnen Block Instanz. Was das genau bedeutet sehen wir später noch.
Hybrid Block: Ist eine Kombination von PHP und React. Hybrid Blocks sind relativ neu in Pinegrow und lösen die Nachteile der Regulären Blocks. Im Block Editor verhalten Sie sich wie React Blocks – das Inline-Editing ist möglich. Jedoch wird weiterhin Struktur und Inhalt getrennt, sodass kein Block Recovery nötig ist, wenn sich die Struktur ändert.
ACF Block: Hierzu benötigt man eine Advanced Custom Fields Pro Lizenz. ACF Blocks visuell mit Pinegrow zu erstellen ist viel einfacher, als das manuell nur mit ACF alleine zu machen. Diesen ACF Blocks werden ACF Felder zugewiesen. Dann kann man den Block Inhalt bequem mit Inhalt füllen. Vorteil ist hier, dass man auf alle Feldtypen von ACF zurückgreifen kann. Da es sich hier um PHP basierte Blocks handelt muss bei der Einhabe von Inhalten die Vorschau immer wieder über den Server neu geladen werden. Man hat also kein Inline-Editing wie bei Regulären- oder Hybrid Blocks.
Dynamischer Block: Dieser Blocktyp eignet sich für die Anzeige dynamischer Daten, die vom Server geladen werden. In unserem Beispiel laden wie die Testimonials von einem Custom Post Type und zeigen diese an. In diesem Fall hat der Block keine Einstellungsoptionen, aber auch das wäre machbar – sagen wir: um die Sortierung zu beeinflussen, oder die Anzahl der anzuzeigenden Testimonials.
Um die Unterschiede zu verstehen, bauen wir einen Testimonial Block als regulären, Hybrid- und ACF Block. Den Dynamischen Block verwenden wir – wie erwähnt – für das Auflisten von Testimonials aus einem Custom Post Type.
In der Video-Beschreibung findest du einen Link zum Github-Repository für die Pinegrow Projekt Dateien. Außerdem einen Link zu der offiziellen Pinegrow Dokumentation sowie den Link zu AutomaticCSS – dem CSS Framework, dass ich verwende.
Um das Video möglichst übersichtlich zu halten, gehe nicht detailliert auf das nötige HTML und CSS ein. Wenn dich das interessiert, wirf einen Blick in das verlinkte Github Repository.
Hier eine Vorschau auf die verschiedenen Blocks.
Der Reguläre, Hybride, ACF und Dynamic Block sehen im Frontend natürlich alle gleich aus.
Der Unterschied besteht in den technischen Details die zum Glück Pinegrow übernimmt. Es gibt auch Unterschiede bei der Inhaltspflege und wie viel Aufwand es ist, die Blocktemplates Seitenübergreifend zu verändern.
Wollen wir loslegen?
Werfen wir erst einen Blick auf die WordPress Installation.
Folgende Plugins sind installiert und für dieses Beispiel relevant:
ACF Pro, ACSS, Das Pinegrow WordPress Plugin, (Dieses Plugin brauchen wir nicht. Weg damit.)
Filster habe ich lediglich installiert um den Pfad zu einer CSS Datei einfach zu finden.
ACSS generiert seine CSS Dateien ins uploads-Verteichnis.
Es spielt keine große Rolle, aber in dieser Installlation habe ich übrigens GeneratePress als Theme installiert.
Okay. Also mit Filester kopiere ich mir nun den Pfad zu automatic.css um ihn in Pinegrow zu verwenden. Dazu wechsele ich zu wp-content/uploads/automatic-css/ und kopiere den Pfad zur Datei automatic.css.
Dann lege ich das Pinegrow Projekt an. Einfach ein leeres Projekt mit Plain HTML.
Das Projekt hat bereits eine index.html
Ich werde alle Blöcke in dieser einen Datei erstellen. Sie dient mir nur als Arbeitsplatz. Für bessere Ordnung könnte ich auch für jeden Block eine eigene .html Datei anlegen – das lohnt sich bei größeren Projekten.
Jedenfalls füge ich jetzt erst mal automatic.css in den head ein, damit ich die CSS Klassen und Variablen in Pinegrow zur Verfügung habe.
Dann das Projekt zum ersten mal Speichern. Pinegrow fragt nach einem Projektnamen.
Durch Anklicken von „Activate“ gelange ich in die Einstellungen. Hier entscheide ich, ob ich ein WordPress Theme, oder ein Plugin erstellen will. Ich wähle „Plugin“, gebe den Namen ein und mache die übrigen Einstellungen.
Als nächstes werde ich eine Sektion erstellen. So kann ich sehen, ob ACSS korrekt geladen wird, denn die Sektion bekommt das korrekte Padding.
Wenn ich möchte, kann ich die Vorschau einschalten, um meine Arbeit im Kontext der Website zu sehen.
Aus irgend einem Grund muss ich jetzt noch dem div in der Section 100% Breite geben. Okay, dann mache ich das in der stye.css die automatisch erstellt wurde. Die verwende ich nur hier in Pinegrow und werde sie nicht mit dem Block ins Plugin exportieren.
Die Vorschau schalte ich erst mal wieder aus. Jetzt habe ich Platz zum Arbeiten.
Die ACSS Klassen stehen in Pinegrow noch nicht zur Verfügung. Offenbar hat Pinegrow sie noch nicht eingelesen.
Im Style-Panel aktualisiere ich die Liste der CSS Dateien. Und da ist jetzt auch automatic.css aufgelistet. Die Datei sperre ich, um sie vor Änderungen zu schützen.
Jetzt habe ich alle CSS Klassen von ACSS zur Auswahl. Die Vorbereitungen sind abgeschlossen.
Über die Funktion „Insert Code“ (oder auf der Tatsatur „+“) arbeite ich gerne, um schnell HTML zu schreiben. Hier muss man nicht HTML Syntax schreiben, sondern kann auch, wie du hier siehst, die SIMPLE Syntax nutzen. So wird das Arbeiten nochmal etwas einfacher und schneller.
Ich baue jetzt die komplette Testimonial Card inklusive der CSS Klassen. Lass uns das ein bisschen beschleunigen…
Ich füge Dummy Texte ein. So ist es einfacher, die Inhalte später zu ändern und durch dynamische Platzhalter zu ersetzen.
Jetzt kann ich den Code in das Struktur-Panel ziehen und dort an der gewünschten Stelle ablegen. Das sieht doch ganz okay aus.
Als nächstes erstelle ich eine CSS-Datei für das Styling der Testimonial-Card. Diese Datei werden wir in der Block-Konfiguration konfigurieren, damit sie im exportierten Code des Blocks enthalten ist.
Die neue CSS Datei muss ich zur index.html hinzufügen, damit sie auch bei der Arbeit im Projekt berücksichtigt wird.
Die Testimonial Card muss jetzt durch Verwendung der Action „Block“ als Gutenberg Block definiert werden. Hier muss zumindest eine eindeutige ID festgelegt werden. Ein lesbarer Titel ist natürlich auch sinnvoll.
An dieser Stelle registriere ich auch eine neue Kategorie für meine Blocks, um sie im Gutenberg zu organisieren.
Lass uns mal sehen, ob unser Block grundsätzlich funktioniert.
Dazu exportiere ich das Plugin. In diesem Moment erstellt Pinegrow den eigentlichen Code für mein WordPress Plugin. In Zukunft wird Pinegrow den Code bei jedem Export aktualisieren.
Das neue Plugin muss jetzt aktiviert werden. Dazu verlasse ich Pinegrow und wechsele zur Plugin Liste.
Sehen wir mal, ob der neu erstellte Block jetzt zur Verfügung steht. Da ist er. Sieht genau so aus, wie in Pinegrow. Okay. Im Frontend prüfe ich jetzt das Markup. Wie du siehst, haben wir hier sehr sauberes HTML. Genau das Markup, dass ich selbst erstellt habe. Das sieht okay aus.
Zurück in Pinegrow, öffne ich die CSS Datei, die für den Block vorgesehen ist. Sie ist natürlich noch leer.
Da das hier kein CSS Tutorial ist, kopiere ich den vorbereiteten Code einfach ins Projekt. Im GitHub Repository kannst du dir den Code genauer ansehen.
So, jetzt sieht die Card schon besser aus.
Es fehlen noch die SVGs für die Sterne. Die kopiere ich auch schnell hier rein.
Die Platzhalter entferne ich. Um den HTML Code des markierten Elements zu bearbeiten, brauche ich nur „C“ auf der Tastatur zu drücken. Jetzt kann ich die Änderung leicht vornehmen und das Fenster mit „Esc“ wieder schließen.
Die Anzahl der Sterne wird über ein data-Attribut gesteuert. Das Attribut füge ich jetzt zu diesem Element hinzu. Wenn ich den Wert des Attributes ändere, verändert sich die Anzahl der angezeigten Sterne. Auch halbe Sterne sind möglich. Das zeigen und verstecken der Sterne funktioniert rein mit CSS.
In der Block Konfiguration muss die CSS Datei angegeben werden. Nur dann wird die Datei auch bei der Verwendung des Blocks geladen. Leider muss man in der Plugin-Version von Pinegrow den Pfad von Hand eintippen.
Damit die Inhalte des Blocks in WordPress editiertbar sind, weise ich nun dem Template weitere „Block Attribute“ Actions zu. Hier ist wieder eine id und ein Titel nötig. Mit der Option „Use as“ lege ich fest, wie der eingegebene Wert verwendet wird. Für das Rating wähle ich hier „Attribute“ aus und gebe „data-rating“ ein, also genau das attribute welches im CSS verwendet wird um die Sterne zu steuern.
In den Block „Attribute Options“ lege ich den Control type fest – damit wird felstgelegt, welchen Feldtyp man in WordPress für diesen Wert sieht. Ich kann hier außerdem einen Standardwert festlegen.
Für die übrigen Textelemente lege ich ebenfalls Block Attribute Actions fest.
Lass uns mal ausprobieren, ob es funktioniert.
Den Block hatte ich ja schon auf einer Seite eingefügt.
Mal sehen, wie der jetzt aussieht. Prima!
In der Siedebar kann ich die Felder sehen, die ich als Block Attribute hinzugefügt habe. Alles klar. Das Rating kann ich bequem ändern.
Da es sich hier um einen Regulären React-Block handelt, ändern sich die Inhalte des Blocks in Echtzeit, ohne dass eine Verzögerung entsteht. Außerdem kann ich direkt inline Änderungen an den Texten vornehmen.
Und auch im front end sieht alles super aus.
Ich werde mal schnell noch drei Spalten hinzufügen, damit drei Testimonials nebeneinander passen.
Ich benutze hier einfach schnell den Columns Block.
Noch schell ein bisschen die Inhalte ändern…
Das ist unser regulärer Testimonial Block. Das funktioniert sehr gut. Jedoch haben diese statischen Recact Blocks einen großen Nachteil. Das zeige ich dir jetzt.
Sagen wir, wir haben diesen Block überall auf der Website eingesetzt und nun soll eine Änderung am Design vorgenommen werden. Oder es soll noch ein Firmenlogo angezeigt werden. Was passiert, wenn ich jetzt die Struktur des Blocktemplates nachträglich verändere? Testweise füge ich einfache einen Absatz mit Dummytext ein.
Also nochmal exportieren und schauen, wie sich unsere vorhandenen Testimonials verhalten. Oh oh! Jede einzelnen Instanz zeigt jetzt einen Fehler an: „This block contains unexpected or invalid content.“ Dazu ein Button, um Block recovery durchzuführen.
Jetzt muss ich bei jedem einzelnen Testimonial Block auf der gesamten Website diesen Button drücken, die Seite speichern und erst dann sind die gewünschten Anpassungen im Frontend sichtbar. Glücklicherweise werden die Blöcke im Frontend weiterhin korrekt angezeigt, aber eben ohne die Template-Anpassung.
Ich ändere die Block Struktur im Template und exportiere nochmal. Natürlich habe ich das gleiche Problem wieder.
Das ist der große Nachteil bei den regulären statischen Blocks.
Deshalb sind die Hybrid Blocks so genial. Sie haben alle Vorteile der regulären React Blocks, aber ohne den Nachteil des statisch innerhalb der Instanz gespeicherten Templates.
Erstellen wir also jetzt einen Hybrid Block.
Ich dupliziere in Pinegrow die Section samt Block. So können wir mit dem Markup weiterarbeiten und können den regulären Block einfach behalten. Lass mich kurz die Hintergrundfarbe ändern. Im Properties Panel benenne gebe ich noch einen Namen ein. Ich füge auch noch eine Überschrift ein, damit ich die Blöcke in der Vorschau besser unterscheiden kann. Beides dient nur der Organisation und hat keine Auswirkung auf den exportierten Code.
Jetzt passe ich die Block Action an und ändere die ID und den Titel des Blocks.
Jetzt kommt der wichtige Schritt: Wie du siehst, ist der „Block type“ hier auf „Auto“ eingestellt, das heißt die globalen Einstellungen bestimmen, welche Block-Typen exportiert werden. In diesem Projekt ist „Regular JavaScript/React“ als Block type definiert. Aber ich kann pro Block eine andere Wahl treffen. Bei disem Block wähle ich jetzt „Hybrid“ aus.
Das ist schon alles. Die übrigen Block-Attribute können so bleiben. Auch deren IDs müssen nicht geändert werden, weil sie automatisch unter der Block ID namespaced sind.
Probieren wir den Hybrid Block aus.
Du siehst, ich kann den Inhalt inline ändern. Der Block verhält sich also genau wie der reguläre React Block. Das liegt daran, dass hier ebenfalls im Editor React für das Anzeigen des Blocks verwendet wird. Allerdings wird das Template nicht mehr direkt mit der einzelnen Block-Instanz gespeichert. Und das Rendering im Frontend wird dynamisch mit PHP erzeugt.
Das bringt den entscheidenden Vorteil: Wir können die Struktur des Blocks nachträglich ändern, ohne bei den einzelnen Instanzen nochmal ein Block-Recovery durchzuführen.
Lass uns das testen. Wieder füge ich im Template einfach einen neuen Absatz ein. Wie du siehst, ist der Block sofort aktualisiert. Und auch im Frontend ist die Änderung sofort sichtbar. Es ist kein Block-Recovery nötig. Das wird dir sehr viel Kopfschmerzen in großen Projekten ersparen, wenn nachträgliche Änderungen zu machen sind.
Sehen wir uns jetzt den ACF Blocktyp an.
Erst lege ich die Felder an, die wir benötigen.
Als Bedingung für die Anzeige der Felder wähle ich „Block“ aus. Da ich aber noch keinen ACF Block erstellt habe, kann ich die Zuordnung noch nicht machen.
Erstellen wir also den ACF Block für das Testimonial.
Wieder dupliziere ich eine vorhandene Section. Das Markup des Blocks bleibt ja gleich.
Die Block ID muss ich zwingend anpassen, damit es keine Kollision mit dem bestehenden Block gibt.
Zu Organisationszwecken ändere ich auch den Namen im Strukturpanel.
Jetzt muss ich die Block Atribute Actions entfernen, denn die Daten kommen ja jetzt aus ACF. Dazu verwende ich die Action „Display ACF Field“.
Bei „Field“ muss ich exakt den key verwenden, den ich auch in den soeben in den ACF Feldern festgelegt hatte. Beim Rating setze ich wieder das data Attribute. Die Textfelder ersetzen einfach den Content.
Beim Avatar Bild finden wir in der ACF Dokumentation einen nützlichen Hinweis, wie wir an das Bild kommen und den Image-Tag samt srcset Attribut rendern können. Wie du siehst ist hier die WordPress Core Funktion wp_get_attachment_image() dokumentiert. Das halte ich in diesem Fall für die Beste Lösung. Pinegrow stellt diese Funktion als Action zur Verfügung, weshalb ich sie sehr einfach hinzufügen kann.
Die Attachment ID können wir über die ACF Funktion get_field() abfragen. Ich hatte allerdings vergessen, das Image-Feld für Avatar anzulegen. Das hole ich schnell nach.
Beachte, das ich bei „Return Format“ „Image ID“ auswählen. Denn die gerade eingefügte Action braucht ja eine ID, um das Attachment zu laden.
Da ich vergessen habe, das Plugin zu exportieren, kann ich in den „Location Rules“ noch immer nicht den Testimonial Block auswählen. Also nochmal zurück zu Pinegrow. Wir müssen ja sowieso den Block-Typ noch auf „ACF“ setzen. Und das Plugin exportieren.
Okay, endlich kann ich die Location Rule setzen.
Zeit, unseren brandneuen ACF Block zu testen.
Da ist er. Die Felder sind initial leer, weil ich keine Standard-Werte gesetzt habe. Die Felder kann ich jetzt in den Block-Einstellungen einfügen.
Rating funktioniert. Dank den ACF Feldeinstellungen ist die Eingabe von 1 bis 5 begrenzt.
Wenn ich jetzt die Felder ausfülle, bemerkst du eine deutliche Verzögerung, bis die Werte auch im Block gerendert wurden. Das ist der Fall, weil dies ein PHP Block ist und meine Eingaben erst zum Server geschickt werden und der ACF Block neu geladen werden muss. Außerdem kann ich die Texte nicht inline bearbeiten. Kein großes Problem, aber ein deutlicher Unterschied zu den React-basierten Blocks die wir bisher hatten.
Über das Bleistift Icon kann ich die Formularansicht umschalten. Das ist eine Alternative zur Eingabe im rechten Panel und man hat deutlich mehr Platz.
Machen wir nochmal den Test auf Änderungen in der Template Struktur. Wieder füge ich einfach einen Absatz ein.
Die Änderung ist – wie schon beim Hybrid Block – sofort im Frontend verfügbar. Und auch im Backend ist es nicht nötig, ein Block-Recovery durchzuführen.
Die bisherigen Blocks waren gedacht zur individuellen Eingabe einzelner Testimonials direkt auf einer Seite.
Als Beispiel für den Dynamischen Block-Typ möchte ich einen simplen Block erstellen, der vorhandene Testimonials auflistet.
Dazu erstelle ich per ACF einen Custom Post Type „Testimoial“.
Die vorhandenen Felder für den ACF Block verwende ich einfach nochmal für diesen Custom Post Type.
Dann erstellen wir einen Dynamischen Block der die Testimonial CPTs im selben Design wie bisher anzeigt.
Ich beginne mit dem CPT „Testimonial“.
Dann ändere ich die vorhandene Fieldgroup ein bisschen ab. Erstmal sinnvoll benennen.
Dann die Location Rule ergänzen, damit die Felder bei dem gerade erstellten CPT zur Verfügung stehen.
Zurück in Pinegrow dupliziere ich nochmal eine vorhandene Section – das kennen wir ja schon.
Dann die Block Optionen und den Block Type anpassen.
Da es nun eine Query Loop geben wird die eine Liste von Testimonials ausgibt, füge ich einen Wrapper um die Testomonial-Card hinzu. Dann verschiebe ich durch Copy&Paste die Block Action von der Card in den Wrapper.
Die Card selbst nutze ich nun, um die Smart Action „Show Posts“ hinzuzufügen. Damit kann ich die Query zur Datenbankabfrage erstellen.
Als Loop Type verwende ich „custom query“, denn ich möchte ja selbst bestimmen, welcher Post Type abgefragt wird. Das mach ich indem ich bei „Post type“ die ID des vorhin mit ACF angelegten Post Types angebe. Mehr muss ich hier für unseren Fall gar nicht konfigurieren.
Da ich vorhin den ACF Block dupliziert hatte, habe ich hier bereits die korrekten Actions um die Feldwerte zu laden. Das heißt, so sollte der neue Block bereits funktionieren.
Da noch gar keine Testimonial Posts existieren, zeigt mir der Block einen entsprechenden Hinweis.
Also lass uns schnell ein paar Testimonials erstellen…
Hey, der dynamic Block spuckt tatsächlich die Testimonials aus. Aber das sieht noch nicht so schön aus. Das lässt sich leicht ändern, indem ich dem Wrapper zwei ACSS Utility Klassen hinzufüge.
Fertig.
Jetzt hast du einen Überblick über die verschiedenen Block Types die du mit Pinegrow erstellen kannst. Das tolle ist, dass du sie problemlos im Projekt kombinieren kannst.
Mein Favorit ist der Hybrid Block. Das ist die Standardeinstellung für meine Projekte. Reguläre Blocks vermeide ich aufgrund der Problematik des Block-Recovery.
Wenn du fragen hast, schreibe einfach einen Kommentar.
Viel Spaß bei deinen Pinegrow Projekten!
