Fragen Sie den Barkeeper: Was passiert mit dem Customizer, wenn ein Blockdesign aktiv ist?

Etwas auf meinem Radar sind derzeit Plugins von Drittanbietern, die Einstellungen im Customizer haben. Was ich von Freunden sammle, die die Entwickler sind, die an Customizer- und Front-End-Sachen in einigen Plugin-Unternehmen arbeiten, globale Styles und Block-Styles sind noch nicht auf ihrem Radar. Was passiert also, wenn jemand Twenty Twenty-Two oder ein anderes blockbasiertes Design installiert? Das linke Admin-Menü für Customizer ist nicht da. Der ruckelige Weg dorthin führt über Aussehen > Themen > Customizer. Es wird jedoch erwartet, dass Plugins und Designs von Drittanbietern die Einstellungen verschieben müssen. Tatsächlich scheint dies eher so, als müssten sie die Einstellungen an beiden Orten für eine Weile duplizieren.

Anonym

Für diejenigen, die nicht auf dem Laufenden sind, möchte ich dieses Thema kurz auffrischen. Wenn WordPress 5.9 landet, erwarten wir, dass es mit dem neuen Website-Editor und der globalen Styles-Oberfläche ausgeliefert wird. Die meisten Benutzer sehen diesen Bildschirm jedoch nur, wenn sie ein Blockdesign ausführen.

Angesichts der Tatsache, dass das kommende Twenty Twenty-Two auch mit WordPress 5.9 ausgeliefert wird und wenn wir die Popularität früherer Standardthemen beurteilen, können wir davon ausgehen, dass viele tausend Benutzer in diese ganz neue Welt versetzt werden. Für einige mag dies so schockierend sein wie die Einführung des Blockeditors in 5.0.

Wenn ein Blockdesign aktiv ist, verschwinden Links zum Zugriff auf den alten und vertrauten Customizer von der Benutzeroberfläche. Die Widgets und Navigationsmenübildschirme werden ebenfalls nicht vorhanden sein. Sie sind jedoch weiterhin zugänglich, wenn Sie die URL für die Bildschirme kennen.

Wir haben zum ersten Mal im vergangenen Jahr im Rahmen der Veröffentlichung von Gutenberg 9.3 erfahren, dass dies der Fall sein würde. Es gibt auch ein offenes Problem, um sicherzustellen, dass der Website-Editor mit einigen WordPress-Kerneinstellungen identisch ist.

Es ist in Ordnung, dass diese Funktionen für Benutzer von Blockdesigns auslaufen. Sie alle waren frühe, unterschiedliche Versuche, einzelne Teile dessen zu erstellen, was der Site-Editor zulässt. WordPress bringt all diese Konzepte zu einem zusammenhängenderen Benutzererlebnis zusammen. Es ist ein Standard, den Mitwirkende kontinuierlich wiederholen können. Es wird nicht von Anfang an perfekt sein, aber diese erste Version in der Kernplattform sollte das Feedback anregen, das zur Verbesserung erforderlich ist, da immer mehr Benutzer mit der Installation von Blockthemen beginnen.

Das hier dargestellte Problem hat eher mit dem Plugin-Markt zu tun. Der Customizer wurde ursprünglich als Design-Einstellungstool entwickelt und wurde hauptsächlich für diesen Zweck verwendet. Aber viele Plugins haben in ihrer neunjährigen Geschichte verschiedene Einstellungen daran gebunden. Eine Suche nach wp_customize im Plugin-Verzeichnis liefert über 1.400 Ergebnisse. Der Hook customize_register zeigt über 1.900 an. Dies sind nicht unbedingt genaue Übereinstimmungen dafür, wie viele Plugins tatsächlich Bedienfelder, Abschnitte, Einstellungen oder Steuerelemente hinzufügen. Es ist jedoch ein Indikator dafür, dass sich viele darauf verlassen, um Endbenutzern Optionen zu präsentieren.

Damit sind wir wieder bei der eigentlichen Frage. Was passiert, wenn ein Benutzer ein Blockdesign wie das kommende Twenty Twenty-Two installiert, während er ein Plugin verwendet, das auf den Customizer angewiesen ist?

Es hängt davon ab, ob.

