Bereits im Dezember 2015 wurde die Parole „Lerne JavaScript gründlich“ ausgerufen. Doch hat dies bisher eher zur Folge gehabt, dass Headless-Konzepte oder Funktionen für den WP-Admin stärker mit JavaScript entwickelt wurden. Das Frontend von Websites und Blogs ist trotz Block-Themes eher statisch und passiv geblieben. Auf den meisten WordPress-Websites sind Kommentare (wenn überhaupt noch aktiv) oder das Kontakt-Formular meistens die einzige Interaktion, die Besuchende mit den Inhalten und indirekt mit den Betreibenden haben.

Je mehr eine Website in Richtung E-Commerce tendiert, wird es interaktiver:

  • Anfrage-Formulare
  • Filterung von Angebotslisten
  • Der Umgang mit dem Warenkorb

Über Apps und soziale Netzwerke haben sich Menschen an verschiedene Interaktionen mit digitalen Inhalten gewöhnt. Es werden Sprechblasen im Chat geliked oder Inhalte mit Stickern versehen. Das Navigieren innerhalb von digitalen Anwendungen geschieht ggf. auch über das Wischen nach links und rechts. Chat-Interfaces ziehen in Anwendungen ein, und Stories (wie bei Instagram oder WhatsApp) werden im Vollbild konsumiert und anschließend zum regulären Ablauf der Anwendung zurückgekehrt.

Daher besteht der Bedarf, den Nutzenden für WordPress einen Weg anzubieten, der hilft, der Entwicklung zu folgen. Es muss also mehr JavaScript ins Frontend, damit alles interaktiver werden kann.

Die Ladestrategie

Der browserseitige Ansatz ist es, die Bereiche, die interaktiv werden sollen, beim Seitenaufruf als leeres DIV auszuliefern und nach dem Seitenaufbau im Browser eine Anfrage an eine Schnittstelle (Admin-AJAX oder WP-REST) zu schicken. Sobald die API geantwortet hat, wird dann der leere Platzhalter durch den eigentlichen Inhalt ersetzt. Hier wird erst der Rahmen und nachgelagert der Inhalt geladen.

Wenn diese Bereiche Nebenfunktionen sind, mag das vielleicht nicht so schlimm sein, aber wenn es sich z.B. um die Liste von Produkten in einer Kategorie handelt, ist es äußerst unschön, und die potenziellen Kunden sitzen ständig vor Lade-Animationen. Dies lässt eine Website langsam erscheinen.Dieser Ansatz hat auch den Nachteil, dass Suchmaschinen oft das JavaScript nicht ausführen und damit niemals die dynamisch geladenen Inhalte zu Gesicht bekommen. Somit ist die Strategie für Websites mit Marketing-Zielen eine schlechte Wahl, da es beim SEO zu großen Nachteilen führt.

Ein deutlich schönerer Weg ist es, um beim vorherigen Beispiel zu bleiben, die Produktliste mit allen Details als fertiges HTML direkt beim eigentlichen Seitenaufruf mit auszuliefern, und – nachdem die Seite vom Browser aufgebaut wurde – „nur noch“ die Filter, Navigations-Elemente oder den Warenkorb-Button interaktiv zu machen.

Dieser Weg ist sowohl technisch als auch gefühlt schneller. Denn das, was von Interesse ist, also der Hauptinhalt, wird sofort geliefert, inklusive dem „Rahmen“. Bis die Pfeile zum Blättern oder der Warenkorb-Button „gebraucht werden“, vergehen ein paar Sekunden, während die Besuchenden die Inhalte lesen und bewerten. Innerhalb der Lesezeit können die interaktiven Funktionen im Hintergrund aktiviert werden.

Nach dem Laden fängt der Spaß an

Unabhängig von der initialen Ladestrategie können derartige JavaScript-getriebene Listen, wenn erstmal geladen, beim Blättern durch Beiträge oder Produkte das Neuladen des kompletten „Rahmens“ vermeiden. Aber auch das Filtern von Inhalten ist eine beliebte Funktion. Dazu muss die Liste eine Art „Gedächtnis“ bekommen. Sie muss sich merken, welche Filter angeklickt wurden, dies darstellen und gleichzeitig die dargestellte Liste anpassen, und dazu ggf. neue Daten von WordPress anfordern. Diese Art von Gedächtnis wird technisch „State-Management“ genannt und ist z.B. auch bei Warenkörben oder umfangreichen Kontaktformularen sehr hilfreich.

Die sogenannte serverseitige Generierung (Server-Side-Rendering) von vollständigen Produkt- oder Beitragslisten war schon immer die Hauptfunktion von WordPress als Content-Management-System (CMS). Auch gab es mit jQuery schon Ansätze, Elemente nachträglich mit Funktionen zu belegen (Hydration). Diese Ansätze waren dabei limitiert in Umfang und Stabilität. Auch war das Realisieren von State-Management mit einigem Aufwand verbunden, nie richtig rund, und hat nur begrenzt die Zusammenarbeit zwischen Plugins erlaubt.

Frontend und Backend haben verschieden Anforderungen

Im Dezember 2018 ist mit React eine JavaScript-Bibliothek in den WP-Admin eingezogen, um den Block-Editor zu realisieren. Dies war eine umstrittene Entscheidung auf verschiedenen Ebenen, z.B. hinsichtlich Lizenz, Ecosystem oder Komplexität. Einer der Punkte war die unterschiedliche Vorliebe von Entwicklern. Manche zogen mit VueJS eine andere Bibliothek vor, die es leichter macht, auch kleine Komponenten zu erstellen. Für den Block-Editor im WP-Admin, bzw. die neuen Anwendungsbereiche wie den Site-Editor, hat sich am Ende doch React durchgesetzt.

Auch wenn der Kern von WordPress meinungsstark ist, wurde nie die Entscheidung gefällt, React zu dem Werkzeug fürs Frontend zu machen. Es wäre auch nicht richtig gewesen, alle Themes in Zukunft zu Single-Page-Applications zu machen (das gesamte Frontend wird komplett per JavaScript gesteuert und geladen, z.B. bei einem Webmailer). Wenn der Anwendungsfall dies erfordert, kann WordPress das Backend für so ein Projekt sein.

Die breite Masse der Websites ist nach wie vor inhaltsgetrieben und hat nur das Bedürfnis, kleine Bereiche verspielter oder funktioneller zu gestalten. Sie liegt also irgendwo genau zwischen den beiden Extremen.

Der WordPress-Weg ist eine neue API

Anstatt einfach alle Websites zu zwingen, React oder eine andere Bibliothek zu nutzen, hat WordPress einen diplomatischen und flexiblen Weg geschaffen, um alle Bedürfnisse für moderne, interaktive Website-Bausteine zu erfüllen – eine typische Aktion für das Projekt

Die Lösung ist die „Interactivity API“: eine Sammlung von Funktionen und Infrastruktur, die von etwas kleinem wie eine Lightbox-Funktion für Bilder bis hin zu Single-Page-Anwendungen alles in einem Standard bündelt und gleichzeitig auch die Grundlagen schafft, damit verschiedene Plugins zusammenarbeiten können. Das Ganze ist tief  in die aktuelle Block-Architektur integriert und erbt von ihr die Vorteile und Abhängigkeiten.

Auch wenn jQuery erst vor kurzem aus seinem Schlaf aufgewacht ist, wird das treue Werkzeug in dem neuen Paradigma abgelöst. Natürlich wird der klassische Weg nicht zerstört, aber der neue und funktionsreichere Weg wird vorangestellt. Die Interactivity API verhindert auch nicht die Kombination mit jQuery. Sie ist explizit neutral und kann ganz nach eigenem Geschmack mit dem nativen JavaScript oder einer Bibliothek genutzt werden.

