Katzen hüten – Lektionen, die bei der Entwicklung für die WordPress-Umgebung gelernt wurden

Als Elementor 3.0 vor über einem Jahr, im Jahr 2020, veröffentlicht wurde, sahen wir darin einen bedeutenden Schritt in Richtung eines schnelleren und deutlich leistungsfähigeren Editors. Das stimmt zwar, aber diese Version hatte auch wichtige, unerwartete Folgen – sie führte dazu, dass eine beträchtliche Anzahl von Websites nicht mehr funktionierte, und schadete ganz offen unserem Ruf. Nach dieser Veröffentlichung mussten wir eine Reihe von Korrekturen vornehmen, um diese Seiten wieder zum Laufen zu bringen. Darüber hinaus hat uns die gesamte Erfahrung gezeigt, dass wir unser gesamtes Test- und Freigabeverfahren überarbeiten mussten. Obwohl schmerzhaft, zahlt sich dieser Prozess heute aus, wie sich in dem außergewöhnlichen Rückgang der Probleme, insbesondere der kritischen, zwischen der Veröffentlichung unserer Versionen v3.0 und v3.4 widerspiegelt:

Jetzt, da wir uns dem einjährigen Jubiläum von Elementor 3.0 nähern, ist es ein guter Zeitpunkt, zurückzublicken und die Verfahren zu untersuchen, die wir eingeführt haben, um sicherzustellen, dass die Probleme, die mit der Veröffentlichung einhergehen, nicht erneut auftreten. Um unserer Community gegenüber so transparent wie möglich zu sein, möchte ich den Hintergrund der Probleme rund um das Release 3.0 untersuchen, die Schritte, die wir im vergangenen Jahr unternommen haben, wie wir stabile Releases sicherstellen konnten und was die Zukunft bringt. Aber zuerst ist es wichtig, etwas über die Geschichte von Elementor und die Herausforderungen zu verstehen, denen wir bei der Entwicklung eines komplizierten, anspruchsvollen Plugins innerhalb der WordPress-Umgebung gegenüberstehen.

Elementor und die WordPress-Challenge

Als wir im Juni 2016 die erste Version von Elementor veröffentlichten, waren wir nur ein paar „Kinder“, die gerne Plugins entwickelten und Menschen beim Erstellen von Websites halfen. Dies war nicht unser erstes Produkt, wir hatten bereits einige Plugins entwickelt, die von der WordPress-Community verwendet wurden. Als wir jedoch an Elementor arbeiteten, waren wir überzeugt, dass wir etwas Besonderes entwickeln. Wie sich herausstellte, hatten wir Recht – nur wenige Monate nach unserer ersten Veröffentlichung hatten bereits Zehntausende von Benutzern Elementor installiert und nutzten es zum Erstellen von Websites weltweit.

Seitdem ist unser Unternehmen in jeder Hinsicht gewachsen, mit mehr Entwicklern, mehr Benutzern und mehr Funktionen. Mit diesem Wachstum gingen eine Reihe neuer Probleme einher, darunter ein wachsendes Technologiedefizit, da wir uns auf dringende Probleme konzentrierten und wichtige, aber alltäglichere Probleme beiseite legten.

Der Umgang mit diesen Problemen wurde durch die allgemeine Herausforderung durch die Natur der WordPress-Umgebung noch schwieriger.

Als offene Plattform bietet WordPress eine Reihe großer Vorteile für Entwickler. Es gibt ein paar Hindernisse, die die Veröffentlichung überwachen und verlangsamen. Konzepte werden erdacht, entwickelt und dem Repository hinzugefügt. Benutzer testen, testen und beurteilen diese Produkte, wobei der Markt entscheidet, welche erfolgreich sind und welche nicht. Diese Geschwindigkeit und Einfachheit haben jedoch ihren Preis.

Es gibt wenig Einheitlichkeit im WordPress-Umfeld und keinen geordneten Arbeitsablauf. Webentwickler können die Umgebung ihrer Websites frei definieren und dabei eine große Auswahl an Plugins, Themen usw. verwenden. Das bedeutet, dass WordPress-Websites unzählige Kombinationen von Plugins, Themen und Serverkonfigurationen enthalten.

Darüber hinaus bedeutet die Einfachheit des Veröffentlichungsprozesses und das Fehlen robuster Bereitstellungstools, dass WordPress-Entwickler moderne Veröffentlichungskonzepte wie CI/CD, Canary Deployment und Feature Flags nicht nutzen können.

