Ein Gespräch mit Fränk Klein
Derzeit verändert sich Vieles in der WordPress-Welt, wir alle müssen unsere gewohnten Pfade verlassen. Einige Änderungen liegen schon hinter uns, andere kommen noch auf uns zu.
Was bedeutet das jetzt für Freelancer und Agenturen, die Themes für Kunden bauen? Wie geh ich’s an, wenn ich heute ein neues Projekt auf den Tisch kriege?
Ich habe mich dazu mit Fränk Klein unterhalten. Er ist Principal Engineer bei Human Made und Gutenberg-Pionier der ersten Stunde. Sein erstes Kundenprojekt mit Block Editor-Support baute er noch bevor Gutenberg in WordPress integriert wurde. Er ist Contributor für das Gutenberg-Plugin, mit einem Fokus auf Block-Based Themes.
Fränk, Du hast mal gesagt, dass der Wettbewerb unter den WordPress-Themes in den letzten Jahren vor allem über Features gelaufen ist und kaum übers Design. Und dass das in der Zukunft anders werden wird, weil Themes und Plugins wieder klarer voneinander getrennt sein werden. Das würde mir persönlich gut gefallen.
Wer über die Zukunft redet, kann eigentlich nur raten. Aber ich glaube, dass die Zeichen ganz klar auf eine Trendwende hindeuten was WordPress-Themes angeht.
Wenn wir über die Kombination von Themes und Plugins reden, glaube ich, dass die meisten Nutzer gar nicht groß nachdenken. Sie aktivieren ein Theme, und wenn das ein Plugin braucht, dann wird das eben installiert. Nicht-technische Nutzer interessiert es nicht, wie ihre Seite zustande kommt. Das Endresultat zählt.
In Zukunft kann man attraktive Themes anbieten, die keinen externen Pagebuilder brauchen. Eben weil WordPress diesen Pagebuilder schon enthält. Ich denke, dass das ein großer Wettbewerbsvorteil für Block-Based-Themes ist. Man muss nichts weiteres installieren, braucht keine Plugin-Updates zu machen und so weiter.
Das Schwierige ist ja auch, dass die Pagebuilder-Plugins nicht miteinander kompatibel sind. Jeder Pagebuilder baut sich seine eigene Welt.
Genau. Mit WordPress 5.9 wird die Lingua Franca ganz klar Blocks sein. Wenn ich eine Seite habe, die mit Elementor gebaut wurde und das Plugin dann deaktiviere, dann ist mein Content weg. Klar ist noch alles in der Datenbank, aber sichtbar ist es nicht mehr.
Mit einem Block-Based Theme kann ich von einem Theme zum anderen wechseln und mein Content ist noch immer da. Klar, Themewechsel laufen nicht immer ohne Probleme, aber die Inhalte bleiben. Und das ist die Hauptsache.
Das Geschäft mit Pagebuilder-Themes funktionierte bisher sehr gut. Was schätzt du, wie geht es da weiter?
Wenn wir über Theme-Shops reden, so machen die sich ja schon abhängig von Elementor und Konsorten, wenn sie kompatible Themes anbieten. Vom wirtschaftlichen Standpunkt her ist das riskant.
Deshalb denke ich, dass Entwickler sich gerne aus dieser Abhängigkeit befreien werden, wann sie die Möglichkeit dazu haben.
Das gilt natürlich auch für Endnutzer. Wer ein Theme kauft, macht sich von dem Theme-Shop abhängig was Updates und Support betrifft. Da will man sich ungern auch noch von Plugin-Anbietern abhängig machen.
Aber könnte ich nicht auch in ein Block Based Theme zehn Slider und fünf Accordions integrieren?
Block-Based Themes haben noch immer eine functions.php Datei. Rein technisch gesehen kann man also noch immer ein Theme und einen ganzen Rattenschwanz an Plugins zusammen kombinieren, und dann als “Site Package” verkaufen. Aber ich denke, dass das in Zukunft viel schwerer sein wird.
Warum?
Wie gesagt, Themes werden zukünftig ganz aus Blocks bestehen. Das macht es für viele Plugins schwer, sich da weiter zu behaupten.
Zum einen gibt es neue technische Herausforderungen für die Entwickler. Der Schwerpunkt in der Plugin-Entwicklung verlagert sich von PHP zu JavaScript. Zum anderen stellt der Block Editor neue Anforderungen an das User-Interface.
Ich denke nicht, dass die Nutzer es in zwei bis drei Jahren noch gut finden werden, wenn sie ihren Slider in einem separaten Admin-Screen suchen müssen. Wenn sich die Nutzer mal an das Site Editor-Interface gewöhnt haben, werden sie nicht zurück wollen.
Ich glaube außerdem, dass es beim Kombinieren von Theme und Plugins nicht nur darum geht, den Nutzern Features zu bieten (50 Sliders! 300 Templates!).
Die Kombinationen erleichtern auch die Arbeit der Entwickler. Da gibt’s eine Hand voll “kompatible” Plugins, die kommen dann rein ins Paket und gut ist.
Kannst du das noch ein bisschen genauer erklären?
Für Plugin-Autoren ist es schwer Interface-Elemente zu erstellen, die sich nahtlos in ein Theme einfügen.
Das erste Problem ist, wie diese Elemente eingebunden werden. Plugin-Entwickler nutzen Shortcodes, Widgets, ersetzen ganze Templates, oder nutzen Template Tag-Filter. Für Endnutzer ist das nicht immer einfach zu durchblicken.
Das zweite Problem ist die Gestaltung dieser Elemente. Entweder passen die Styles des Plugins nicht zum Theme, und stechen deshalb als Fremdkörper heraus. Oder aber man nutzt keine vom Plugin bereitgestellte Styles, und das Element sieht halbfertig aus.
Am einfachsten ist es deshalb, wenn Theme-Autoren angepasste Styles für Plugin-Elemente im Theme zur Verfügung stellen. Oft werden diese Element auch direkt in den Template-Code integriert.
Das heißt, wenn ich eine bestimmte Auswahl an Plugins immer wieder hernehme, dann kann ich das in meinem Theme-Design berücksichtigen und die Plugin Elemente sehen immer gut aus.
Ja, genau. Das Problem ist einfach, dass es so wahnsinnig viele Plugins gibt. Ein Theme für alle zu optimieren ist unmöglich. Deshalb geben viele Themes an, welche Plugins unterstützt werden. Oder Theme-Autoren gehen noch weiter und bündeln ein Auswahl an Plugins mit dem Theme.
Was wird mit Full Site Editing anders?
Full-Site Editing erleichtert die Arbeit für beide Seiten, für Theme-Autoren und für Plugin-Autoren.
Weil sich die Frage der Einbindung von Plugin-Elementen ins Theme gar nicht mehr stellt, denn alle Plugins müssen Blocks nutzen. Die lassen sich leichter ins Design integrieren.
Theme-Autoren haben die Möglichkeit, globale Elemente zu definieren. Also Schriftart und -größe, Text-und Linkfarben usw. Damit werden die Plugin-Blocks zumindest ansatzweise aussehen wie der Rest des Templates.
Custom Blocks aus Plugins fügen sich besser in ein bestehendes Styling-System ein. Der Block-Editor bietet verschiedene Möglichkeiten an, Blocks zu stylen, und Plugin-Autoren können diese für ihre Blocks nutzen. So können z.B. die Farben, die Schriften usw. vom Endnutzer einfach angepasst werden können.
Die Richtung ist also ganz klar eine bessere Integration von Themes und Plugins. Gerade das Block-Directory des WordPress-Projekts ist darauf ausgerichtet, dass Endnutzer schnell und einfach zusätzliche Blocks installieren können. Und die sollen dann natürlich auch gut aussehen, sowohl im Editor wie auch im Template selbst.
Wir werden also in Zukunft die klassische Theme-Plugin-Kombi immer weniger sehen?
Das wäre schön. Ich glaube allerdings, dass viele Autoren ihre Themes mit einem extra Plugin for zusätzliche Blocks kombinieren werden. Sieht man ja zum Beispiel bei Blocksy. Aber grundsätzlich werden die Themes auch ohne diese Plugins funktionieren. Die zusätzlichen Blocks sind ein Extra, aber nicht das Kernelement.
Mit Block-Based Themes wird es einfacher werden, eigene Third-Party Blocks in ein Theme zu integrieren. Man muss also nicht immer alles bundlen.
Ich glaube, für die Nutzer sind auch Vorlagen ziemlich wichtig. Gerade wenn sie nicht so technik-affin sind und was brauchen, mit dem sie schnell ein Ergebnis sehen. Wie schaut es damit aus?
Bisher war es für Theme-Autoren nicht ganz einfach, Demo-Content bereitzustellen. Es gab keine allgemein verbindliche technische Methode dafür und das Installieren von Demo-Content war für die Nutzer häufig recht umständlich.
Mit dem Block Editor kamen dann die Block-Patterns, mit denen man sich mit einem Klick eine schöne Vorlage in den Editor laden kann. Block-Patterns sind für die Nutzer leicht zu handhaben und für Theme-Autoren einfach aufzusetzen.
Mit dem Full Site Editing kommen jetzt noch die Seiten-Templates dazu. Es geht sozusagen noch einen Schritt weiter. Theme-Autoren können solche Seiten-Templates zur Verfügung stellen und – das ist neu – die Nutzer können diese Templates direkt aus dem Editor heraus anpassen und verändern.
Bisher waren diese Templates PHP-Dateien, die man nur über einen Code-Editor bearbeiten konnte. Der normale Nutzer kam da gar nicht ran.
Was glaubst du wird sich dadurch verändern?
Ich könnte mir vorstellen, dass vorgefertigte Templates nicht mehr einen so hohen Stellenwert für End-Nutzer haben werden. Über den neuen Site Editor kann man selbst Templates verändern, da braucht man dann keine 300 Vorlagen mehr.
Die Themes, die auf Pagebuildern basieren wie z.B. Elementor, sind ja eigentlich nur ein Header und Footer für das Elementor Template. Klar ist es da schwer hervorzustechen. Die Themes haben ja keine Persönlichkeit. Hier spielen die Vorlagen eine wichtige Rolle.
Wenn ich mir jedoch Frost ansehe oder Aino dann denke ich, dass Design wichtiger werden wird. Nicht nur das Design des Themes selber, sondern auch wie flexibel das Design ist.
Ein Design-System sozusagen. Das ist Musik in meinen Ohren. Ich hab mal Design studiert her und tu mich schwer damit, Design als reine Dekoration zu sehen. Es wäre toll, wenn in Zukunft wieder mehr Raum für gutes, funktionales Design wäre.
Ja, ich glaube schon, dass Nutzer mehr auf gutes Design achten werden. Eine Webseite soll sofort gut aussehen, ohne dass man viel herumschrauben muss, oder einen langwierigen Setup über sich ergehen lassen muss.
So, jetzt kommt die Frage, auf die wahrscheinlich alle gewartet haben. Wenn ich heute ein neues WordPress-Projekt plane – wie geh ich das an? Full Site Editing und Block Based Themes sind noch nicht fertig für den Einsatz in Kundenprojekten. Aber irgendein olles Theme nehmen fühlt sich auch nicht richtig an.
Entwickler können jetzt Hybrid-Themes bauen, also PHP-Templates mit theme.json und Template Editor-Support. Ich bin gerade dabei die letzten Arbeiten an einem Online-Kurs speziell für WordPress-Entwickler zu machen. Der Kurs zeigt anhand praktischer Video-Lektionen, wie man die Features in WordPress 5.8 effizient in bestehende Themes integrieren kann.
Hier ist das Theme, das in dem Kurs gebaut wird: Hybrid Twenty Twenty
Es ist das Twenty Twenty Theme, angepasst für 5.8.
Der Kurs ist jetzt im Early Access, und für die ersten Studenten gibt es einen ordentlichen Rabatt.
LIVE WEBINAR MIT FRÄNK KLEIN
WordPress Themes mit FSE
Einführung in die Theme-Erstellung mit Full-Site Editing
Fränk zeigt uns eine kurze Demo der FSE Features in 5.9 und baut ein simples Blog mit Blocks. Anschließend könnt ihr eure Fragen stellen.
Datum 23. September 2021 · Uhrzeit 15 bis 16.30 Uhr
Der Link öffnet das Meeting. Teilnehmen können alle, die Interesse haben.
Du hast unseren Blog-Lesern ein tolles Angebot gemacht – ein Live-Webinar zum Theme Full Site Editing (siehe Kasten oben). Vielen Dank!
Gern geschehen! Ich möchte gern etwas Wissen vermitteln und freu mich drauf, wenn ich Fragen beantworten kann. Am meisten freue ich mich aber darauf mich mit Gleichgesinnten auszutauschen.
WordPress-Entwickler stehen vor großen Umbrüchen. Mein Ziel ist es, möglichst viele Freelancer und Agenturen dazu zu bringen, sich der Herausforderungen zu stellen, die dieser Umbruch mit sich bringt.
Wir müssen unser bestehendes Wissen an die neuen Gegebenheiten anpassen. Ich will versuchen, diesen Wandel so schmerzlos wie möglich zu machen. Durch meine Kurse, aber ich schreibe auch Artikel, mache Podcasts und so weiter. Live
Ich kann bestätigen, da sind ein paar sehr lesens- und hörenswerte Sachen dabei. Eine Liste mit Links findet ihr am Ende des Artikels.
Vielen Dank, Fränk, für das Gespräch. Ich bin sehr gespannt wie es weitergeht und wohin uns die Veränderungen führen.
Ich freue mich auch auf die Zukunft. Und mit WordPress 5.8 sind wir ja auch schon teilweise da angekommen.
LINKS
Kurse
Artikel
- What I Learned Building a Full-Site Editing Theme
- Implementing Global Styles in Block-Based Bosco
- The Query Block: The Loop in Block-Based Themes
Videos
- Full-Site Editing Preview: Introduction to the Query Block
- Full-Site Editing Preview: Navigation Menus
- Full-Site Editing Preview: The What, Why, and How of Global Styles
- Full-Site Editing Alignment Controls
Podcast