Inhaltsverzeichnis
- Das Interview
- Wann habt ihr angefangen, mit dem Site Editor zu arbeiten? Und wann habt ihr zum ersten Mal überlegt, ein Block-Theme zu erstellen?
- Das war eine große Entscheidung. Was war der Auslöser für eure Begeisterung?
- Was ist passiert, als ihr angefangen habt?
- Was waren eure anfänglichen Bedenken gegenüber full site editing?
- Warum habt ihr dann darauf gewettet, obwohl ihr wusstet, dass das eine große Investition erfordert?
- Hast du das Gefühl, dass ihr euch mit Full Site Editor in einem Wettlauf der Funktionen befindet?
- Welchen Rat würdest du WordPress-Entwicklern geben, die darüber nachdenken, mit Full-Site-Editing zu arbeiten?
- Wie lange hat es gedauert, bis du dich an die neu eingeführten Begriffe gewöhnt hast?
- Hast du noch einen letzten Tipp für alle Leser?
Beim Release der Greyd.Suite im Jahr 2021 war klar, dass wir uns einer Herausforderung stellen würden. Der WordPress-Block-Editor wurde (und wird) ständig weiterentwickelt. Neue Funktionen werden zuerst im Gutenberg-Plugin entwickelt und getestet. Wenn sie sich bewährt haben, werden sie in den WordPress-Core integriert. Das Bearbeiten kompletter Websites wird damit immer weiter optimiert.
Jedes Mitglied unseres Teams könnte stundenlang über die breite Palette an Funktionen sprechen, die die Greyd.Suite zu bieten hat. Da wir aber kurz vor dem Release unseres Block-Themes stehen, halten wir es für einen guten Zeitpunkt, Jakob Trost, unseren CTO, zu den Überlegungen dahinter zu befragen und darüber, mit den Entwicklungen des WordPress-Cores Schritt zu halten.
Das Interview
Wann habt ihr angefangen, mit dem Site Editor zu arbeiten? Und wann habt ihr zum ersten Mal überlegt, ein Block-Theme zu erstellen?
Ich weiß nicht mehr, wie lange das her ist, aber das war, als wir die erste Beta-Phase oder wahrscheinlich sogar die ersten Design-Diskussionen über den Site Editor gesehen haben. Das war der Punkt, an dem wir automatisch wussten, dass wir da mitgehen müssen. Wir sagten uns: “Das müssen wir machen!”.
Das war eine große Entscheidung. Was war der Auslöser für eure Begeisterung?
Unsere Lösung war bereits blockbasiert. Indem wir so nah wie möglich am WordPress Core bleiben und die nativen Funktionen von WordPress nutzen, stellen wir sicher, dass unsere Kunden immer von den neuesten Entwicklungen in WordPress profitieren und von einer maximalen Kompatibilität zu anderen WordPress-Tools profitieren können. So können sie mit einem Produkt arbeiten, das immer auf dem neuesten Stand der Technik ist.
Davon abgesehen: Wenn du so nah wie möglich am WordPress Core bleibst, vermeidest du Abwärtskompatibilitätsprobleme und technische Altlasten.
Wir wussten also, dass wir auch eine Lösung für die vollständige Bearbeitung von Websites anbieten mussten. Für uns war damals klar, dass der Site Editor die Zukunft sein würde.
Unser Gedanke war buchstäblich: Okay, das ist die nächste Sache, die WordPress macht. Es sieht gut aus. Es bietet eine Menge Möglichkeiten. Natürlich muss es noch überarbeitet werden. Aber das wird das Ding für die Zukunft sein, und wir müssen damit arbeiten, während es sich weiterentwickelt.
Was ist passiert, als ihr angefangen habt?
Wir haben nicht sofort losgelegt, als der Site Editor in seiner ersten Rohphase war, weil er damals weniger Möglichkeiten bot als unsere eigene Lösung.
Wir haben gewartet, bis der Funktionsumfang des Site Editors zumindest ansatzweise dem entsprach, was wir mit unserer Lösung bereits erreichen konnten. Es hätte keinen Sinn gemacht, in die Arbeit mit dem Site Editor zu investieren, wenn es eine Verschlechterung gegenüber dem bedeutet hätte, was wir unseren Kunden bereits anbieten.
Nach ein paar Monaten in der ersten Version sahen wir den Fortschritt und begannen, auf der Grundlage des Site Editors zu entwickeln.
Was waren eure anfänglichen Bedenken gegenüber full site editing?
Der erste Gedanke, den wir hatten, war: “Uh oh, das ist genau das, was wir machen!” Das ist in den ersten Momenten etwas beängstigend. Denn du denkst: “Okay, das ist eine wertvolle Funktion, die wir bereits gebaut haben. Ein gutes Beispiel dafür ist die Option, Stile global zu definieren.
Aus technischer Sicht bietet unsere Erweiterung ähnliche Möglichkeiten wie die Global Styles bei Full Site Editing. In unserem klassischen Theme haben wir CSS-Variablen im Customizer untergebracht, sodass die Nutzer diese CSS-Variablen anpassen können. Und später, im Content Bereich, kannst du diese Variablen einfach auswählen, was es einfacher macht, das gesamte Design auszutauschen. Das ist so ziemlich das Gleiche, was die Global Styles im Site Editor tun.
Code-mäßig hat das WordPress-Entwicklungsteam beschlossen, dass Entwickler (noch) keinen direkten Zugriff auf die Core Global Styles haben dürfen. Das hat uns vor eine Herausforderung gestellt! Um unseren Kunden die granularen Gestaltungsmöglichkeiten zu bieten, die sie bereits von unserem klassischen Theme gewohnt sind, mussten wir eine ganz neue Erweiterung entwickeln: Greyd Styles. Abgesehen davon, dass das für uns technisch ziemlich aufwändig ist, finden wir, dass es für den Nutzer nicht ideal ist, was die Benutzerfreundlichkeit angeht. Aber das ist ein gutes Thema für ein separates Interview auf Entwicklerebene.
Und dann war da noch das Thema Template Bearbeitung, die den zweiten Teil des Site Editors ausmacht. Auch dafür haben wir bereits eine Lösung angeboten. Wir hatten dynamische Templates, sogenannte System Templates. Nutzer unseres klassischen Themes hatten bereits die Möglichkeit, die 404-Seite, den Footer, das single Template, kategoriebasierte Archive und vieles mehr zu bearbeiten. Das alles konntest du bereits in der Greyd.Suite erstellen.
Das bedeutet, dass es von der Funktionalität her nicht unbedingt etwas Neues war. Aber es war eindeutig etwas Neues in Bezug auf die Benutzeroberfläche. Natürlich unterscheiden sich die technischen Details von dem, was wir gebaut haben.
Warum habt ihr dann darauf gewettet, obwohl ihr wusstet, dass das eine große Investition erfordert?
Letztendlich sind wir davon ausgegangen, dass, wenn viele erfahrene Entwickler und Designer daran arbeiten, es wahrscheinlich viel besser wird als das, was wir bauen, und wir uns mehr auf die komplexeren Dinge konzentrieren können, die unsere Suite ausmachen. Denn die Möglichkeiten, die der Site Editor zur Erstellung von Templates und zur zentralen Steuerung von Patterns und Design bietet, sollten meiner Meinung nach standardisiert sein. Sie hätten schon immer standardisiert sein sollen, waren es aber nicht.
Je mehr wir darüber nachdachten, was Full Site Editing für uns bedeutete, desto klarer wurde uns, dass es eigentlich gut für unsere Kunden und damit auch für uns war. Wir hatten bereits Erfahrung. Wir wussten bereits, was wir taten.
Der erste Gedanke war also: Okay, das ist beängstigend. Damit wird ein großer Teil dessen weggenommen, was unser Produkt wertvoll macht. Aber andererseits hat es uns dazu gebracht, den Wert, den wir unseren Kunden bieten, zu überdenken. Manche haben uns fälschlicherweise als Pagebuilder wahrgenommen. Tatsächlich sind wir aber eine viel umfassendere Lösung, und die Pagebuilding Funktionen sind ein zusätzlicher Vorteil zu dem, was wir bereits tun.
Dass die Pagebuilding Funktionen weitgehend vom WordPress-Core übernommen wurden, ist eigentlich eines der besten Dinge, die uns und unseren Kunden passieren konnten. Denn dadurch wird die Greyd.Suite flexibler denn je. Full Site Editing ist der sauberste und am wenigsten aufgeblähte Ansatz, den ich je gesehen habe, um deine gesamte Website visuell zu bearbeiten. Es wurde mit vielen guten Ideen und wirklich guten Gedanken von den brillantesten Leuten im WordPress-Ökosystem entwickelt.
Hast du das Gefühl, dass ihr euch mit Full Site Editor in einem Wettlauf der Funktionen befindet?
Das tun wir tatsächlich, aber es hat überhaupt nicht den negativen Beigeschmack, den der Ausdruck “Wettlauf” hat. Es ist ein aufbauender und sehr spannender Prozess. Wir arbeiten jetzt noch enger mit dem WordPress-Core Team zusammen, um sicherzustellen, dass unser Produkt mit den neuesten Full Site Editing Funktionen kompatibel sind.
Bevor Funktionen zum Block-Editor in WordPress hinzugefügt werden, werden sie zuerst im Gutenberg-Plugin entwickelt. Das bedeutet, dass wir in der Regel rechtzeitig wissen, was auf uns zukommt. Neben den Greyd Styles haben wir Greyd Blöcke. Eine Reihe von Blöcken, die im Vergleich zu den Core Blöcken erweiterte Funktionen bieten.
In beiden Fällen gilt: Wenn eine Funktion in den WordPress-Core kommt, nehmen wir sie aus unseren heraus.
Welchen Rat würdest du WordPress-Entwicklern geben, die darüber nachdenken, mit Full-Site-Editing zu arbeiten?
Mein Rat an WordPress-Entwickler/innen, die ein Block-Theme entwickeln wollen, ist, sich zunächst mit dem Editor selbst und seiner Funktionsweise vertraut zu machen. Es gibt verschiedene Online-Ressourcen, darunter den WordPress Codex und die WordPress.tv-Tutorial-Videos.
Sobald du ein grundlegendes Verständnis des Site Editors hast, kannst du darüber nachdenken, wie du ihn nutzen kannst, um deine eigenen Produkte und Dienstleistungen zu verbessern.
Wie lange hat es gedauert, bis du dich an die neu eingeführten Begriffe gewöhnt hast?
Ah, ja. Das hat einige Mühe gekostet. Vor allem, weil es am Anfang in der WordPress-Community viele Diskussionen über Namenskonventionen gab. In unserem Umfeld sprechen die Leute immer noch vom Full Site Editor. Intern nennen wir ihn manchmal immer noch mit dem Akronym FSE. Diese Gewohnheit müssen wir uns erst noch abgewöhnen, denn wir lieben unsere Akronyme.
Hast du noch einen letzten Tipp für alle Leser?
Ja! Wir haben auch jede Menge Video-Tutorials über die Arbeit mit dem Site Editor und dem Block Editor erstellt. Außerdem werden wir bald ein ganz neues Demo-Video von der Greyd.Suite veröffentlichen. Melde dich für unseren Newsletter an, wenn du wissen willst, wann diese online veröffentlicht werden.