Während Offenheit Teil der Schönheit von WordPress ist, stellt die inhärente Vielzahl von Site- und Serverkonfigurationen Entwickler vor eine echte Herausforderung, wenn es darum geht, Plugin-Konflikte und spezifische Serverprobleme zu berücksichtigen.

In unserem Fall, als Elementor für immer mehr Websites verwendet wurde, verlangsamte die Notwendigkeit, all diese verschiedenen Kombinationen zu unterstützen, unseren Veröffentlichungszeitplan und ließ uns sogar zögern, neue Funktionen zu entwickeln. Unnötig zu sagen, dass diese Situation nicht akzeptabel war und wir die Dinge aufrütteln mussten.

Neue Funktionen entwickeln, ohne die alten zu brechen

Alle oben genannten Faktoren haben uns vor das Dilemma gestellt, wie wir uns weiterentwickeln und verbessern können, ohne die Arbeit derer zu beeinträchtigen, die sich bereits auf Elementor verlassen?

Wir begannen damit, einige kleine Änderungen in unserem Veröffentlichungsprozess vorzunehmen. In Elementor 1.5 haben wir damit begonnen, Entwicklern Zugriff auf Beta-Versionen anzubieten. Wir taten dies über Github und andere Communities, die es uns ermöglichten, vor einer Veröffentlichung Feedback zu erhalten, das angibt, wie diese Version mit einer Vielzahl von Kombinationen aus Plugin/Design/Umgebung interagiert, und uns frühzeitig auf Inkompatibilitäten aufmerksam macht. Dieser Ansatz funktionierte eine Zeit lang gut, aber als Elementor noch mehr wuchs, stellten wir fest, dass dies nicht ausreichte.

Zu diesem Zeitpunkt hatten wir die Schwelle von fünf Millionen Installationen überschritten. Dies war zwar eine unglaubliche Leistung, bedeutete aber auch, dass wir jetzt dafür verantwortlich waren, dass all diese Websites reibungslos funktionierten.

Mit der Veröffentlichung von Elementor 3.0 spitzten sich die Dinge schließlich zu. In dieser Version haben wir uns entschieden, einige alte, scheinbar veraltete Funktionen fallen zu lassen und DOM-Elemente zu entfernen, um die Ladegeschwindigkeit zu erhöhen. Dies geschah zumindest teilweise als Reaktion auf berechtigte Beschwerden, dass wir das System unnötig belasten.

Leider führte diese Änderung dazu, dass eine Reihe von Websites, die sich auf von uns gelöschten Code stützten, während des Upgrades zusammenbrachen. Trotz unserer Bemühungen, Drittentwickler in den Prozess einzubeziehen, blieben diese Fehler unentdeckt und wir mussten schnell handeln, um die Situation zu korrigieren. Am Ende konnten wir dies tun, indem wir Teile des Upgrades optional machten, aber nicht bevor das Vertrauen einiger Mitglieder unserer Community in die Stabilität unseres Plugins erschüttert wurde.

Diese Erfahrung zwang uns dazu, unseren Entwicklungsprozess gründlich und gründlich zu prüfen, um einige wichtige Änderungen vorzunehmen. Unsere Prozesse waren einfach nicht für ein Unternehmen unserer Größe und Installationsbasis geeignet. Der erste und vielleicht naheliegendste Schritt bestand darin, die Größe und den Umfang unseres QA-Teams zu erhöhen, aber dies ließ uns immer noch mit einer Reihe offener Probleme kämpfen:

• Überprüfung der Kompatibilität einer Version mit unzähligen Site-Setups
• Gewährleistung der Abwärtskompatibilität mit über fünf Millionen bestehenden Websites
• Überprüfung der Kompatibilität von Hunderten von Elementor-Erweiterungen von Drittanbietern

Um all diese Probleme zu lösen, mussten wir modernere Softwareentwicklungsmethoden in die WordPress-Welt bringen.

Die Rückkopplungsschleife

Eines der großen Probleme bei der Entwicklung im Allgemeinen besteht darin, dass Benutzer Updates erst sehen, wenn sie veröffentlicht wurden. Das bedeutet, dass eine Funktion bereits entworfen, entwickelt und veröffentlicht wurde, wenn wir Feedback von Benutzern erhalten. In unserem Fall, bei dem es um Hunderte von Erweiterungen und Plugins von Drittanbietern geht, ist das Problem dieser Rückkopplungsschleife sogar noch wichtiger.

