Entwicklung von Addons für Gutenberg. Die ehrliche Erfahrung aus erster Hand – mteleben.com
Last Updated on 11/10/2021 by MTE Leben
Das Team von MTELeben beobachtet Gutenberg-Redakteur schon sehr lange. Wir waren wirklich an dem Produkt interessiert und warteten auf den besseren Moment, um unser erstes Produkt zu entwickeln, das für diesen neuen WordPress-Editor geeignet ist.
Zu Beginn dieses Sommers hat Matt Mullenberg endlich die Gutenberg-Editor-Integration in WordPress v.5.0 auf der WCEU vorgestellt, und genau zu diesem Zeitpunkt haben wir entschieden, dass es endlich soweit ist.
Unser Team hat sich nicht allzu viele Gedanken über den Zweck unseres ersten Plugins gemacht. Stattdessen haben wir einfach unser beliebtestes meistverkauftes JetElements-Plugin genommen und beschlossen, ein ähnliches Addon für Gutenberg zu erstellen, das die Widget-Blöcke zum Hinzufügen von mehr Inhalten zu Gutenberg-erstellten Seiten einführt.
Als Ergebnis haben wir JetGuten erstellt, das erste Addon für den Gutenberg-Editor.
In diesem Artikel möchten wir unsere Erfahrungen mit der Erstellung teilen. Lesen Sie also weiter, um mehr über unsere Erfahrung bei der Entwicklung des JetGuten-Addons für Gutenberg zu erfahren.
Ich hoffe, es hilft Ihnen, wenn Sie gerade planen, Ihre eigenen Produkte für diesen Seiteneditor zu entwickeln.
Für Gutenberg entwickeln: Es geht um JavaScript, nicht um PHP Noch 2015 sagte uns Matt Mullenweg: „Lerne JavaScript. Tief”.
Es war der Disclaimer, der uns zeigte, in welche Richtung sich alle WordPress-Entwickler bewegen sollten, um mit der Zeit Schritt zu halten.
Und jetzt, bei der Entwicklung des Produkts für Gutenberg Editor, sehen wir den Wahrheitsgehalt dieser Aussage.
Hier ist zum einen die Nutzungsstatistik für verschiedene Programmiersprachen in JetElements, einem der beliebtesten Plugins unseres Teams für Elementor.
Hier ist die Statistik zu JetGuten, unserem neuen Addon für Gutenberg.
In der ersten Version von JetGuten brauchten wir PHP nur, um den klassischen „Wrapper“ des Plugins zu erstellen, CSS- und JS-Dateien zu aktivieren und für mehrere Implementierungen von AJAX-Callbacks.
Für alles, was das Aussehen und die Blockeinstellungen betrifft, haben wir JavaScript verwendet.
Das heißt natürlich nicht, dass wir PHP überhaupt nicht brauchen. Das Backend wird weiterhin in den komplexeren Blöcken vorhanden sein, die mit Posts, Taxonomien und APIs von Drittanbietern arbeiten. Der größte Teil des Codes wird jedoch in JavaScript geschrieben.
Die Abkehr von einigen der alten Standards zum Erstellen von WordPress-PluginsIm Laufe der Jahre, in denen unser Team mit WordPress arbeitet, haben wir eines der grundlegendsten Prinzipien der Programmierung verwendet – „trenne immer die Logik von der Präsentation“.
Näher an WordPress lässt sich eine solche Trennung in zwei verschiedene Aspekte unterteilen:
Die Trennung von Templates und Dateien mit den Logiken findest du in jedem WordPress-Theme. Das gleiche gilt für die Plugins. Das beliebteste E-Commerce-Plugin WooCommerce kann diese Aussage leicht veranschaulichen.
Der Ordner „Vorlagen“ enthält die Dateien für die Präsentation.
Der Ordner „Includes“ besteht hauptsächlich aus den Dateien mit den Logiken.
Sie können die Vorlagen des Themes mit dem Child-Theme überschreiben. Und das gleiche gilt für die Templates der Plugins – jedes gut gemachte Plugin (zB WooCommerce) kann auch einige seiner Templates sowohl vom Theme als auch vom Child-Theme überschreiben lassen.
Dies gibt sowohl Front-End-Webentwicklern, die die Themen erstellen, als auch Endbenutzern die Freiheit.
Sie haben tatsächlich keine Grenzen beim Ändern des HTML-Layouts. Und die Funktionalität bleibt immer gleich.
Diese Freiheit wurde uns im Gutemberg-Redakteur – zumindest vorerst – entrissen. Die Logik ist eng mit dem Erscheinungsbild verknüpft, weshalb Sie das Design nicht einfach aus dem Thema überschreiben können.
Sowohl Front-End-Entwickler als auch Endbenutzer sind eingeschränkt, indem CSS nur zum Ändern des Aussehens der Blöcke verwendet wird.
Wir können nicht leugnen, dass es auch ein sehr praktisches Werkzeug ist. In einigen Situationen ist jedoch die Möglichkeit, das HTML-Layout der Blöcke zu bearbeiten, dringend erforderlich.
Keine Grenzen beim Erstellen von SchnittstellenEiner der wichtigsten Vorteile von Gutenberg ist aus unserer Sicht die völlige Freiheit der Entwickler bei der Erstellung von Schnittstellen für die Interaktion mit dem Editor.
Nun, wir' Ich bin etwas übertrieben, wenn ich die völlige Freiheit erwähnt – dem Entwickler stehen 2 Hauptstandorte zum Hinzufügen seiner benutzerdefinierten Oberflächenelemente zur Verfügung.
Die erste Position ist der Textkörper des Blocks im Editor.
Der zweite ist der Seitenbereich mit den Einstellungen, auch „Blockinspektor“ genannt.
Sie können beliebige Elemente verwenden, um das Erscheinungsbild des Inhalts an diesen Orten zu verwalten. Ich meine, sowohl die Standardversionen, die bereits in Gutenberg enthalten sind, als auch die benutzerdefinierten.
Zum einen haben wir für den Animated Box-Block ein Steuerelement hinzugefügt, das den Block zur bequemeren Bearbeitung auf die Vorder- oder Rückseite schaltet, und es in die Symbolleiste des Blockkörpers eingefügt.
Ein solcher Ansatz gibt den Entwicklern so viel Freiheit bei der Verwaltung der Schnittstelle.
Ja, es kann sich von dem unterscheiden, das bei der Entwicklung der Jet-Plugins für Elementor verwendet wurde. Es gibt uns jedoch noch mehr Werkzeuge.
Die Freiheit, Blöcke im Editor und im Frontend einzuführen Wenn Sie Gutenberg mit einem anderen bestehenden Page Builder vergleichen möchten, werden Sie feststellen, dass er einen weiteren großen Vorteil hat. Ich spreche von der Möglichkeit, das Erscheinungsbild des Blocks im Editor und im Frontend zu trennen.
Etwas ähnliche Funktionen sind in Elementor verfügbar, und ehrlich gesagt hat jeder andere Seitenersteller der alten Schule Inhalte im Editor und im Frontend ursprünglich anders dargestellt. Es gibt viele Beispiele: wie Divi, Visual Composer usw.
Allerdings gibt nur Gutenberg den Entwicklern die volle Freiheit, die Inhalte im Frontend und Backend so darzustellen, wie sie es wollen und brauchen.
Wir müssen zwei Methoden für jeden Block in Gutenberg implementieren: edit und save.
- edit Methode ist für das Aussehen des Blocks verantwortlich im Editor;
- save Methode lässt uns definieren, wie der Block in die Datenbank geschrieben wird.
- Gutenberg-Redaktionshandbuch;
- Mehrere gute Beispiele für Erstellen von Blöcken bei GitHub;
- Leute, die eng mit der WordPress-Community verbunden sind.
- Gutenbergs Repository.
- der Code für jeden der Blöcke ist ziemlich kompliziert und lang (zB Bannerblock in JetGuten hat 530 Zeilen Code ); Wenn Sie sich entschieden haben, den Code für mehrere Blöcke in einer der Dateien zu behalten, denken Sie noch einmal darüber nach;
- Viele Beispiele für Gutenberg sind in ESNext-Syntax geschrieben, und das bedeutet, dass Sie Sie können sie nicht direkt verwenden, ohne sie in Ihrem Code in die ES5-Syntax zu konvertieren.
Gutenberg aktualisiert Sensibilität Der Gutenberg-Editor entwickelt sich ständig weiter und ändert sich mit den Updates. Aus diesem Grund können die Updates manchmal Probleme mit dem von Ihnen erstellten Produkt verursachen.
Unser Team hat in 3 Wochen JetGuten für Gutenberg erstellt. In dieser Zeit gab es 2 Releases neuer Gutenberg-Plugin-Versionen (v.3.3.0, v.3.4.0).
Und für jede dieser Veröffentlichungen war unser Team gezwungen, weitere Korrekturen im Code des JetGuten-Plugins hinzuzufügen, da es Änderungen in der API des Plugins gab.
Dies ist jedoch nicht wirklich ein großes Problem, denn Gutenberg-Entwickler informieren alle vorab über die Änderungen in den kommenden Releases. Sie können solche Benachrichtigungen in der Konsole des Browsers sehen.
Das heißt, wenn Sie ein eigenes Plugin entwickeln, haben Sie alle Möglichkeiten, die potenziellen Probleme mit der Kompatibilität rechtzeitig zu beheben.
Auf Kundenseite gibt es bereits viele Informationen über die Vor- und Nachteile von Gutenberg.
In diesem Artikel haben wir jedoch versucht, unsere Arbeitserfahrungen mit Gutenberg zu teilen von der Entwicklerseite.Es ist schon ziemlich offensichtlich, dass Gutenberg ein sehr leistungsstarkes Produkt ist, das den Workflow von WordPress-Entwicklern verändern wird.
Seine Flexibilität eröffnet jedem neue Möglichkeiten und erfordert auch mehr Fähigkeiten und Kenntnisse (wie tiefe JavaScript-Kenntnisse, aktivere Nutzung moderner Entwicklungstechniken, größere Verantwortung für die Benutzeroberfläche usw.).
Wir glauben, dass WordPress 5.0 nicht nur für Endbenutzer, sondern auch für WordPress-Entwickler vieles verändern wird.
Mit anderen Worten, der Entwickler ist nicht durch die Bedingung eingeschränkt, dass der Block im Editor genauso aussehen muss wie im Frontend.
Stattdessen können die Entwickler selbst wählen, wie die Blöcke im Editor dargestellt werden.
Um genauer zu verstehen, wie dies in der Praxis hilft, schauen wir uns den Bildvergleichsblock des JetGuten-Plugins genauer an.
Dieser Block bietet die Möglichkeit, zwei Bilder im Frontend zu vergleichen, indem das Steuerelement umgeschaltet wird. Diese Funktionalität wird mit Hilfe der Bibliothek von Drittanbietern implementiert.
Das Hauptproblem bei diesem Block im Editor besteht darin, dass bei jeder Änderung der Einstellungen des Blocks das Skript, das für das Umschalten des Steuerelements verantwortlich ist, unter Berücksichtigung der neuen Einstellungen erneut initialisiert werden muss.
Um den Editor nicht mit den zusätzlichen Aktionen in der edit-Methode zu überladen, haben wir HTML-Markup erstellt, das dem Ergebnis entspricht, das Sie im Frontend haben werden. Es gibt jedoch keine Option zum Umschalten der Steuerung.
In der Methode save speichern wir nur das erforderliche Markup für das zu initialisierende Drittanbieter-Skript.
Tatsächlich können Sie auf diese Weise alle erforderlichen Komponenten des Blocks im Builder einstellen, ohne im Browser ein Übergewicht zu erzeugen. Und am Front-End macht diese Methode es möglich, den vollwertigen Block mit allen Funktionen zu erhalten.
Das Fehlen von Best PracticesEines der Dinge, die uns bei der Entwicklung eines Plugins für Gutenberg auch einige Schwierigkeiten bereitet haben, ist das Fehlen der sogenannten „Best Practices“ zum Erstellen von Blöcken für Gutenberg.
Nachfolgend haben wir die Quellen aufgelistet, die uns immens geholfen haben:
Für unser Team haben sich diese Quellen aus praktischer Sicht als die nützlichsten herausgestellt.
Es ist jedoch offensichtlich, dass sie nicht alle Fragen abgedeckt haben, die im Entwicklungsprozess auftauchten. Und das führte dazu, dass wir in manchen Situationen komplett blind geflogen sind.
Deshalb sind wir uns fast sicher, dass sich beim Öffnen des Codes des JetGuten-Plugins in Zukunft viele Lösungen als irrational und manchmal sogar als falsch herausstellen werden.
Ich möchte nicht sagen, dass dies die negative Seite des Gutenberg-Plugins ist – das ist normal, wenn das Produkt gerade ausgerollt wurde.
Mit jedem Tag werden mehr und mehr Gutenberg-zentrierte Tutorials und Anleitungen erstellt. Ich denke, an Best Practices wird es in etwa einem Jahr nicht mangeln.
Aber für den Moment der Entwicklung von JetGuten stellte sich dies als echte Komplikation für unser Team heraus.
Sensibilität für Code-Updates Wir leugnen nicht, dass dieses Problem von dem oben bereits benannten herrührt. Vielleicht hat es nicht einmal mit Gutenberg zu tun. Wir haben uns jedoch dem Problem mit der Empfindlichkeit der Blöcke gegenüber Änderungen im HTML-Markup gestellt.
ZB verursacht fast jede Änderung im Markup der Methode save die Probleme in den zuvor hinzugefügten Blöcken.
Wenn Sie sich im Entwicklungsprozess befinden, ist dies nicht wirklich der Rede wert, aber die Probleme können mit den Updates auftauchen. Die Änderungen im Markup des Blocks können dazu führen, dass er für alle Clients beschädigt wird, die ihn vor der Aktualisierung hinzugefügt haben.
Die automatischen Build-Tools sind von entscheidender BedeutungDie automatischen Build-Tools wie Gulp, Grunt, NPM usw. sind für jeden Webentwickler zum unvermeidlichen Teil des Lebens geworden.
Die Entwickler einiger eigenständiger WordPress-Plugins könnten jedoch manchmal darauf verzichten.
Für den Fall, dass das Plugin nur mehrere JavaScript-Codezeilen und ein bisschen CSS-Code enthält, wird die Verwendung der automatischen Build-Tools Ihren Workflow nur komplizierter machen.
Solche Situationen waren völlig akzeptabel, wenn Sie das Plugin mit mehreren kleinen Shortcodes erstellt haben, um sie im Editor weiter zu verwenden.
Wenn Sie das Plugin derzeit mit Gutenberg kompatibel machen oder die Shortcodes in Blöcke umwandeln möchten, können Sie dies ohne die automatischen Build-Tools nicht tun.
Hier sind die Hauptgründe dafür: