Offene Umfrage für WordPress-Theme-Autoren zu JSON-Dateien und Block-Themen

WordPress 5.8 hat ein Opt-in-System für Themes eingeführt, um Blockeinstellungen, Stile, Vorlagen und mehr zu konfigurieren. Dies erfolgt über eine neue theme.json -Datei, die Autoren im Stammverzeichnis ihrer Designordner ablegen können. Anne McCarthy, die Leiterin des FSE Outreach-Programms, kündigte heute früher eine Umfrage an, um Feedback von Entwicklern zu dieser Funktion zu erhalten.

„Da dieser neue Mechanismus ein früher Schritt in Richtung eines umfassenden Stilsystems für die Zukunft von WordPress ist, ist es wichtig, von allen zu hören, die derzeit theme.json verwenden, um mehr darüber zu erfahren, wie Leute dieses Tool verwenden und was sinnvoll sein könnte in Core in Zukunft“, schrieb sie in der Ankündigung.

Die Umfrage steht allen Themenautoren offen, die theme.json verwendet haben, und gibt ihnen die Möglichkeit, frühzeitig Feedback abzugeben und dabei zu helfen, das Schiff voranzubringen.

Da ich in den letzten Monaten intensiv mit diesem System gearbeitet habe, hatte ich einiges zu sagen. Außerdem nehme ich einfach gerne an WordPress-bezogenen Umfragen teil. Ich entschied auch, dass dies eine Gelegenheit wäre, einige meiner ungefilterten Gedanken aus Entwicklungssicht zum aktuellen Stand von theme.json zu teilen.

Was folgt, sind meine Antworten auf die Fragen der Umfrage – nun ja, die aufgeräumte Version.

Hinweis: Dies ist ein entwicklerzentrierter Beitrag, der möglicherweise nicht alle unsere Leser anspricht. Ich habe versucht, einige Dinge in benutzerfreundlicher Terminologie zu erklären, aber einige Grundkenntnisse der Themenentwicklung können erforderlich sein.

Erfahrung

Die erste Frage der Umfrage ist ziemlich banal. Es fragt Sie nach Ihren Erfahrungen mit Bausteindesigns oder mit theme.json . Es bietet vier Auswahlmöglichkeiten (und eine „andere“ Option):

• Ich habe Blockthemen erstellt und gestartet.
• Ich habe mit Bausteinthemen experimentiert.
• Ich habe die Verwendung von theme.json mit einem klassischen Design untersucht.
• Ich habe ein Blockdesign verwendet, aber noch keins erstellt.

Ich habe mich für die erste Option entschieden, weil ich bereits zwei Blockthemen für Familie und Freunde gebaut habe. Dies waren einfache persönliche Websites, die ich bereits kostenlos betreue – ehrlich gesagt, ich muss mit dem Aufladen beginnen . Ich arbeite auch an einem Thema, das ich hoffentlich öffentlich veröffentlichen kann.

Wie es begann und wie es läuft

Die zweite Frage fragt, wie man mit Blockthemen und theme.json . Sie haben die Wahl, ein vorhandenes Thema zu forken, das leere Thema zu verwenden oder ganz von vorne zu beginnen.

Auch dies ist eines dieser Dinge, bei denen ich mit jeder Richtung experimentiert habe, aber ich kann mich nicht an den genauen Ausgangspunkt erinnern. Der Großteil meiner Arbeit stammt aus der Forkierung eines Themas, an dem ich zuletzt 2019 gearbeitet habe.

Ich plane, dies irgendwann als neues Thema kostenlos zu veröffentlichen. Ich warte meistens auf folgendes:

• Entwicklung von Navigationsblöcken, um sich niederzulassen
• Der Post-Autor-Block soll in kleinere Blöcke aufgeteilt werden
• Ein robuster Satz kommentarbezogener Blöcke
• Veröffentlichen Sie den Featured Image-Block, um eine Größenoption zu haben

Ich denke, ich könnte heute realistischerweise eine Beta-Version meines Designs auf eigene Gefahr veröffentlichen, wenn diese Punkte behoben würden.

Vorlagen und Vorlagenteile