Auf der Suche nach Möglichkeiten, diese Feedback-Schleife zu verkürzen, haben wir uns angesehen, wie Browser-Entwickler mit Problemen umgehen, die unseren eigenen sehr ähnlich sind – sie müssen auch die Kompatibilität mit unzähligen Webseiten, Apps, Erweiterungen und mehr von Drittanbietern sicherstellen.

Wir haben zum Beispiel das von Google entwickelte System für den Chrome-Browser untersucht. Entwickler haben jederzeit Zugriff auf drei Versionen des Browsers – eine Beta-Version, eine Dev-Version und eine Nightly-Version. Das bedeutet, dass Entwickler frühzeitig einen Blick auf neue Chrome-Funktionen werfen und Google schon lange vor der offiziellen Veröffentlichung der Version Feedback geben können.

Durch Anwendung dieser Lektionen auf unser Plugin begann Elementor mit der Veröffentlichung seiner eigenen Entwickler-Edition – Elementor Beta (Entwickler-Edition), die im WordPress-Repository verfügbar ist und sich an Entwickler richtet, die daran interessiert sind, unsere neuen Funktionen „druckfrisch“ sozusagen auszuprobieren.

Für uns profitieren wir natürlich von frühzeitigen Warnungen bei Kompatibilitätsproblemen. Die Developer Edition ermöglicht Benutzern nicht nur den Zugriff auf all diese neuen Funktionen, sondern es gibt sogar einen direkten Link zu Github zum Melden von Fehlern. Das bedeutet, dass wir kontinuierlich neue Funktionen bereitstellen und Feedback dazu erhalten können, ohne bestehende Websites zu gefährden. Entwickler können sich so frühzeitig auf kommende offizielle Veröffentlichungen vorbereiten, eigene Kompatibilitätsprobleme vermeiden und ihnen außerdem die Möglichkeit geben, Produkt- und technisches Feedback zu geben, während noch an der Funktion gearbeitet wird.

Es sollte beachtet werden, dass Releases der Developer Edition parallel zu den normalen – Alpha, Beta, RC und Produktion – einem Prozess laufen, der zur Entwicklung von Elementor-Releases verwendet wird. Wenn wir ein neues Feature entwickeln, fügen wir es der Developer Edition hinzu, sobald es stabil genug ist, um verwendet zu werden, aber noch in der Alpha-Phase. Auf diese Weise können uns unsere Entwickler Feedback geben, noch bevor das Feature die Beta erreicht. Das bedeutet auch, dass die Developer Edition Funktionen enthält, die das Beta-Stadium noch nicht erreicht haben.

Im Wesentlichen ist die Beta-Phase für einen bewussten Debugging-Prozess reserviert, während die Entwicklerversion häufiger aktualisiert wird und Funktionen in ihren frühesten Stadien enthält.

Seit ihrer Einführung hat sich die Entwicklerversion als großer Erfolg erwiesen und in weniger als einem Jahr über 40.000 Installationen erzielt.

Einführung „experimenteller“ Funktionen

Ein weiteres Konzept, das sich Entwickler im Laufe der Jahre zu eigen gemacht haben, sind Feature-Flags, die besonders in der Welt von SaaS weit verbreitet sind. Die allgemeine Idee ist, dass diese Feature-Flags es Entwicklern ermöglichen, neue Funktionen zu testen, indem sie sie für verschiedene Benutzersegmente ein- und ausschalten, um sie zu testen und zu sehen, wie sie funktionieren.

Wie oben erwähnt, waren viele der Probleme, die sich aus der Veröffentlichung von 3.0 ergaben, auf neue Funktionen zurückzuführen, die älteren Code eliminierten. Um diese Art von Problemen zu vermeiden, haben wir uns für einen ähnlichen Ansatz wie bei Feature-Flags entschieden.

Beginnend mit Elementor 3.1 haben wir begonnen, neue Funktionen sorgfältiger zu veröffentlichen und sie als „experimentell“ zu kennzeichnen. Dazu gehört ein System zur schrittweisen Einführung neuer Funktionen. In diesem System wird eine neu entwickelte Funktion als „Alpha“ gekennzeichnet. Dies bedeutet, dass es standardmäßig auf allen Websites deaktiviert ist. Da es sich als stabiler erweist, wird es zu einer „Beta“, was bedeutet, dass es jetzt standardmäßig für neue Websites aktiviert und für bestehende Websites deaktiviert ist. Sobald wir sicher sind, dass es stabil ist, wird es standardmäßig für alle Websites aktiviert. Selbst dann wird es für Benutzer die Möglichkeit geben, die Funktion für eine begrenzte Zeit zu deaktivieren.