Wie schon angerissen, basiert die Interactivity API auf den Blöcken, die in WordPress seit Version 5.0 maßgeblich sind, was dazu führt, dass die Erstellung und Weiterentwicklung durchaus eine größere Lernkurve erfordert. Bei der Entwicklung wurde großes Augenmerk auf die PHP-Gemeinschaft gelegt, die nach wie vor die Masse der Website-Projekte weltweit betreut.

Das WordPress-Projekt hat an sich auch einen hohen Anspruch an Kompatibilität (für bestehende Websites und auch zwischen verschiedenen Plugins) und Übersetzbarkeit. Für all diese Punkte werden durch die serverseitige Generation die bestehenden und bewährten Funktionen genutzt und müssen nicht erneut gelernt werden. Das bekannte Prinzip der Hooks and Filter wird entsprechend genutzt, und die Funktionen für die Übersetzbarkeit stehen weiterhin zur Verfügung.

Das ganze Paket ist dabei nicht plötzlich veröffentlicht, sondern schon in WordPress 6.4 als eine nicht-öffentliche Funktion ausgerollt und mit der Zoom-Funktion für Bilder (auch Lightbox genannt) in großem Umfang getestet worden. Mit Version 6.5 ist das Ganze nun öffentlich und kann frei genutzt werden.

Eine große Bandbreite von Funktionalitäten

So breit wie die Wünsche sind auch die Möglichkeiten der Interactivity API.

Kosmetische oder spielerische Interaktion

Die einfachste Version einer Interaktion ist z.B. das Aufklappen eines Elements in einem FAQ-Bereich oder das Öffnen eines Mega-Menüs. Hierbei benötigt WordPress als Backend keine Rückmeldung, was gerade passiert ist, da die Interaktion nur im Browser stattfindet und damit alles erledigt ist.

Weitere Ideen für kosmetische Interaktionen:

  • Slider
  • Karte mit Standorten und Filter
  • (Web-)Stories wie bei Instagram oder WhatsApp

Kommunikative Interaktion

Wenn nach einer Interaktion, z.B. einem Klick auf einen „Like-Button“ oder einer Reihe an Interaktionen wie bei einem Kontaktformular, ein Datenpaket an WordPress geschickt werden soll, macht es die State-Verwaltung einfach, zunächst alle Daten zu sammeln und dann in einer Anfrage an WordPress zu schicken. Auch ist es möglich, in der Zwischenzeit eine Information anzuzeigen, dass „der Computer arbeitet“. Gefolgt von der Rückmeldung vom Backend über Erfolg oder Probleme mit dem Datenpaket.

Weitere Ideen für kommunikative Interaktionen:

  • Chat-Funktion
  • Quizze

Interaktionen mit Seiteneffekten

Diese beiden Interaktionstypen sind recht geradlinig und laufen innerhalb einer Funktionalität bzw. eines Plugins ab. WordPress wird aber auch vermehrt zur Plattform für komplexere Anwendungen wie einem Lern-Management-System (LMS) oder Onlineshops. Ein Argument für das Nutzen von WordPress als Plattform ist dabei immer wieder die Flexibilität und die große Auswahl an Plugins, um die Anwendung genau für das Projekt anzupassen. Dazu müssen Plugins zusammenarbeiten.

Durch die Nutzung der State-Verwaltung können, ähnlich wie bei den Hooks und Filtern in PHP, nun auch Plugins im Frontend bei Interaktionen aufeinander aufbauen. Dafür löst jede Veränderung im State einen „Event“ aus, das dann vom eigentlichen Plugin genutzt wird, um die Hauptaufgabe, z.B. das Hinzufügen eines Produkts in den Warenkorb, auszuführen. Genau so kann ein weiteres Plugin reagieren, um zu schauen, ob der Warenkorbwert den Mindestbestellwert erreicht hat, um mit einem Pop-Up darüber zu informieren, dass die Bestellung abgeschickt werden kann. Oder ein Verschönerungs-Plugin für ein LMS kann ein Einhorn quer über den Bildschirm fliegen lassen, wenn eine Lektion des Onlinekurses erfolgreich abgeschlossen wurde.

