WordPress berücksichtigt historische Entwicklungsänderungen

Meta description

Matt Mullenweg, WordPress-Entwickler und CEO von Automatic, hat vorgeschlagen, das Hinzufügen neuer Funktionen zu WordPress einzustellen und stattdessen zu einer Plugin-First-Richtlinie überzugehen.

Dieser neue Ansatz für die Zukunft von WordPress hat bereits dazu geführt, dass ein neues Feature, das für die nächste Version von WordPress vorgesehen ist, vollständig aufgegeben wird.

Kanonische Plugins sollen eine Möglichkeit bieten, WordPress schneller zu verbessern.

Einige zentrale WordPress-Mitwirkende haben jedoch die Meinung geäußert, dass die Benutzererfahrung des Editors darunter leiden könnte.

Kanonische Plugins

Kanonische Plugins, die erstmals 2009 diskutiert wurden, sind eine Möglichkeit, neue Funktionen in Form von Plugins zu entwickeln.

Das Ziel dieses Ansatzes ist es, den WordPress-Kern schnell und leicht zu halten und gleichzeitig die Entwicklung experimenteller Funktionen in Form von Plugins zu fördern.

Der ursprüngliche Vorschlag von 2009 beschrieb es wie folgt:

„Kanonische Plugins wären Plugins, die von der Community entwickelt wurden (mehrere Entwickler, nicht eine Person) und würden die beliebtesten Funktionsanforderungen mit außergewöhnlicher Ausführung erfüllen.

… gäbe es eine sehr starke Beziehung zwischen dem Kern und diesen Plugins, die sicherstellt, dass a) der Plugin-Code sicher und das bestmögliche Beispiel für Codierungsstandards ist und b) neue Versionen von WordPress vor der Veröffentlichung mit diesen Plugins getestet werden Kompatibilität sicherstellen.

Dieser Ansatz für Features und Optionen wird auch Plugin First genannt, um zu betonen, wie Features zuerst als Plugins erscheinen.

Diese Plugins werden als kanonisch bezeichnet, weil sie vom zentralen WordPress-Entwicklungsteam entwickelt wurden, im Gegensatz zu nicht kanonischen Plugins, die von Drittanbietern erstellt wurden und die Funktionalität einschränken könnten, um den Kauf einer Pro-Version zu fördern.

Die Integration von kanonischen Plugins in den WordPress-Kern selbst würde in Betracht gezogen, sobald sich die Plugin-Technologie als beliebt und für die Mehrheit der Benutzer unverzichtbar erwiesen hat.

Der Vorteil dieses neuen Ansatzes für WordPress wäre, dass keine neuen Funktionen hinzugefügt werden, die die Mehrheit der Benutzer möglicherweise nicht benötigt.

Plugin-first könnte als im Einklang mit der WordPress-Philosophie namens Decisions, not Options angesehen werden, die darauf abzielt, Benutzer nicht mit einer Vielzahl technischer Optionen zu überfordern.

Durch das Auslagern verschiedener Features und Funktionen in Plugins muss ein Benutzer keine Funktionen aktivieren oder deaktivieren, die er benötigt, nicht benötigt oder nicht versteht.

Die Designphilosophie von WordPress besagt:

“Es ist unsere Pflicht als Entwickler, intelligente Designentscheidungen zu treffen und zu vermeiden, dass die Last technischer Entscheidungen unseren Endbenutzern aufgebürdet wird.”

Die kanonischen Plugins der Zukunft?

Matt Mullenweg veröffentlichte einen Artikel mit dem Titel Canonical Plugins Revisited, in dem er erklärte, dass WordPress in Zukunft so entwickelt werden sollte.

Er schrieb:

„Wir erreichen einen Punkt, an dem der Kern redaktioneller sein muss und ‚Nein‘ zu Funktionen sagen muss, die so pünktlich eintreffen, wie sie es manchmal tun, und ich hoffe, dass mehr Make-Teams dies als Gelegenheit nutzen, die Zukunft von WordPress durch ein zu beeinflussen Plugin-zentrierter Ansatz, der ihnen den Luxus schnellerer Entwicklungs- und Veröffentlichungszyklen (statt dreimal pro Jahr), weniger Überprüfungsaufwand und einen Weg gibt, dem sie folgen können, wenn das Plugin ein überwältigender Erfolg wird.

Das erste Opfer dieses neuen Ansatzes ist das Rollback der WebP-Bildkonvertierungsintegration in der nächsten Version von WordPress, WordPress 6.1, die derzeit für November 2022 geplant ist.