Dieses System ermöglicht es uns, Elementor weiterzuentwickeln und sowohl seinen Funktionsumfang als auch seine Geschwindigkeit zu erweitern, während Ersteller diese neuen Upgrades entsprechend den Anforderungen ihrer Website aktivieren oder deaktivieren können. Dies hilft den Erstellern auch dabei, ihre Websites zu aktualisieren, indem sie neue Funktionen sorgfältiger übernehmen können.

Kompatibilitäts-Tags

Das Wachstum der sehr aktiven Entwickler-Community von Elementor war eine große Quelle des Stolzes, hat aber auch seine eigenen Herausforderungen mit sich gebracht. Drittentwickler haben Hunderte von Erweiterungen, Designs, Kits und Widgets erstellt, die alle auf unserer bestehenden Technologie basieren.

Um die Entwickler dieser Drittanbieter-Add-Ons zu unterstützen, haben wir unseren Entwickler-Blog und unsere Mailingliste verwendet, um sie frühzeitig über Änderungen zu informieren, die wir an der API vornehmen, sowie über veraltete Versionen. Wie oben erwähnt, stellten wir jedoch fest, dass dies nicht ausreichte. Viele der Probleme, die wir mit neuen Versionen hatten, waren Kompatibilitätsprobleme aufgrund dieser Add-Ons von Drittanbietern. Unser Plugin wurde als instabil angesehen, nicht wegen unserer Technologie, sondern wegen dieser Inkompatibilitäten von Drittanbietern.

Auch hier haben wir uns inspirieren lassen, was andere tun. In diesem Fall WooCommerce und ihr Ansatz zur Zusammenarbeit mit Drittentwicklern. Beginnend mit unserer Version 3.1 haben wir ein System eingeführt, bei dem Drittentwickler bestätigen, dass ihre Erweiterungen mit der neuen Version kompatibel sind (Weitere Informationen). Wenn Benutzer dann die Möglichkeit erhalten, Elementor zu aktualisieren, wird ihnen eine Liste der von ihnen verwendeten Erweiterungen von Drittanbietern angezeigt und ob sie als kompatibel mit der neuen Version von Elementor zertifiziert wurden oder nicht. Auf diese Weise können die Benutzer eine fundierte Entscheidung über ein Upgrade treffen.

Auf dem Weg zu einer noch besseren Zukunft

Indem ich diese Herausforderungen und die von uns vorgenommenen Änderungen skizziere, hoffe ich, dass ich Ihnen einen Einblick gegeben habe, wie es ist, ein Produkt für den weltweiten Einsatz in einer sich ständig ändernden Open-Source-Umgebung zu entwickeln. Als Teil dieser Open-Source-Kultur ist es entscheidend, dass wir gegenüber unserer Community von Benutzern und Entwicklern transparent sind – umso mehr, wenn das Unternehmen wächst und es schwieriger wird, eine „persönliche Note“ zu bewahren. Nicht nur, weil der Schmerz unserer Benutzer unser Schmerz ist, sondern weil es der beste Weg für Elementor ist, ein stabiles Werkzeug zu bleiben, das für die größtmögliche Anzahl von Benutzern offen ist.

Wir sind der festen Überzeugung, dass die von uns durchgeführten Änderungen zum Wachstum und Erfolg von Elementor beigetragen haben und weiterhin beitragen werden. Wir sind uns jedoch auch bewusst, dass noch viel zu tun ist und dass die Kommunikation zwischen Elementor und der Elementor-Community offen bleiben und sogar verbessert werden muss. Zum Beispiel aktualisieren wir unsere Entwickler-Ressourcen-Site und bieten eine benutzerfreundliche Dokumentation, die Entwicklern hilft, Elementor anzupassen und darauf aufzubauen.
Aber der vielleicht wichtigste Schritt, den wir zur Verbesserung der Kommunikation unternommen haben, ist die Einrichtung des Elementor Community Hub. Hier können sich Webdesigner weltweit versammeln, um Ideen untereinander und mit uns auszutauschen – gemeinsam daran zu arbeiten, Elementor so gut wie möglich zu machen. Wie das alte Sprichwort sagt, mag es fast unmöglich sein, Katzen zu hüten, aber wenn sie zusammenarbeiten, nennt man das Stolz.