Einige Plugins wie WooCommerce haben bereits praktischerweise einen direkten Link zu ihrem Customizer-Panel/Abschnitt im Admin-Menü platziert. Dies wird kein Problem für ihre Benutzer sein. Für alle anderen scheint der Customizer jedoch vollständig zu verschwinden.

In wenigen Wochen nach 5.9 könnten wir, je nachdem, wie schnell die Akzeptanz von Twenty Twenty-Two erfolgt, Tausende von verwirrten Benutzern betrachten. All dies kann sich natürlich bis zur Veröffentlichung ändern. Dies ist jedoch ein Gespräch, das jetzt stattfinden muss.

„Die Sorge gilt hier den Endbenutzern“, sagte der anonyme Fragesteller. „Sie werden sich Knowledgebase-Artikel, Anleitungen zu Plugin-Einstellungen und mehr ansehen, die angeben, wo sie nach den Einstellungen suchen müssen.“

Zumindest im Moment liegt die Verantwortung bei den Plugin-Autoren, dies für ihre eigenen Benutzer anzugehen. Es gibt jedoch mehrere Wege, die sie vielleicht gehen möchten.

Die einfachste Methode ist, dem Beispiel von WooCommerce zu folgen. Das Plugin prüft die Bedingung gutenberg_is_fse_theme() (beachten Sie, dass sich dieser Funktionsname ändern kann). Wenn es true zurückgibt, fügt das Plugin einen Link direkt zu seinem Customizer-Panel hinzu.

Das Verknüpfen mit einem Customizer-Panel, -Abschnitt oder -Steuerelement ist einfach. Plugin-Autoren finden die URLs im Entwicklerhandbuch. Sie können auch einfach die Technik kopieren, die das WooCommerce-Team verwendet hat.

Dies ist eine schnelle Methode, um sicherzustellen, dass Benutzer nicht den Zugriff auf ihre Optionen verlieren, wenn Plugin-Autoren keine Änderungen vornehmen können, bevor WordPress 5.9 landet.

Langfristig ist es nicht die ideale Lösung. Den Customizer wird es noch lange geben, aber Plugin-Autoren müssen sich mit zwei Gruppen von Benutzern auseinandersetzen: denen, die sowohl Block- als auch klassische Themen ausführen.

Da jedes Plugin anders ist, müssen Lösungen unterschiedlich sein. Viele können einfach die Einstellungs-API verwenden, um einen benutzerdefinierten Optionsbildschirm zu erstellen. Wenn dies eine praktikable Lösung ist, spielt es keine Rolle, welches Design der Benutzer ausführt.

Die Realität könnte jedoch darin bestehen, zwei Systeme für beide Benutzergruppen zu unterhalten. Eines, das sich in den Customizer integriert, und ein anderes, das Optionen in den Site-Editor zieht. Wenn das Plugin über designbezogene Funktionen verfügt, erwarten Benutzer von Blockdesigns Einstellungen in der neuen Benutzeroberfläche.

Auf der Themenseite sollte es weniger Probleme geben. Ein Block-Theme macht sowieso nichts mit dem Customizer. Ein ausstehendes Problem wäre die Konvertierung von Starter-Inhalten, und es gibt ein offenes Ticket, um dies in die vollständige Site-Bearbeitung zu bringen.

Mehr als alles andere wird die Aufrechterhaltung offener Kommunikationswege mit den Benutzern dazu beitragen, den Übergang zu erleichtern. Ein Teil davon sollte aus dem Kern von WordPress stammen. Viele Benutzer müssen es jedoch von ihren Plugin- und Theme-Entwicklern hören. Dies können Blog-Posts, Wissensdatenbank- oder Tutorial-Updates sein und mit dem Support Schritt halten.

Dann gibt es die endgültige Lösung, die WordPress selbst implementieren könnte. Es ist auch der Weg des geringsten Widerstands.

WordPress sollte automatisch Filter oder Aktionen auf Customizer-bezogenen Hooks erkennen. Dies sollte ein Flag „Support anpassen“ auslösen und das Admin-Menü und die Symbolleisten-Links zum Customizer-Bildschirm beibehalten. Dies würde den Entwicklern etwas Zeit geben, aufzuholen, ohne dabei die Benutzer zu verwirren. Es mag ein paar False Flags oder verpasste Integrationen geben, aber es sollte in der Lage sein, die Mehrheit der Anwendungsfälle effektiv zu erfassen.