Einstellungen API vs Theme Customizer

Wann ist es angebracht, die Einstellungs-API zu verwenden, und wann ist es besser, den Theme-Customizer zu verwenden?

Nachdem ich den ganzen Morgen gegoogelt habe, konnte ich in dieser Angelegenheit keine gut überlegte und aktuelle Anleitung finden. Ich bin der Meinung, dass der Theme-Customizer ein eindrucksvoller erster Schritt ist, um mehr Funktionen für die Bearbeitung im Squarespace-Stil bereitzustellen . Kennt jemand Pläne, die Einstellungs-API zugunsten des Theme-Customizers zu beenden? Sollten wir alle langsam darauf zugehen oder sollten wir uns besser an die Einstellungs-API halten? Können sie nebeneinander leben, und wenn ja, wo würde die Aufteilung der Zuständigkeiten liegen?

settings-api theme-customizer

— Dre
quelle

Antworten:

Die Prämisse der Frage ist fehlerhaft. Die Customizer API ist keine Optionen API, sondern eine Option Vorschau - API. Die Customizer-API verwendet entweder die Settings-API oder die Theme Mods-API , um Steuerelemente für vorhandene Einstellungen zu registrieren, die über eine der beiden APIs hinzugefügt wurden.

Der Customizer kann und kann keine neuen Einstellungen definieren / registrieren , die noch nicht über die Einstellungs-API oder die Theme Mods-API registriert wurden. Anders ausgedrückt: Die Customizer-API ist keine API zum direkten Hinzufügen von Einstellungen zu oder zum Abrufen von Einstellungen direkt aus der Datenbank. Die Customizer-API verwendet stattdessen entweder die Settings-API oder die Theme Mods-API, um Einstellungen in der Datenbank zu speichern oder Einstellungen aus dieser abzurufen.

Daher ist die Customizer-API keine Alternative zu einer der vorhandenen Options-APIs . Es ist eher eine Alternative für eine Einstellungsseite . Dem Customizer ist es egal, ob eine Einstellung über die Settings API oder die Theme Mods API registriert wird. Solche Einstellungen können im Customzer gemischt und abgeglichen werden. In der Tat, in den meisten Fällen solche Einstellungen sind gemischt und abgestimmt: benutzerdefinierten Header und benutzerdefinierten Hintergrund sind Thema Mods und Site Titel und Beschreibung sind Einstellungen API.

Um genau zu verstehen, wie Einstellungen und Steuerelemente über die Customizer-API registriert werden, empfehle ich, die hervorragenden Tutorials von Otto zu lesen:

So ist die Frage nicht , entweder / oder in Bezug auf die angegebenen APIs. Geeignete entweder / oder Fragen wären:

Verwenden Sie entweder die Einstellungs-API oder die Theme Mods-API , um vorhandene Einstellungen für die Vorschau über die Customizer-API zu registrieren
Verwenden Sie entweder die Customizer-API oder eine Seite mit benutzerdefinierten Designeinstellungen , damit der Benutzer Designoptionen konfigurieren kann .

— Chip Bennett
quelle

Vielen Dank, Chip. Ich folge dir immer noch nicht zu 100% , aber du hast mir genug gegeben, um das Problem noch einmal zu untersuchen. Ich denke, meine Verwirrung ergibt sich aus der Überlappung in der Funktionalität und der Ähnlichkeit in den Namen. Gibt es eine Seite, die die Anwendungsfälle der verschiedenen APIs (in einer abstrakteren Art und Weise) klar dokumentiert? Ich hatte nicht viel Glück, als ich den Kodex durchgesehen habe. Es konzentriert sich nur auf das Wesentliche beim Anwenden der API.

— Dre

Ich habe mehr hinzugefügt, um zu versuchen, es ein bisschen genauer zu erklären. Siehe insbesondere auch die Links zu Ottos Customizer-Tutorials; Ich denke, sie werden helfen, die Dinge zu klären.

— Chip Bennett

Sie, mein Herr, sind ein Gentleman.

— Dre

So einfach kann es manchmal sein: Die Einstellungs-API ist nicht der Theme Customizer. Beides sind unterschiedliche Dinge für unterschiedliche Aufgaben.

Einstellungs-API

Sie schreiben entweder ein Plugin oder haben ein Thema ohne Optionen, für das kein visuelles Feedback erforderlich ist? Gehen Sie mit dieser Option.

Theme Customizer

Sie benötigen Optionen mit visuellen Auswirkungen, die der Benutzer sehen sollte? Gehen Sie mit dieser Option.

— Kaiser
quelle

Dies war meine erste Schlussfolgerung. Es gibt jedoch eine große funktionale Überschneidung zwischen den beiden, was zu den ursprünglichen Fragen führt. Außerdem erscheint mir die Idee, die Themenoptionen in zwei Bereiche zu unterteilen, je nachdem, ob sie visuell sind oder nicht, aus UX-Sicht problematisch. Das heißt nicht, dass ich mit Ihnen nicht einverstanden bin; Ich bin gerade dabei, Meinungen einzuholen. Das ganze Thema selbst ist etwas düster. Vielleicht wäre eine gut definierte Anleitung „von oben“ von Vorteil. Danke für deinen Beitrag!

— Dre

@Dre Vermutlich haben Sie es ein bisschen falsch verstanden: Wenn Sie auch nur eine einzige Option haben, für die visuelles Feedback erforderlich ist, wählen Sie den ThemeCustomizer. Die Faustregel lautet also: Theme -> Theme Customizer | Plugin -> Einstellungen API.

— Kaiser

In der Regel sollten alle themendefinierten Optionen eine Präsentationswirkung haben. :) Das heißt: Die Anpassungs-API benötigt entweder die Einstellungs-API oder die Theme Mods-API, um zu existieren. Die Anpassungs-API ist keine Alternative für eine dieser beiden APIs, sondern eine Alternative für eine Seite mit benutzerdefinierten Designeinstellungen .

— Chip Bennett

Haben Sie Probleme mit der Reaktionsfähigkeit des Customizers? Für mich scheint es sowohl in 3.5.1 als auch in 3.6 (trunk) ziemlich temperamentvoll zu sein. Ich finde, dass die Schaltflächen Überschrift und Schließen / Speichern oft nicht richtig auf Klicks reagieren und manchmal mehrmals darauf klicken müssen (und noch mehr im Kofferraum). Dies ist sowohl in FF als auch in Chrome möglich.

— 1.

@t31os Hatte dieses Problem schon mal, aber ohne Konsistenz. Habe es aber schon länger nicht mehr versucht. Ich würde console.log()all deinen Aktionen vorschlagen, damit du siehst, was ausgelöst wird und was dich stört. JavaScript-Debugging ist nicht einfach ...

— Kaiser