Plugin-First ist umstritten

Der Wechsel zu einem Plugin-basierten Entwicklungsprozess wurde in den Kommentaren diskutiert.

Einige Entwickler, wie etwa der Hauptverantwortliche Jon Brown, haben Vorbehalte gegenüber dem Vorschlag geäußert, zur Entwicklung mit kanonischen Plugins überzugehen.

Sie kommentierten:

„Das Problem bleibt, dass es zu viele komplizierte Plugins gibt, die ein einfaches optionales Feature ersetzen.

Plugins sind _keine_ nutzerfreundliche Möglichkeit zur Grundeinstellung. Early Adopters müssen herausfinden, dass es ein Plugin gibt, und dann einen weiteren Einstellungsbildschirm sowie Updates und Wartung für dieses Plugin aushandeln.

Der Kommentator verwendete das Beispiel einer Kommentarfunktion, die derzeit von mehreren aufgeblähten Plugins als nicht ideale Benutzererfahrung bereitgestellt wird.

Sie stellten fest, dass ein kanonisches Plugin zur Behebung eines Problems besser ist als der aktuelle Zustand, in dem wünschenswerte Optionen nur in aufgeblähten Plugins von Drittanbietern zu finden sind.

Sie sagten aber auch, dass eine Einstellungsoption im Kern ohne die Notwendigkeit eines Plugins eine bessere Benutzererfahrung bieten könnte.

Sie fuhren fort:

„Jetzt denke ich, dass kanonische Plugins eine bessere Situation sind als mehr als 6 aufgeblähte Plugins wie die, die hier existieren, aber das würde auch ein einzelnes Kontrollkästchen tun, das der Einstellungsseite im Kern hinzugefügt wird, um dies zu tun. Dies würde die inhärenten UX- und Erkennungsprobleme weiter verbessern bei Plugins.

Am Ende äußerte der Kommentator die Idee, dass das Konzept der kanonischen Plugins eine Möglichkeit zu sein schien, Diskussionen darüber zu beenden, welche Funktionen zu berücksichtigen sind, sodass die Konversation nie stattgefunden hat.

„Kanonische Plugins“ scheinen ein bewaffnetes Werkzeug zu sein, um Diskussionen zu entgleisen, so wie es seit Jahren „Entscheidungen statt Optionen“ sind. »

Diese letzte Aussage bezieht sich auf die Frustration, die einige zentrale Mitwirkende über die Unfähigkeit empfanden, Optionen für Features hinzuzufügen, aufgrund der Philosophie „Entscheidungen, nicht Optionen“.

Andere waren auch mit dem Ansatz des Plugins nicht einverstanden:

„Das kanonische Plugin sieht großartig aus, aber es wird den Wartungsaufwand für die Betreuer weiter erhöhen.

Meiner Meinung nach ist es nicht möglich.

Es ist viel besser, einige grundlegende Funktionen in den Kern selbst aufzunehmen, anstatt weiter zu sagen – Dies ist ein guter Ort für das Plugin.

Jemand anderes wies auf einen Fehler in Plugin-First hin, der darin besteht, dass das Sammeln von Benutzerfeedback möglicherweise nicht einfach ist. Wenn dies der Fall ist, gibt es möglicherweise keine gute Möglichkeit, Plugins so zu verbessern, dass sie den Benutzeranforderungen entsprechen, wenn diese Anforderungen unbekannt sind.

Sie schrieben:

„Wie können wir Benutzerfeedback besser sammeln?

Sofern Website-Eigentümer nicht sachkundig genug sind, um Probleme auf GitHub oder Trac zu melden (seien wir ehrlich, niemand meldet Plugin-Probleme auf Trac), gibt es wirklich keine Möglichkeit, Benutzerfeedback zu sammeln, um diese empfohlenen/offiziellen Plugins zu verbessern. “

Kanonische Plugins

Die WordPress-Entwicklung entwickelt sich weiter, um Verbesserungen schneller vorzunehmen. Das Feedback von wichtigen Mitwirkenden zeigt, dass es viele ungelöste Fragen dazu gibt, wie dieses System für Benutzer funktionieren wird.

Ein Frühindikator wird sein, was mit der gestrichenen WebP-Funktionalität passieren wird, die zuvor in den Kern integriert werden sollte und nun ein Plugin wird.


Ausgewähltes Bild von Shutterstock/Romantic Studio


Blog In 2021 joker0o xyz

Comments
No comments
Post a Comment



    Reading Mode :
    Font Size
    +
    16
    -
    lines height
    +
    2
    -