Die Umfrage fragte, welche Templates und Template-Teile Themes immer in ihre blockbasierten Themes aufnehmen. Es gab ein Freiform-Kommentarfeld – Schritte auf Seifenkiste …

Ich habe im Moment eine Hassliebe zu Blockvorlagen. Die statische Natur von HTML-Vorlagen erinnert mich an einfachere Zeiten, als die Themenentwicklung weniger kompliziert war. Dies stellt jedoch auch ein Problem in einem dynamischen System dar.

Ich kann mich nicht erinnern, wann ich das letzte Mal ein traditionelles, PHP-basiertes Design mit mehr als einem Top-Level-Template erstellt habe: index.php . Die dynamischen Stücke waren schon immer der Kern der Sache, die Vorlagenteile sind. Mit PHP ist es einfach, eine Variable festzulegen oder einen Funktionsaufruf zu verwenden, um kontextbezogen die Vorlagenteile zu laden, die für die Seite erforderlich sind, die ein Besucher gerade auf einer Website anzeigt.

Das Blockvorlagensystem funktioniert so nicht. Es zwingt Entwickler im Wesentlichen dazu, das Don't Repeat Yourself (DRY)-Prinzip zu brechen.

Wenn ein Designer beispielsweise einen anderen Header-Template-Teil für Seiten und Beiträge anzeigen möchte, müsste er in herkömmlichen Themes nur ein header-page.php oder header-post.php Template erstellen. Da das Blockvorlagensystem jedoch anders ist, müssen sie jetzt zwei Vorlagen der obersten Ebene erstellen, single.html (post) und page.html , um dasselbe zu erreichen.

Dies ist eine „schlechte Sache“, da Themenautoren den gesamten anderen Code in jeder der Vorlagen der obersten Ebene duplizieren müssen. Es gibt keine Möglichkeit, verschiedene Vorlagenteile kontextbezogen zu laden.

Um die Frage zu beantworten: Ich verwende fast alle möglichen Top-Level-Vorlagen aus Notwendigkeit.

Ich habe auch den zweiten Teil der Frage beantwortet und meine am häufigsten verwendeten Vorlagenteile aufgelistet (unterteilt nach Hierarchie):

• Header
• Inhalt
  – Schleife
  – Seitenleiste
• Fusszeile

Die Vorlagenteile content-*.html und loop-*.html sind diejenigen mit den meisten Variationen.

Farben definieren

Im nächsten Abschnitt der Umfrage wird gefragt, wie Theme-Autoren ihre Farbpaletten-Slugs in theme.json definieren. Ob Sie es glauben oder nicht, die Benennung von Farben ist möglicherweise das umstrittenste Thema in der Themenwelt seit Jahren. Die einzigen zwei Dinge, auf die man sich allgemein geeinigt hat, sind „Hintergrund“- und „Vordergrund“-Farben.

Morten Rand-Hendriksen eröffnete 2018 ein Ticket zur Standardisierung eines Benennungsschemas für Themenfarben. Es war nicht das erste Gespräch und es war nicht das letzte. Das Problem, das es ansprechen sollte, waren die Slugs für Farben im System, wodurch Themen ihre Paletten definieren. Sobald ein Benutzer eine voreingestellte Farbe verwendet, wird der Slug fest in seinen Inhalt codiert. Wechseln Sie zu einem anderen Thema mit anderen Slugs, und die alten Farben verschwinden und wechseln nicht automatisch zu den Farben des neuen Themas.

Ich verwende semantische Namen, die etwas folgen, das dem Schattierungssystem des CSS-Frameworks von Tailwind sehr ähnlich ist. Anstelle von red-medium (beschreibend) würde ich beispielsweise primary-500 (semantisch) verwenden. Ein semantischer Ansatz würde es Themenautoren ermöglichen, eine Reihe von Farben zu definieren, die jedes Mal aktualisiert werden, wenn ein Benutzer die Themen wechselt.

Natürlich gibt es andere Denkrichtungen, und selbst alle, die eine semantische Benennung bevorzugen, sind sich nicht über dasselbe System einig. Ich habe meinen Ansatz in einem neueren GitHub-Ticket ausführlicher beschrieben und habe eine theme.json Gist für andere, die es vielleicht ausprobieren möchten.

Andere Design-JSON-Einstellungen