Dabei muss jedes Plugin nur den State „beobachten“, und das Plugin, auf das aufgebaut wird, weiss gar nichts davon, was die anderen Plugins tun oder wissen wollen. Die komplette Kommunikation findet automatisch über den State statt, und die Datenbasis ist für alle gleich. Für dauerhafte gute Zusammenarbeit dürfen die Haupt-Plugins natürlich nicht ständig die Felder im State umtaufen. Auch wenn der Austauschort klar ist, würde dies zu Problemen führen.

Weitere Ideen für gemeinsame Interaktionen:

  • Online-Communities (z.B. mittels BuddyPress)
  • Dashboards

Funktionsprinzip per Interactivity API

Wenn über den Block-Editor ein interaktiver Block in eine Seite oder einen Beitrag hinzugefügt wird, wird ein HTML-Kommentar als Platzhalter mit den nötigen Informationen und Einstellungen für diesen einen Block in den Inhalt geschrieben und entsprechend in der Datenbank abgelegt.

Hier ein Beispiel für so einen Kommentar durch einen Beispiel-Block mit dem Namen „Mein Blockname“, wie er in der Listenansicht und der zusätzlichen CSS-Klasse „meine-klasse“ zu sehen ist.

Je nach Einstellungen des Blocks können die Eigenschaften und Metadaten sehr umfangreich werden. Dabei wird kein strukturelles HTML gespeichert. Der Platzhalter ist ein Kommentar und im Frontend erstmal unsichtbar.

Wenn die entsprechende Seite nun im Frontend aufgerufen wird, wandelt WordPress den Platzhalter in das nötige HTML um. Dieses HTML enthält alle Elemente, um sofort im Browser alles darstellen zu können plus eine ganze Reihe an unsichtbaren Informationen, die für die Interaktivität nötig sind. Dieses HTML kann man auch im Inspektor im Browser ansehen. Zusätzlich werden von WordPress die dazugehörigen CSS- und JavaScript-Dateien automatisch an den Browser übergeben.

Das Beispiel ist ein einfacher Knopf, der beim ersten Klick einen kleinen Absatz einblendet und anschließend immer aus- und einblendet.

Abbildung: Funktionsprinzip per Interactivity API

 

Neben den unsichtbaren Informationen ist auch die CSS-Klasse „meine-klasse“ wiederzufinden, so wie es von allen anderen Blöcken bekannt ist. Der Platzhalter wurde durch umfangreiches HTML-Markup ersetzt. Diese kann je nach Datenlage mehr oder weniger umfangreich sein. Somit können genau nach Wunsch und immer aktuell die passenden Informationen ausgespielt werden.

Ein kleiner technischer Einblick

Um nun das HTML mit dem JavaScript in Verbindung zu bringen, werden die Data-Attribute genutzt. Bei dieser Art der Verwendung spricht man in der Fachsprache von „Directives“. 
In dem umschließenden DIV befindet sich das „data-wp-interactive“-Attribut, welches mit seinem Wert „my-blocks“ signalisiert, dass alles innerhalb die Interactivity API nutzen wird und die ganzen „data-wp-*“-Attribute mit diesem Namespace anzusprechen sind.

Das nächste Attribut, das wir im Quellcode finden, ist „data-wp-context“. Dies sieht in der HTML-Schreibweise sehr merkwürdig aus, da es als JSON codierte Informationen sind. In diesem Fall setzen wir ein einfaches isOpen : false. Dieses Attribut ist quasi das niedergeschriebene Gedächtnis des Blocks. Nachdem der Browser den Button gerendert hat, wandelt er das JSON in den lebendigen State um und arbeitet anschließend damit. Es ist eine Einbahnstraße, um Informationen in den State zu bekommen.

