Gestaffelte Rollouts für WordPress-Plugin- und Theme-Entwickler: Vermeiden eines „Clusterbug-Releases“
Veröffentlicht: 2020-12-23Erinnerst du dich an das letzte Mal, als du eine neue Version deines WordPress-Plugins oder -Themes veröffentlicht hast, um schnell zu entdecken, dass du versehentlich einen neuen großen Fehler hinzugefügt hast, der durch deine Testsequenzrisse gerutscht ist?
Yoast SEO 3.0 hat im Jahr 2015 viele Websites kaputt gemacht. Elementor 3.0 hat dieses Jahr dasselbe getan. Und das sind nur zwei Beispiele für fantastische Unternehmen in unserem Bereich mit über 100 Mitarbeitern und engagiertem QA-Personal (und nein, es hat nichts mit Version 3.0 zu tun, aber vielleicht ist es ein Zeichen dafür, diese Version in Ihrer Software zu überspringen; )).
Egal, ob Sie ein autodidaktischer Programmierer oder Softwareentwickler, Indie-Entwickler oder Teil eines großen Plugin-/Theme-Shops sind, wir alle müssen uns mit Fehlern auseinandersetzen. Es ist ein unvermeidlicher Bestandteil der Softwareentwicklung.
Egal, welche ausgefallenen CI/CD/Testautomatisierungen Sie einsetzen – Sie werden nie alles testen können. Die Anzahl der Serverkonfigurationen (PHP, MySql, Caching, Webserver), WP-Versionen, Kombinationen von Plugins und Themes … ist endlos.
Und es ist kontraintuitiv. Je beliebter und stabiler Ihre Produkte werden, desto höher sind die Chancen für eine gefürchtete „Clusterbug“-Veröffentlichung, die Ihre Unterstützung erschöpft, das Vertrauen und die Loyalität Ihrer Kunden erheblich beeinträchtigen und möglicherweise den allgemeinen Markenruf schädigen kann.
Während Sie Fehler nicht vermeiden können, können und sollten Sie das Risiko so weit wie möglich mindern.
Wenn Sie ein Smartphone besitzen, ist Ihnen wahrscheinlich aufgefallen, dass einige Ihrer Freunde Android/iOS-Updates Tage, Wochen, manchmal sogar Monate vor Ihnen erhalten. Das ist kein Zufall, und nein, es ist nichts Persönliches gegen Sie. Es handelt sich um einen absichtlich progressiven Bereitstellungsprozess namens Staged Rollouts, der Unternehmen wie Apple hilft, wichtige Software-Updates an über eine Milliarde Geräte zu liefern.
Ja, eine Milliarde!
Können Sie sich überhaupt vorstellen, wie viel Verantwortung ein Versionsleiter bei Apple tragen würde, wenn er gleichzeitig ein Live-Update auf 1,5 Milliarden mobile Geräte übertragen müsste? Ich kann nicht. Ich wette, dass kein vernünftiger Mann zustimmen würde, eine solche Verantwortung zu tragen.
Wie funktioniert also der gestaffelte Rollout-Mechanismus? Wie können Sie es umsetzen? Und worauf wartet WordPress.org? Dies sind die Themen, die ich im Folgenden behandeln werde.
Was sind gestaffelte Rollouts für WordPress-Plugins und -Themes?
Mit gestaffelten Rollouts können Sie die Anzahl (oder den Prozentsatz) der Websites angeben, auf denen Sie eine neue Version ausrollen möchten. Ein gestufter Rollout-Mechanismus ermöglicht es Ihnen, Ihren Veröffentlichungszyklus mit begrenzter Präsenz zu beginnen und ihn dann schrittweise zu erhöhen, während Sie Support und Feedback überwachen, wodurch Sie und Ihre Benutzer Vertrauen in Ihre Veröffentlichung aufbauen.
Was sind die Vorteile von gestaffelten Rollouts?
Anstatt Ihre gesamte Installationsbasis durch die Veröffentlichung potenzieller Fehler, Konflikte mit Plugins/Designs von Drittanbietern oder sogar UI/UX-Probleme zu riskieren, können Sie Versionen nach und nach veröffentlichen und so die Anzahl der Personen und Websites minimieren, die unerwarteten Problemen ausgesetzt sind. Sobald Sie alle Probleme und Fehler beseitigt haben, die während des Rollout-Prozesses entdeckt wurden, wird die überwiegende Mehrheit Ihrer Benutzer mit einer „ausgereiften“ und viel stabileren Version konfrontiert.
Wir verwenden fortlaufende Updates, um die Qualität unserer neuen Versionen sicherzustellen. Wenn es ein Problem mit einer neuen Version gibt, können wir es schnell identifizieren, und es wäre nur eine kleine Untergruppe von Benutzern betroffen.
John Turner, Gründer von SeedProd
Die Verwendung von gestaffelten Rollouts ist DIE Best Practice für die verantwortungsvolle Veröffentlichung von Software – ein Prozess, dem viele Unternehmen (unabhängig von ihrer Größe) außerhalb der WP-Blase folgen.
Es gibt eine große Chance für die WordPress-Community, die Vorteile von gestaffelten Rollouts zu nutzen, auf die ich gleich noch eingehen werde.
Sind Beta-Programme mit gestaffelten Rollouts vergleichbar?
Das Einrichten eines Beta-Programms für Ihr WordPress-Produkt ist ein guter Anfang, aber es ist bei weitem nicht so effektiv wie gestaffelte Rollouts, und es hat einen grundlegend anderen Zweck und eine andere Dynamik.
Sofern Ihr Plugin oder Thema nicht sehr beliebt ist und eine große Community hat, ist es ziemlich schwierig, eine statistisch ausreichende Beta-Gruppe zu rekrutieren, da nur ein winziger Bruchteil der Benutzer daran interessiert sein wird, beizutreten. Selbst wenn Sie sich darin auszeichnen, eine anständige Gruppe von Beta-Testern zu rekrutieren, müssen Sie sich auf ihre Verfügbarkeit und ihren guten Willen verlassen, um das Produkt zu testen, und dann hoffen, dass sie sich die Mühe machen, die gefundenen Probleme zu melden.
Was glauben Sie, wie viele Leute diesen ganzen Prozess durchschauen werden? Nicht viele.
Beta-Tests sind ein Vorproduktionsprozess, bei dem Ihre Support-Bemühungen vollständig kontrolliert werden und Tester Probleme mit Beta-Versionen erwarten. Daher spiegeln die Qualitätserwartungen der Tester nicht die allgemeine Stimmung Ihrer Benutzerbasis wider.
Darüber hinaus wird ein verantwortungsvolles Beta-Programm seine Tester davor warnen, Beta-Versionen in Produktionsumgebungen zu verwenden, sodass Beta-Tests nicht wirklich Live-Produktions-Websites simulieren.
Wie verwalte ich eine gestaffelte Rollout-Version für Ihr WordPress-Plugin oder -Theme?
Im Rahmen meiner Recherchen zu gestaffelten Rollouts hatte ich die Gelegenheit, Amir Helzer per E-Mail zu treffen und von ihrer mehr als zweijährigen Erfahrung mit gestaffelten Rollouts mit WPML und Toolset zu lernen, Plugins, die auf mehr als 1.000.000 WordPress-Websites ausgeführt werden.
Hier ist, was Amir über die Implementierung von Staged Rollouts mitteilte:
Wenn eine Website eines unserer Plugins installiert, ziehen wir eine Zufallszahl zwischen 1 und 100 und speichern sie zur Erinnerung in der Datenbank der Website. Diese Methode teilt die Websites im Wesentlichen zufällig in 100 Bins auf.
Wenn eine Version bereit ist, live zu gehen, wird sie nur inkrementell für eine einzelne ausgewählte Bin verfügbar. Jeden Tag erhöhen wir die Sichtbarkeit der Veröffentlichung auf weitere 5 % der Websites in der dafür vorgesehenen Ablage. Und beheben und patchen Sie die kommenden Probleme, während wir fortfahren.
Um die Umgebungen mit der aktualisierten Version zu diversifizieren und zu vermeiden, dass dieselben „Opfer“ früher Veröffentlichungen wiederholt werden, bestätigte Amir, dass jede neue Veröffentlichung zuerst an eine andere Gruppe von Benutzern geht.
Dieser Ansatz bedeutet auch, dass ein durchschnittlicher Release-Zyklus etwa einen Monat dauert, bis er für jeden Benutzer verfügbar ist.
Es dauert einige Zeit, bis die Leute eine neue verfügbare Version im WP Admin sehen und ihre Version aktualisieren. Und selbst danach kann es Tage dauern, bis sie ein Problem entdecken.
Bei unserer Publikumsgröße hat jede Veröffentlichung zwangsläufig einige Probleme. Unser Hauptziel ist es, sicherzustellen, dass wir die Einführung neuer Probleme vermeiden, und wenn wir dies tun, haben wir einen zuverlässigen Prozess, um sie zu lösen.
Der Veröffentlichungszyklus ist in der Tat lang, aber selbst wenn im schlimmsten Fall ein verrückter Fehler auftritt, den wir beim Testen übersehen haben, sind sich 95 % unserer Benutzer nicht einmal des ganzen Dramas bewusst, da sie der Veröffentlichung nicht ausgesetzt sind bis es stabil ist.
Amir betonte auch die Bedeutung der Synchronisierung mit dem gesamten Team vor Veröffentlichungen, insbesondere dem Kundensupport und der Entwicklung. Auf diese Weise können Teammitglieder sich besonders auf Tickets konzentrieren, die aufgrund von Problemen im Zusammenhang mit der laufenden Veröffentlichung ausgelöst wurden, mit dem Ziel, gültige Probleme zu überprüfen, zu bestätigen und zu beheben und Patches so schnell wie möglich zu veröffentlichen.
Wir haben drei Support-Ebenen in unserem Team. Tier 1 wird sich das Problem ansehen und bestätigen, dass es sich tatsächlich um ein Problem im Zusammenhang mit der Veröffentlichung des Plugins handelt, indem es reproduziert wird. Wenn ein Fall im Zusammenhang mit der neuen Version zu stehen scheint, geht er an Ebene 2, die das Problem debuggt, um zu bestätigen, dass es tatsächlich mit der Version zusammenhängt, und die relevanten Teile im Code zu finden, die das Problem auslösen. Bei Validierung wird der für diesen Code verantwortliche Entwickler sofort benachrichtigt, um eine Fehlerbehebung zu priorisieren.
OnTheGoSystems ist ein großes Unternehmen mit fast 100 Mitarbeitern, daher ist es sinnvoll, dass sie ihren gestaffelten Rollout-Prozess perfektioniert haben. Aber selbst als einzelner Produktentwickler mit einer Supportebene (Sie und Sie selbst) kann uns Amirs Einblick lehren, dass es entscheidend ist, Releases dedizierte Ressourcen zuzuweisen. Es hat sich bewährt, Support-Tickets zu priorisieren, die sogar „riechen“, um mit Ihrer neuen Version in Verbindung zu stehen, und die Gefährdung durch neue Probleme so weit wie möglich zu reduzieren.
Warum gibt es (fast) keine Plugins oder Themes, die gestaffelte Rollouts unterstützen?
In Vorbereitung auf das Schreiben dieses Artikels habe ich versucht, die Community zu fragen, wer gestaffelte Rollouts verwendet, um Feedback zu ihren Erfahrungen, dem, was sie gelernt haben, usw. zu erhalten.
Es überrascht nicht, dass ich in meinem Netzwerk nur zwei WordPress-Unternehmen gefunden habe, die im Rahmen ihres Veröffentlichungszyklus gestaffelte Rollouts eingerichtet haben. Viele Entwickler kannten das Konzept nicht einmal, und der Rest verwendet es nicht, da ihre Distributionslösung es nicht unterstützt (oder sie haben vielleicht darüber nachgedacht, es zu entwickeln und haben keine Zeit).
Die meisten Plugin- und Theme-Entwickler, die nicht über Freemius verkaufen, verkaufen von ihrer Website über EDD oder WooCommerce, die beide keine gestaffelten Rollouts unterstützen. Diejenigen, die über Marktplätze wie CodeCanyon und ThemeForest verkaufen, haben ebenfalls keine Out-of-the-Box-Lösung und werden höchstwahrscheinlich nie eine haben.
Selbst Entwickler, die sich des Konzepts bewusst sind, haben keine andere Wahl, als einen eigenen Mechanismus zu entwickeln, um gestaffelte Rollouts zu unterstützen. Diese Infrastrukturentwicklung ist in der Regel sehr schwer innerhalb eines Produktunternehmens zu priorisieren.
Abonnieren Sie und holen Sie sich eine kostenlose Kopie unserer
WordPress Plugin Geschäftsbuch
Genau, wie man ein florierendes WordPress-Plugin-Geschäft in der Abonnementwirtschaft aufbaut.
Teilen Sie mit einem Freund
Geben Sie die E-Mail-Adresse Ihres Freundes ein. Wir schicken ihnen nur dieses Buch per E-Mail, Scout's Ehre.
Ich danke Ihnen für das Teilen
Großartig – eine Kopie von „The WordPress Plugin Business Book“ wurde gerade an gesendet . Möchten Sie uns helfen, das Wort noch mehr zu verbreiten? Los, teilen Sie das Buch mit Ihren Freunden und Kollegen.
Danke fürs Abonnieren!
- wir haben gerade Ihr Exemplar von 'The WordPress Plugin Business Book' an gesendet .
Haben Sie einen Tippfehler in Ihrer E-Mail? Klicken Sie hier, um die E-Mail-Adresse zu bearbeiten und erneut zu senden.
Wie verschaffen Ihnen gestaffelte Rollouts einen kommerziellen Vorteil?
Da derzeit fast niemand die Vorteile von gestaffelten Rollouts nutzt, verschafft Ihnen dies definitiv einen Wettbewerbsvorteil und erhöht das Vertrauen in Ihr Produkt, wenn Sie mit der Verwendung von gestaffelten Rollouts beginnen und diese richtig auf Ihrer Website vermarkten, um Besucher wissen zu lassen, dass Sie verantwortungsvolle Veröffentlichungszyklen haben /Marke!
Wenn Sie den Markt aus der Perspektive eines Entwicklers analysieren, werden Sie feststellen, dass viele Entwickler ihren Konkurrenten genau folgen und ihre Preise normalerweise innerhalb der Preisspanne des Marktes in ihrer Branche festlegen, was dazu führt, dass konkurrierende WordPress-Produkte ähnliche Funktionen in derselben Preisklasse anbieten.
Aus der Sicht des Käufers bedeutet dies, dass es oft umstritten ist, welches Produkt er kaufen soll, da sie alle vergleichbare Funktionen und Preise haben. Aber wenn Sie mehrere Plugins evaluieren, die gleich viel kosten und, geben oder nehmen, die gleichen Funktionen haben, würden Sie nicht geneigt sein, sich für das Produkt zu entscheiden, das gestaffelte Rollouts anbietet, wenn Sie wissen, dass seine Produktionsversionen stabiler sein sollten als die der Konkurrenz?
Gestaffelte Rollouts steigern das Vertrauen in Ihr Produkt und Unternehmen. Es ist ein Vorteil, den Sie nutzen können, bevor gestaffelte Einführungen zur Standardpraxis werden (was ich wirklich hoffe).
Freemius unterstützt jetzt gestaffelte Rollouts für kostenpflichtige Plugins und Themes
Wir freuen uns, den Weg für gestaffelte Rollouts im Premium-WordPress-Plugins- und Themes-Ökosystem zu ebnen. Unsere Vertriebspartner können jetzt sicher, vertrauensvoll und zuverlässig Updates veröffentlichen, mit minimalem Rückschlag für ihre Benutzer oder Support-/Entwicklungsressourcen.
Wir wissen, wie herausfordernd und nervenaufreibend große Releases sein können, zumal nach einem „Clusterbug“-Release immer das potenzielle Risiko besteht, Ihre Marke negativ zu beeinflussen.
Mit gestaffelten Rollouts gibt es ein Sicherheitsnetz für die Markennachhaltigkeit und -verteidigung unserer Partner und verringert den unnötigen Stress, der mit Veröffentlichungen für eine große Benutzerbasis verbunden ist.
Davon profitieren die Kunden unserer Partner. Wenn Benutzer Produkte kaufen, die über Freemius verkauft werden, können sie sich jetzt darauf verlassen, dass sie sich für eine Lösung entscheiden, die von Staged Rollouts unterstützt wird, und sie können viel stabilere Versionen von Premium-Plugins und -Themen erwarten, die den Mechanismus nutzen.
Wenn Sie mit Freemius verkaufen, erfahren Sie hier, wie Sie unseren gestaffelten Rollouts-Mechanismus richtig verwenden.
Wie hat Freemius gestaffelte Rollouts implementiert?
Jede Website, die eine Lizenz zum Freischalten eines Premium-Plugins oder -Themes aktiviert, erhält einen Eintrag in unserer Datenbank. Als erstes haben wir eine neue Eigenschaft last_served_update_version eingeführt, um die neueste Produktversion zu speichern, die einer Website zur Verfügung gestellt wurde.
Dann haben wir die Tabelle, die für das Speichern von Release-Daten verantwortlich ist, mit zwei neuen Eigenschaften angereichert: limit , uniques .
Wenn ein Entwickler eine Version als freigegeben kennzeichnet, wird er mit dem folgenden Dialogfeld aufgefordert, in dem er den Prozentsatz (oder die Anzahl) der Websites mit einer aktiven Lizenz festlegen kann, auf denen er die kostenpflichtige Version einführen möchte:
Wenn sie einen eingeschränkten Release-Rollout festlegen, zählt das System die gesamten aktiven Websites mit einer aktiven Lizenz und legt dann die neue limit -Eigenschaft des Releases entsprechend fest.
Schließlich haben wir den API-Endpunkt aktualisiert, der von Websites aufgerufen wird, um zu prüfen, ob es eine neue Version gibt, und die folgende Logik (in Pseudocode) eingeführt:
latest_version = load latest version of product X
If (website is on latest_version)
return “no new version”
If (last_served_update_version of website same as latest_version)
return “no new version”
If (latest_version is limited)
If (latest_version is limited AND uniques >= limit)
return “no new version”
previous_version = load the previous version of product X
If (previous_version is limited too AND uniques <= previous_version.uniques)
If (website not using previous_version AND
last_served_update_version different from previous_version)
return “no new version”
else If (random({true, false}) )
return “no new version”
Set last_served_update_version of website to latest_version
Increment uniques by 1
return latest_version
Dieser Algorithmus stellt Folgendes sicher:
- Die Exposition des Releases ist entsprechend dem festgelegten Prozentsatz des Rollouts begrenzt.
- Wenn die vorherige Version noch gestaffelt ist, dh sie war nie für die gesamte Installationsbasis verfügbar, werden die Websites, die die vorherige gestaffelte Version erhalten haben, zuerst der neuesten gestaffelten Version ausgesetzt.
Im Gegensatz zur stufenweisen Rollouts-Architektur von WPML, die sicherstellt, dass jede Version mithilfe logischer Bins an eine andere Teilmenge ihrer Installationsbasis geht, ist unsere Implementierung auf Zufälligkeit angewiesen. Eine Website kann also zwei Early-Stage-Releases in zwei aufeinanderfolgenden Release-Zyklen erhalten. Der Vorteil dieses Ansatzes besteht jedoch darin, dass wir gestaffelte Rollouts an alle Kunden unserer Partner liefern konnten, ohne dass ein SDK-Update gepusht werden musste, das viele Monate oder sogar Jahre dauern kann, bis es an alle Kunden weitergegeben wird.
Warum sind gestaffelte Rollouts für die Zukunft von WordPress unerlässlich?
Als ich Amir fragte, was ihr Auslöser war, gestaffelte Rollouts für WPML-Veröffentlichungszyklen zu entwickeln, sagte er mir Folgendes:
Vor 3 Jahren verbrachte ich beim WordCamp Europe Zeit damit, mit WPML-Kunden zu chatten, um alle Arten von Feedback zu ihrer Gesamterfahrung zu sammeln. Die größte Frustration, die ich fand, war, dass unsere Kunden Angst hatten, das Plugin zu aktualisieren, da es ihre Website unerwartet beschädigen kann.
Amir Helzer,
Gründer von OnTheGoSystems (WPML, Toolset)
Dem schließe ich mich absolut an.
Unsere interne Richtlinie bei Freemius, wenn es um die Aktualisierung von Plugins und Themes geht, ist … einfach nicht! Mit zwei Ausnahmen: Wenn es ein bekanntes Sicherheitsproblem oder eine Funktion gibt, die in einer neueren Version verfügbar ist, die wir für unsere Website benötigen.
Unsere Update-Richtlinie wurde nach mehreren Vorfällen von Updates, die schief gelaufen sind und unerwartete Kopfschmerzen und Zeitverschwendung verursachten und unseren Betrieb und unsere Zeitpläne unterbrachen, „mit Blut geschrieben“. Und ja, wir hätten einen Teil des Stresses mit einer Staging-Umgebung vermeiden können, aber das hätte uns nicht die Zeit und den Ärger gespart, wenn wir das Update trotzdem auf die Produktion übertragen wollten.
WordPress hat sich seitdem ein wenig weiterentwickelt, und jetzt haben wir eine automatische Deaktivierung bei Plugin-Fehlern. Das gilt jedoch nicht für Themes und die Deaktivierung eines geschäftskritischen Plugins für unsere Website ist immer noch ein großes Problem.
Das Fazit ist, dass wenn ich als Plugin-Entwickler und CEO eines Unternehmens, das Tausenden von Plugin- und Theme-Entwicklern hilft, ihr Geschäft auszubauen, besorgt bin, dass unsere Website jedes Mal kaputt geht, wenn wir Plugins oder Themes auf unserer Website aktualisieren, dann bedeutet das sicherlich Die meisten Benutzer haben kein Vertrauen in die Aktualisierung von Software in unserem Bereich.
Das Fehlen von gestaffelten Rollouts hält uns und das gesamte WP-Ökosystem zurück und verschafft SaaS-basierten Konkurrenzlösungen einen erheblichen Vorteil. Benutzer von WiX und Shopify müssen überhaupt nicht an Updates denken! Updates passieren für sie einfach im Hintergrund, und ihre Software ist immer auf dem neuesten Stand, was Sicherheit und Funktionen angeht.
Das Fehlen von gestaffelten Rollouts hält das gesamte WP-Ökosystem zurück und verschafft SaaS-basierten Lösungen einen erheblichen Vorteil. Nutzer von WiX und Shopify brauchen sich keine Gedanken über Software-Updates zu machen – sie passieren einfach im Hintergrund.Tweet
Wenn Sie letzte Woche State of the Word gesehen haben, wird WordPress-Mitbegründer Matt Mullenweg klar, wie wichtig aktuelle Software ist. Hier ist Matts Vision für WP-Updates:
… damit Sie sich für automatische Updates für Core anmelden können. Dies ist der erste Schritt zu unserem Ziel, damit sich Ihr WordPress im Wesentlichen selbst verwaltet, wenn Sie es einstellen und vergessen können, und es automatisch, im Hintergrund und problemlose Updates für alle Ihre Plugins, Themen und Core.Tweet erhält
Ich kann mir nur vorstellen, dass WordPress zu einem „Set and Forget“ wird, wenn Software-Updates zuverlässiger und vertrauenswürdiger sein können, und das kann nur mit gestaffelten Rollouts geschehen.
WordPress.org: So können Sie gestaffelte Rollouts für das Plugin- und Theme-Repository einführen
Ähnlich wie bei unserer Implementierung müssen zu jeder Plugin- und Theme-Version in der WordPress.org-Datenbank zwei neue Meta-Optionen hinzugefügt werden: limit und uniques .
Die Bearbeitung der limit -Meta-Option kann in der erweiterten Ansicht für den angemeldeten Eigentümer (und möglicherweise für andere Committer) angezeigt werden:
Ein Entwickler hat die Möglichkeit, die Offenlegung jeder Version zu kontrollieren, sowie die Möglichkeit, ein Limit für die nächste Version festzulegen.
Da WordPress.org nicht strukturierte Daten für jede Website speichert, die Updates von WordPress.org erhält, anstatt die neueste Version, die von einer Website „gesehen“ wird, in der WordPress.org-Datenbank zu speichern, kann die Speicherung der Daten an die Websites delegiert werden . Das bedeutet, dass der 'update_plugins' und die Daten, die an die WordPress.org-API gesendet werden, wenn nach Updates gesucht wird, mit einer last_served_update_version angereichert werden müssen.
Schließlich können die API-Endpunkte für WordPress.org-Updates mit der gleichen Logik angereichert werden, die wir für die Implementierung von Freemius Staged Rollouts verwendet haben. Anstatt sich auf die last_served_update_version aus der wp.org-Datenbank zu verlassen, hängt der Mechanismus von dem Wert ab, der von der Website vom Kern gesendet wird.
Kinderleicht, oder?
stellt ein 
Lassen Sie uns das Vertrauen der Benutzer zurückbringen, auf die Schaltfläche „Aktualisieren“ zu klicken
Wir alle wollen, dass WordPress erfolgreich ist und ständig größer und besser wird!
Bei so vielen Ressourcen, die in Gutenberg fließen, ist es klar, dass die Führung von WordPress anerkennt, dass wir die Plattform für den durchschnittlichen Nicht-Techniker viel zugänglicher machen müssen. Die Sache ist, dass, solange Software-Updates nicht vertraut werden können, selbst mit Gutenberg und all den erstaunlichen Seitenerstellern, die wir zur Verfügung haben, eine nicht technisch versierte Person bei ihrem ersten kaputten Update zu Wix davonlaufen wird, und ich kann es nicht beschuldigen Ihnen.
Ich rufe den Gründer von EDD, Pippin Williamson, den CEO von WooCommerce, Paul Maiorana, und das WordPress.org-Team auf: Wir haben die Möglichkeit, das Plugin- und Theme-Ökosystem für die größere WordPress-Community viel stabiler zu machen. Lassen Sie uns Benutzern ermöglichen, ihre Software mit weniger Angst und Frustration sicher und auf dem neuesten Stand zu halten. Auch wenn es kurzfristig nicht wie eine hohe Priorität aussieht, bin ich sicher, dass wir alle langfristig davon profitieren werden.