Filter zum Deaktivieren des Customizer Shot Down auf WordPress Trac

WordPress 4.3 führt die Menüverwaltung über den Customizer ein und bietet Live-Vorschauen im Frontend zum Hinzufügen, Löschen und Bestellen von Menüelementen. Obwohl Benutzer immer noch die Möglichkeit haben, Menüs über die Admin-Oberfläche zu verwalten, suchen Entwickler, die an dieser Funktion nicht interessiert sind, nach einer einfachen Möglichkeit, den Customizer zu deaktivieren und seine Links in WordPress zu entfernen.

In bestimmten Szenarien mit Client-Arbeit kann der Customizer mehr Ärger bereiten, als er wert ist, und ist möglicherweise keine nützliche Ergänzung zu einem maßgeschneiderten WordPress-Admin.

@pollyplummer sehr interessant. Ich bin nicht gegen die neuen Updates, aber der Customizer ist die Hölle in der Agenturwelt.

– Edward McIntyre (@twittem) 24. Juni 2015

Gabe Shackle, ein Anwendungsentwickler und UI-Ingenieur bei Risdall, hat letzte Woche ein Ticket auf WordPress Trac erstellt und einen Filter angefordert, um den Customizer zu deaktivieren. Sein Patch bietet Entwicklern eine einfache Möglichkeit, die Klasse „no-customizer-support“ innerhalb des Body-Tags zu aktivieren.

Aufgrund der Tatsache, dass die Klasse „customizer-support“ über JavaScript beim Seitenrendering hinzugefügt wird, kann sie derzeit nicht mit Kernfiltern oder -aktionen manipuliert werden.

Indem Sie den Filterwert auf „false“ setzen, wird der Customizer im Wesentlichen vor dem Administrator verborgen, und die Links, die derzeit auf den Customizer verweisen (Widgets, Themen usw.), werden auf ihre vorherigen Dashboard-Ziele zurückgesetzt.

Derzeit müssen Entwickler, die den Customizer deaktivieren möchten, eine Kombination verschiedener Methoden anwenden, um effektiv alles zu entfernen, was der Customizer in den Admin einführt.

„Dieser Filter macht diesen Prozess zu einem einfachen booleschen Filter, sodass Entwickler, die den Customizer nicht wollen oder brauchen, ihn einfach entfernen können“, sagte Shackle.

Der führende WordPress-Entwickler Dion Hulse antwortete auf das Ticket und sagte, dass er den Customizer zwar selbst nicht oft verwende, aber nicht glaube, dass WordPress-Benutzer von einer einfachen Möglichkeit profitieren würden, ihn auszuschalten.

Obwohl ich den Customizer nicht oft verwende, denke ich persönlich, dass das Anbieten eines Filters zum Deaktivieren wahrscheinlich nicht im besten Interesse der WordPress-Benutzer ist.

Der Customizer, so sehr ihn manche nicht mögen, ist ein wichtiger Bestandteil der Zukunft von WordPress UX – ob das eine gute oder schlechte Sache ist, bleibt von einigen abzuwarten – aber ob es ihm gefällt oder nicht, er ist da.

Hulse schlug als Alternative vor, dass eine bessere Möglichkeit zum Deaktivieren darin bestünde, die customize aus den Rollen zu entfernen.

Shackle erklärte weiter, dass er versuche, dem Präzedenzfall der Admin-Leiste zu folgen, die er für eine ähnliche Art von UX-Komponente hält.

„Die Admin-Leiste kann nicht nur durch einen Filter, sondern auch durch eine globale Variable, eine Kernfunktion und eine Benutzerprofileinstellung deaktiviert werden“, sagte er. „Der Customizer hat keine dieser Optionen.“

Nick Halsey, der Entwickler des Menu Customizer-Plugins, das in 4.3 integriert wird, antwortete basierend auf Annahmen darüber, warum Shackle einen Filter anfordern könnte, um die Funktion zu deaktivieren:

Ich habe noch keinen triftigen Grund für so etwas gesehen. In den meisten Fällen rührt die Sorge, dass Benutzern kein Zugriff auf den Customizer gewährt werden soll, daher, dass Sie ihnen nicht die entsprechenden Funktionen zur Verfügung stellen. Und die Anpassungsfunktion kann verwendet werden, um den Customizer auszuschalten, wenn Sie es wirklich müssen.

Sie können zwar die Metafunktion zum Anpassen entfernen (oder neu zuordnen oder was auch immer), aber wenn Sie dies einfach tun, weil Sie Benutzer nicht schulen oder den Customizer nicht verwenden möchten, tun Sie sich und Ihren Benutzern einen enormen Gefallen. Wie bereits von dd32 erwähnt, wird der Customizer innerhalb von WordPress weiter an Bedeutung gewinnen. Darüber hinaus haben Benutzertests gezeigt, dass die Customizer-Erfahrung für Benutzer im Allgemeinen einfacher zu verstehen ist als für den Administrator, was größtenteils auf den Wert der verfügbaren Live-Vorschau zurückzuführen ist. Wir investieren bei jeder Version viel Zeit in den Customizer, um ihn weiter zu verbessern, und führen dabei häufige Benutzertests durch, um die Benutzerfreundlichkeit zu optimieren.

Halsey schloss das Ticket nach diesem Austausch umgehend. Ich habe mit Shackle nachgefragt, um herauszufinden, warum die vorgeschlagene Alternative zum Entfernen der customize für seine Zwecke unzureichend ist.

„Hauptsächlich hatte ich gehofft, dass der Customizer eher wie die Admin-Leiste behandelt werden könnte, die mehr als 3 Methoden zum Deaktivieren hat“, sagte Shackle. „Einen klar gekennzeichneten Filter zu haben, ist meiner Meinung nach besser lesbar, als die Benutzerfunktionen zu ändern. Ein PHP-Entwickler mit praktisch keinen WordPress-Kenntnissen könnte höchstwahrscheinlich viel schneller verstehen, was mit einem Filter namens ‚enable_customizer_support‘ statt ‚map_meta_cap‘ passiert.“

Offensichtlich werden nicht alle Tickets und Patches von den Betreuern der WordPress-Kernkomponenten als gültig angesehen, aber Shackle war von der defensiven Reaktion auf die Diskussion enttäuscht.

„Ehrlich gesagt, wenn die Antwort einfach etwas in der Art gewesen wäre wie ‚Sie sollten einfach die customize verwenden, um den gleichen Effekt zu erzielen', hätte ich wirklich keine Probleme gehabt“, sagte er.

„Leider scheint es keinen anderen Ansatz als ‚Customizer for all things!' zu geben. bedeutet, dass mir mehrmals gesagt wird, wie sehr ich meinen Kunden einen Bärendienst tue und was für ein fauler Entwickler ich bin, weil ich meine Kunden nicht nur neu schule, wie sie das Erscheinungsbild ihrer Websites verwalten können.

„Es fühlt sich so an, als ob das Customizer-Team selbst einen Alles-oder-Nichts-Ansatz für das Projekt verfolgt und dass jeder, der dies in Frage stellt, falsch liegt, unabhängig von seiner Argumentation“, sagte Shackle.

Dieser Austausch zeigt, dass, da die wichtigsten Mitwirkenden den Customizer als einen wichtigen Teil der Zukunft von WordPress ansehen, dies ein Feature ist, bei dem es wenig Bereitschaft geben wird, Bemühungen zu unterstützen, es modularer zu machen. Das Deaktivieren der Unterstützung für den Customizer erfordert weiterhin die Verwendung von „map_meta_cap“, der gleichen Methode, die die Entwickler des Customizer Remove All Parts-Plugins verwendet haben.