Eine Zeile weiter stoßen wir auf das Attribut „data-wp-watch“. Dies ist ein Beispiel für eine Aktionen, die immer ausgelöst wird, wenn sich im State etwas verändert. In diesem Fall ist es eine ganz einfache Funktion, die Daten ins Log schreibt. Hier können auch andere Plugins einen Beobachter abstellen.

Für das nächste interessante Attribut gehen wir einige Zeilen tiefer und treffen im DIV auf „data-wp-on–click“, das den Button repräsentiert. Hier sehen wir einen Vertreter für eine ganze Reihe an Attributen, die bereitstehen, um auf die tatsächlichen Interaktionen durch die Besuchenden zu reagieren. In diesem Fall geht es um einen Klick auf den Button. Sobald der Button angeklickt wird, kümmert sich die Interactivity API darum, die zugehörige Aktion „Toggle“ zu finden und führt diese aus. Dieser Aktion sind keine Grenzen gesetzt. Anders als im klassischen JavaScript sollte sie aber nicht direkt den DOM verändern. Sie sollte Validationen und Operationen durchführen und die Ergebnisse an den State übergeben. Denn nur, wenn sie dies tut, kann die nächste Gruppe von Attributen ihre volle Wirkung entfalten.

Im Eröffnungs-Tag des Absatzes, im unteren Teil, finden wir das „data-wp-bind–hidden“-Attribut, ein weiterer Vertreter einer Gruppe an Attributen, die dem Muster „data-wp-bind—*“ folgen. Darum handelt es sich um ein spezielles Attribut, das HTML-Attribute programmatisch im Browser verändern kann.

Konkret wird in diesem Fall das Hidden-Attribut genutzt, um den Absatz zu steuern. Im Ladezustand ist das Attribut aktiv, wie im HTML zu sehen ist. Durch die Bindung des Attributs an den State über den Wert „!context.isOpen“ wird das Attribut immer zum Gegenteil davon gemacht, was im State für ein Wert steht.

  • State: isOpen = true | Absatz: hidden = false bzw. Attribut fehlt -> der Absatz wird sichtbar
  • State: isOpen = false | Absatz: hidden = true bzw. Attribut ist gesetzt -> der Absatz wird versteckt

Umdenken für mehr Möglichkeiten

Die Art und Weise, die Darstellung einer Funktion an einen State zu hängen und nach Aktionen wie einem Klick nicht die Darstellung zu verändern, sondern den State, erfordert ein erhebliches Umdenken.

Als Belohnung dafür bekommt man deutlich interessantere Funktionalitäten, und es macht Spaß, diese in eine Website zu integrieren. Da fast alles damit möglich ist, empfiehlt es sich, Schritt für Schritt in das Thema einzusteigen. Auch können wir uns in den kommenden Monaten auf immer mehr Plugins freuen, die zeigen werden, wie Sie die neue Interactivity API nutzen können.

Fazit: die Interactivity API für WordPress

Dieser Artikel beschränkt sich auf die Vorstellung der Interactivity API und auf die Erkundung der verschiedenen Möglichkeiten, um ein generelles Verständnis aufzubauen. Wer nun richtig in die Entwicklung von interaktiven Blöcken starten möchte, findet im Entwicklungshandbuch und im Entwicklungsblog umfangreiche Schritt-für-Schritt Anleitungen. Das CLI-Werkzeug für eigene Blöcke wurde ebenfalls erweitert, um bei der Erstellung von interaktiven Blöcken zu unterstützen.

Titelmotiv: Bild von zeeve platform auf Pixabay

Ralf Wiechers
Letzte Artikel von Ralf Wiechers (Alle anzeigen)

Große Auswahl an günstigen Domain-Endungen – schon ab 0,08 € /Monat
Jetzt Domain-Check starten