Matt Mullenweg, Entwickler von WordPress und CEO von Automatic, schlug vor, keine neuen Funktionen mehr zu WordPress hinzuzufügen und stattdessen zu einer Plugin-First-Richtlinie überzugehen.
Dieser neue Ansatz für die Zukunft von WordPress hat bereits zu einer neuen Funktion geführt, die für die nächste Version von WordPress vorgesehen ist und vollständig fallen gelassen werden soll.
Kanonische Plugins sollen eine Möglichkeit bieten, WordPress schneller zu verbessern.
Aber einige WordPress-Core-Mitwirkende äußerten die Meinung, dass die Benutzererfahrung des Publishers darunter leiden könnte.
Kanonische Plugins
Kanonische Plugins wurden erstmals 2009 diskutiert und sind eine Möglichkeit, neue Funktionen in Form von Plugins zu entwickeln.
Das Ziel dieses Ansatzes ist es, den WordPress-Kern schnell und schlank zu halten und gleichzeitig die Entwicklung experimenteller Funktionen in Form von Plugins zu fördern.
Der ursprüngliche Vorschlag von 2009 beschrieb es so:
„Kanonische Plugins wären Plugins, die von der Community entwickelt wurden (mehrere Entwickler, nicht nur eine Person) und die beliebtesten Funktionsanforderungen mit hervorragender Ausführung erfüllen.
… Es würde eine sehr starke Beziehung zwischen Core und diesen Plugins geben, die sicherstellt, dass a) der Plugin-Code sicher und das bestmögliche Beispiel für Codierungsstandards ist und b) dass neue Versionen von WordPress vor der Veröffentlichung mit diesen Plugins getestet werden Kompatibilität zu gewährleisten.“
Dieser Ansatz für Funktionen und Optionen wird auch als Plugin First bezeichnet, um zu betonen, wie Funktionen zuerst in Form von Plugins erscheinen.
Diese Plugins werden als kanonisch bezeichnet, weil sie vom WordPress-Core-Entwicklungsteam entwickelt wurden, im Gegensatz zu nicht kanonischen Plugins, die von Drittanbietern erstellt wurden und die Funktionen 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 von der Mehrheit der Benutzer möglicherweise nicht benötigt werden.
Plugin-first könnte im Einklang mit der WordPress-Philosophie genannt werden Entscheidungen, keine Optionendas darauf abzielt, Benutzer nicht mit einer Vielzahl technischer Optionen zu belasten.
Durch das Auslagern verschiedener Features und Funktionalitäten in Plugins muss sich ein Benutzer nicht durch das Aktivieren oder Deaktivieren von Funktionen kämpfen, die er benötigt, nicht benötigt oder nicht versteht.
Die WordPress-Designphilosophie besagt:
„Es ist unsere Pflicht als Entwickler, intelligente Designentscheidungen zu treffen und zu vermeiden, dass unsere Endbenutzer das Gewicht technischer Entscheidungen tragen.“
Kanonische Plugins die Zukunft?
Matt Mullenweg veröffentlichte einen Beitrag mit dem Titel Kanonische Plugins überarbeitetin dem er argumentierte, dass WordPress auf diese Weise weiter entwickelt werden sollte.
Er schrieb:
„Wir erreichen einen Punkt, an dem der Kern redaktioneller sein muss und „nein“ zu Funktionen sagen muss, die so ad hoc kommen, wie sie es manchmal tun, und ich hoffe, dass mehr Make-Teams dies als Gelegenheit nutzen, um die Zukunft von WordPress zu beeinflussen ein Plugin-First-Ansatz, der ihnen den Luxus schnellerer Entwicklungs- und Veröffentlichungszyklen (statt dreimal pro Jahr), weniger Überprüfungsaufwand und einen Weg zum Core bietet, wenn das Plugin ein durchschlagender Erfolg wird.“
Das erste Opfer dieses neuen Ansatzes ist die Abbruch der Integration der WebP-Bildkonvertierung in die nächste Version von WordPress, WordPress 6.1, aktuell geplant für November 2022.
Plugin-First ist umstritten
Die Umstellung auf einen Plugin-First-Entwicklungsprozess wurde in den Kommentaren diskutiert.
Einige Entwickler, wie z. B. Core Contributor Jon Braunäußerte Vorbehalte gegen den Vorschlag, auf die Entwicklung mit kanonischen Plugins umzusteigen.
Sie kommentiert:
„Das Problem bleibt, dass es zu viele komplizierte Plugins gibt, die ein einfaches optionales Feature ersetzen.
Plugins sind _keine_ benutzerfreundliche Option für Kerneinstellungen. Zuerst müssen die Benutzer feststellen, dass es ein Plugin gibt, dann haben sie noch einen weiteren Einstellungsbildschirm und Updates und Wartung dieses Plugins ausgehandelt.“
Der Kommentator verwendete das Beispiel einer Kommentarfunktion, die derzeit von mehreren aufgeblähten Plugins als weniger als ideale Benutzererfahrung bereitgestellt wird.
Sie stellten fest, dass ein einziges kanonisches Plugin zur Lösung eines Problems dem aktuellen Stand vorzuziehen ist, in dem wünschenswerte Optionen nur in aufgeblähten Plugins von Drittanbietern zu finden sind.
Aber sie sagten auch, dass eine Einstellungsoption innerhalb des Kerns ohne die Notwendigkeit eines Plugins eine bessere Benutzererfahrung bieten könnte.
Sie fuhren fort:
„Nun, ich denke, Canonical-Plugins sind eine bessere Situation als mehr als 6 aufgeblähte Plugins, wie sie hier existieren, aber auch ein einziges Kontrollkästchen, das der Einstellungsseite im Kern hinzugefügt wird, um dies zu tun. Das würde die mit Plugins verbundenen UX- und Discovery-Probleme weiter verbessern.“
Letztendlich äußerte der Kommentator die Idee, dass das Konzept der kanonischen Plugins eine Möglichkeit zu sein schien, Diskussionen über Funktionen, die in Betracht gezogen werden sollten, zu beenden, damit die Konversation nie stattfindet.
„Kanonische Plugins“ scheinen ein waffenfähiges Werkzeug zu sein, um Diskussionen zu entgleisen, so wie es seit Jahren „Entscheidungen statt Optionen“ sind.“
Diese letzte Aussage bezieht sich auf die Frustration einiger wichtiger Mitwirkender aufgrund der Unfähigkeit, Optionen für Funktionen hinzuzufügen, aufgrund der Philosophie „Entscheidungen, nicht Optionen“.
Andere waren auch mit dem Plugin-First-Ansatz nicht einverstanden:
„Das kanonische Plugin klingt großartig, aber es wird den Wartungsaufwand für die Betreuer weiter erhöhen.
Meiner Meinung nach geht das nicht.
Es wird viel besser sein, einige grundlegende Funktionen in den Kern selbst aufzunehmen, anstatt weiter zu sagen – Es ist ein guter Ort für Plugins.“
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 schrieb:
„Wie können wir Feedback von Benutzern besser erfassen?
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, Feedback von Benutzern zu sammeln, um diese empfohlenen/offiziellen Plugins zu verbessern. „
Kanonische Plugins
Die WordPress-Entwicklung entwickelt sich weiter, um Verbesserungen schneller vorzunehmen. Die Kommentare der wichtigsten Mitwirkenden weisen darauf hin, dass es viele ungelöste Fragen dazu gibt, wie gut dieses System für Benutzer funktionieren wird.
Ein Frühindikator wird sein, was mit dem gestrichenen WebP-Feature passiert, das zuvor in den Kern integriert werden sollte und nun ein Plugin wird.
Ausgewähltes Bild von Shutterstock/Studio Romantic