Abgesehen von Farben und Typografie fragt die Umfrage, welche anderen Einstellungen Themenautoren verwendet haben. Dies ist ein weiteres Szenario, in dem ich normalerweise alles verwende – wenn es eine Option dafür gibt, definiere ich sie.

Ein Anwendungsfall, für den WordPress derzeit keine Voreinstellung hat, ist der globale Abstand. Die meisten Themenautoren verwenden einen einzelnen Wert für die meisten vertikalen Ränder (Leerzeichen zwischen Blöcken und Elementen). Es wird auch häufig für standardmäßiges vertikales und horizontales Auffüllen verwendet.

Ich bin mir nicht sicher, ob ich ein Preset möchte, weil ich nicht weiß, wie WordPress es verwenden wird. Es ist etwas, wonach andere gefragt haben, und es ist fast allgegenwärtig in Gebrauch. Das Definieren eines ganzen Systems darum herum könnte später Kopfschmerzen verursachen, aber ich würde immer noch gerne eine Diskussion über die Implementierung zumindest einer standardmäßigen globalen Abstandsvoreinstellung sehen.

Einstellungen und Stile pro Block

Dieser Umfrageabschnitt war eine Ja/Nein-Frage, bei der lediglich gefragt wurde, ob Themenautoren Einstellungen oder Stile pro Block in ihre theme.json -Dateien aufgenommen haben. Natürlich habe ich später im optionalen Kommentarbereich einige zusätzliche Kommentare hinterlassen.

Ich bin zufrieden mit dem System, wenn es um Einstellungen geht, die es Themen ermöglichen, zu definieren, welche Funktionen global oder auf Blockbasis aktiviert werden. Ich bin jedoch nicht davon überzeugt, Stile über theme.json .

Das Schreiben von CSS in JSON, worüber wir im Wesentlichen sprechen, fühlt sich auf so vielen Ebenen falsch an. Derzeit ist es auf nur wenige konfigurierbare Stile beschränkt, sodass alles darüber hinaus sowieso in eine tatsächliche CSS-Datei eintauchen muss. Das ist problematisch, weil die Hälfte des CSS-Codes des Themes zwischen theme.json und einer separaten CSS-Datei aufgeteilt ist. Aus Sicht der Entwicklung wird die Codebasis dadurch schwieriger zu warten.

Zunächst habe ich den Weg der Konfiguration von Block- und Elementstilen aus theme.json . Allerdings habe ich mein Styling inzwischen wieder in CSS-Dateien verschoben. Es fühlt sich natürlicher an und ich habe den zusätzlichen Vorteil all der Werkzeuge, an die ich gewöhnt bin. Im Moment kann ich mir kein Szenario vorstellen, in dem ich zurückziehen würde.

Abgesehen davon, dass ich ein paar Bytes Code gespart habe, habe ich nicht viele Vorteile beim Hinzufügen von Stilen für die meisten Dinge über JSON gesehen. Vielleicht ändert sich das in Zukunft, und ich werde konvertieren. Im Moment bleibe ich hauptsächlich bei CSS.

Sonstiges Feedback: Eine PHP-Schicht

Ich habe es bereits gesagt, aber es muss wiederholt werden. Wir benötigen eine PHP-Schicht für dieses theme.json -Konfigurationssystem. Es gibt derzeit ein offenes Ticket, um dies zu beheben.

Ein solches System hat zwei Hauptvorteile. Eine PHP-API zum Zusammensetzen der Konfiguration wird sich für traditionelle Theme-Entwickler weitaus natürlicher anfühlen. Ich betrachte es als ein bisschen wie einen Olivenzweig, ein Zeichen des guten Glaubens, dass die Kern-/Gutenberg-Entwickler erkennen, dass es vielen Themenautoren leichter fallen wird, sich über eine vertraute Programmiersprache in FSE-Funktionen einzuarbeiten.

Der zweite Vorteil ist, dass es eine ungezählte Anzahl von Plugin-Ideen gibt, um globale Stile, Website-Bearbeitung und mehr zu erweitern, wenn es eine einfache Möglichkeit gibt, sich in das Theme-JSON-System einzuklinken und Dinge zu überschreiben. Ein einfacher Filterhaken würde dies schmerzlos machen.