Wie die Style Engine Klassen generiert

Im letzten Artikel dieser Reihe haben wir uns mit theme.json-Presets und Konfigurationen von Stil-Abschnitten beschäftigt. Dann haben wir besprochen, wie die WordPress Style Engine die JSON-Daten in CSS umwandelt und diese mit konsolidierten Daten aus verschiedenen Quellen – WordPress Core-Styles, Theme-Styles und Benutzer-Styles – zusammenführt, um ein globales Stylesheet zu erstellen. Wir haben auch gelernt, wie das generierte CSS auf einzelne Elemente wie Überschriften und spezifische Blöcke wie die Query Loop angewendet wird.

Die Style Engine ist dafür verantwortlich, Ihr CSS in einem einzigen globalen Stylesheet zu strukturieren und zu organisieren. Es ist wichtig zu verstehen, wie sie Ihre theme.json-Datei und Stile aus anderen Quellen verarbeitet. Andernfalls könnten Sie sich in einer Situation wiederfinden, in der Sie nicht verstehen, warum einer Ihrer Stile nicht funktioniert. Auf diese Weise haben Sie eine Vorstellung davon, wo Sie nachforschen und Fehler beheben können, ohne im Dunkeln zu tappen.

Ich diskutiere die WordPress Style Engine in einem anderen Artikel. Das ist ein großartiger Einstieg, wenn Sie mehr Kontext suchen, ohne all die kleinteiligen Details, die wir hier behandeln.

Inhaltsverzeichnis

• Woher Stile kommen
• Kombinieren von Quellen
• Verarbeitung von theme.json
• Generierte CSS-Klassen
• Zusätzliche Quellen für Benutzerstile
• Block-Stylesheets
• Das alles ist in aktiver Entwicklung!
• Zusätzliche Ressourcen
• Als Nächstes…

---

Woher Stile kommen

Die Style Engine muss ihre Informationen irgendwoher beziehen, oder? Die Wahrheit ist, dass es mehrere Orte gibt, an denen die Style Engine nach Informationen sucht, bevor sie CSS generiert.

• WordPress Core: Richtig, WordPress wird mit vordefinierten Stilen „out of the box“ geliefert. Denken Sie daran als Standardstile, die auf CMS-Ebene erstellt wurden, ähnlich wie die Standardstile in Browsern. Sie sind standardmäßig vorhanden, aber wir können sie in unserer theme.json-Datei überschreiben.
• Die theme.json-Datei: Wir haben diese Datei in der gesamten Serie ausführlich behandelt. Hier aktivieren wir bestimmte Styling-Funktionen und definieren Standardstile wie Farben, Schriftarten und Abstände. Sie können sie sich wie die style.css-Datei in einem „klassischen“ WordPress-Theme vorstellen: die Stile, die wir auf Theme-Ebene erstellen.
• Benutzerstile: WordPress verfügt über eine Reihe von Funktionen, mit denen Sie Stile direkt in WordPress festlegen können, ohne Code anfassen zu müssen. Das „wichtigste“ davon ist das Bedienfeld „Globale Stile“ im Site Editor. Es verwendet die Stile von WordPress Core und theme.json als Standardeinstellungen, aber das Ändern der Stileinstellungen überschreibt die beiden anderen Quellen.

Können Sie die Hierarchie erkennen, die sich daraus ergibt? WordPress Core-Stile können von theme.json überschrieben werden, und sowohl theme.json als auch WordPress Core-Stile können von Benutzerstilen überschrieben werden. Es ist auf gewisse Weise viel wie die CSS-Kaskade strukturiert!

Kombinieren von Quellen

Damit wir ein gutes Bild davon bekommen, womit wir arbeiten, hier ein Screenshot des WordPress Site Editors mit den Einstellungen für globale Stile.

Dies ist die Benutzeroberfläche, von der Benutzerstile stammen. Beachten Sie, wie sich oben im Bedienfeld eine Kachel befindet, die eine Vorschau der aktuellen Typografie und Farben des Themes anzeigt. Diese Kachel wird als Stilvariation bezeichnet, im Grunde vordefinierte Stilkonfigurationen, die in JSON im Theme-Ordner definiert sind. Ein Theme kann beliebig viele vordefinierte Stilvariationen haben, und die Auswahl einer solchen ändert sofort die Schriftarten und Farben des Themes mit der ausgewählten Kachel.

Sie sehen also bereits, wie Benutzerstile durch theme.json informiert werden. Beachten Sie jedoch die drei Kategorien von Stileinstellungen unter den Stilvariationen: Typografie, Farben und Layout. Wenn Sie auf eine dieser Einstellungen klicken, können Sie als Benutzer die Konfiguration der aktuell ausgewählten Stilvariation überschreiben.

Nun sehen Sie, wie theme.json und WordPress Core-Stile durch Benutzerstile überschrieben werden. Wir können uns auf WordPress Core-Stile für grundlegende Layouts und Stile verlassen, diese anpassen und unsere eigenen Stile in theme.json definieren, und dann dem Benutzer mehr Kontrolle über die Dinge mit Benutzerstilen aus den globalen Stileinstellungen des Site Editors überlassen.

Alle diese Styling-Daten werden als JSON gespeichert und verarbeitet. Die Style Engine generiert dieses JSON und konsolidiert es zu einem einzigen globalen Stylesheet für das Theme.

Verarbeitung von theme.json

Während der Konsolidierungsphase betrachtet die Style Engine die theme.json-Datei im Theme-Verzeichnis. Wir sprachen zuvor über die Struktur von theme.json und wie sie in zwei „oberste“ Abschnitte unterteilt ist: settings und styles.

{
  "version": 2,
  // Top-level settings
  "settings": {},
  "styles": {
    // Global element styles
    "elements": {},
    // Block styles
    "blocks": {}
  }
}

Die Style Engine verarbeitet diese Abschnitte wie folgt. Zuerst generieren die obersten settings CSS-Variablen, die auf das <body>-Element angewendet werden (z. B. --wp--preset--<category>-<slug>).

{
  "version": 2,
  "settings": {
    // Top-level settings
    "color": {
      "palette": [
        {
          "color": "#F8A100",
          "name": "Primary",
          "slug": "primary"
        }
      ]
    }
  },
  "styles": {
    // Global element styles
    "elements": {},
    // Block styles
    "blocks": {}
  }
}

In diesem Beispiel erhalten wir eine neue CSS-Variable, --wp-preset--color--primary. Die Style Engine wendet sie dann auf neue CSS-Klassen mit dem Präfix .has- an.

body {
  --wp--preset--color--primary: #F8A100;
}

.has-primary-color {
  color: var(--wp--preset--color--primary) !important;
}
.has-primary-background-color {
  background-color: var(--wp--preset--color--primary) !important;
}
.has-primary-border-color {
  border-color: var(--wp--preset--color--primary) !important;
}

Schön, oder? Diese Klassen können jetzt überall im Theme verwendet werden!

Als Nächstes generiert das styles.elements-Objekt Elementselektoren, die dem von ihnen repräsentierten HTML-Element entsprechen (z. B. styles.elements.h2 entspricht dem <h2>-Element).

{
  "version": 2,
  "settings": {},
  "styles": {
    // Global element styles
    "elements": {
       "h2": {
        "color": {
          "text": "#F8A100"
        }
      }
    },
    // Block styles
    "blocks": {}
  }
}

In diesem Beispiel wird ein h2-Selektor mit dem Farbwert #F8A100 generiert.

h2 {
  color: #F8A100;
}

Und, hey, wir hätten die CSS-Variable, die wir zuvor in settings definiert haben, als Farbwert verwenden können, da wir wissen, dass die Style Engine sie generieren wird.

{
  "version": 2,
  "settings": {},
  "styles": {
    // Global element styles
    "elements": {
       "h2": {
        "color": {
          "text": "var(--wp--preset--color--primary)"
        }
      }
    },
    // Block styles
    "blocks": {}
  }
}

…was uns das hier in CSS gibt.

h2 {
  color: var(--wp--preset--color--primary);
}

Und schließlich verwendet das settings.blocks-Objekt die Verkettung des Block- und Elementselektors. So ist die Spezifität dieser Selektoren höher, was ihnen eine größere Priorität gegenüber den anderen bisher generierten Stilen verleiht.

Lassen Sie uns zum Beispiel die Farbe des Site Title-Blocks ändern.

{
  "version": 2,
  "settings": {},
  "styles": {
    // Global element styles
    "elements": {},
    // Block styles
    "blocks": {
      "blocks": {
        "core/site-title": {
          "color": {
            "palette": [
              {
                "color": "#F8A100",
                "name": "SF Orange",
                "slug": "sf-orange"
              }
            ]
          }
        }
      }
    }
  }
}

Hier ist, wie sich das in CSS niederschlägt. Die Style Engine generiert eine Klasse für den Site Title-Block (.wp-block-site-title) und für die Farbe als Selektor für einen Nachfahrenselektor.

.wp-block-site-title .has-sf-orange-color {
  color: var(--wp--preset--color--sf-orange) !important;
}
.wp-block-site-title .has-sf-orange-background-color {
  background-color: var(--wp--preset--color--sf-orange) !important;
}
.wp-block-site-title .has-sf-orange-border-color {
  border-color: var(--wp--preset--color--sf-orange) !important;
}

Generierte CSS-Klassen

Wir haben nun eine ziemlich gute Vorstellung davon, wie die WordPress Style Engine die Daten, die sie aus verschiedenen Quellen erhält, in das CSS eines Block-Themes umwandelt.

Wir haben auch gesehen, wie die Einstellungen und Stile aus theme.json CSS-Variablen und Klassen erzeugen. Was Sie jetzt wahrscheinlich interessiert, sind die anderen CSS-Klassen, die wir von der Style Engine erhalten. Lassen Sie uns diese genauer betrachten.

Block-Klassen

Ein „Block“ in WordPress ist eine eigenständige Komponente, die in jede Seite oder jeden Beitrag eingefügt werden kann. Jeder Block erhält eine CSS-Klasse, die als Container-Elternteil des Blocks verwendet wird.

Und alle Klassennamen haben das Präfix wp-block. Zum Beispiel erhält der Cover-Block eine .wp-block-cover-Klasse, die wir verwenden können, um den gesamten Block auszuwählen und zu gestalten. WordPress nennt diese semantischen Klassen, weil sie den Block im Namen identifizieren.

Blöcke erhalten zusätzlich zu ihrer semantischen Klasse noch eine weitere Klasse, die als zustandsabhängige Klasse bezeichnet wird. Diese Klassen beschreiben den Zustand des Blocks, so als ob er eine bestimmte Textfarbe „hat“ oder eine bestimmte Hintergrundfarbe oder einen bestimmten Layouttyp „ist“.

Nehmen wir zum Beispiel an, wir fügen einen Post Title-Block zu einer unserer Theme-Vorlagen im Site Editor hinzu. Dann ändern wir ihn so, dass er eine Hintergrundfarbe hat, die „SF Orange“-Farbe, die wir in einem früheren Beispiel definiert haben.

Dies führt zu einer zustandsabhängigen Klasse am Element. Hier ist das HTML:

<h1 class="wp-block-post-title has-background has-sf-orange-background-color">
  <a href="#" target="_self">Hello world!</a>
</h1>

Sehen Sie die beiden zustandsabhängigen CSS-Klassen, die dies erzeugt hat?

• .has-background: Dies fügt dem Element einen Abstand hinzu, damit der Post Title nicht die Ränder des Containers berührt und mehr Hintergrund durchscheint.
• .has-sf-orange-background-color: Dies wendet die CSS-Variable für die Farbe an.

Hier ist eine Tabelle ausgewählter WordPress-Blöcke und Beispiele für die Art von Klassen, die generiert und auf sie angewendet werden.

Block	Semantische Klasse	Zustandsabhängige Klasse
Schaltflächen	.wp-block-buttons	.has-custom-width
Cover	.wp-block-cover	.is-light.has-parallax .has-position-vertical
Columns	.wp-block-columns	.has-2-columns .has-background
Heading	.wp-block-heading	.has-text-color
Gallery	.wp-block-gallery	.has-nested-images
Bild	.wp-block-image	.alignleft .aligncenter .alignright .has-custom-border
Spacer	.wp-block-spacer	.is-style-dots .has-text-color
Zitat	.wp-block-quote	.is-layout-constrained

Auch dies ist keine erschöpfende Tabelle von Blöcken. Eine vollständige Liste finden Sie jedoch im WordPress Block Editor Handbook. Ob es eine vollständige Liste zustandsabhängiger Klassen gibt, konnte ich nicht herausfinden. Daher sind die zustandsabhängigen Klassenbeispiele in der Tabelle zwar korrekt basierend auf meinen Tests, sollten aber auch nicht als vollständige Liste von Klassen betrachtet werden.

Layout-Klassen

WordPress bietet verschiedene Layout-Typen, die auf Container-basierte Blöcke angewendet werden können. Damit meinen wir die folgenden Blöcke:

• Columns
• Group
• Post Content
• Query Loop

Jeder dieser Blöcke kann einen Layout-Typ zugewiesen bekommen, und es gibt drei Optionen:

• Flow-Layout: Fügt vertikalen Abstand zwischen verschachtelten Blöcken in Richtung margin-block hinzu. Diese verschachtelten Blöcke können auch nach links, rechts oder zentriert ausgerichtet werden.
• Constrained-Layout: Genau das Gleiche wie ein Flow-Layout, aber mit Breitenbeschränkungen für verschachtelte Blöcke, die auf den Einstellungen contentWidth und wideWidth basieren (entweder in theme.json oder Global Styles).
• Flex-Layout: Dies wurde in WordPress 6.1 nicht geändert. Es verwendet CSS Flexbox, um ein Layout zu erstellen, das standardmäßig horizontal (in einer Reihe) fließt, aber auch vertikal fließen kann, sodass Blöcke übereinander gestapelt werden. Abstände werden mit der CSS-Eigenschaft gap angewendet.

Abhängig von den gewählten Einstellungen entspricht dies den folgenden CSS-Klassen:

• .is-layout-flow
• .is-layout-constrained
• .is-layout-flex

Sehen Sie, wie die zustandsabhängige Namenskonvention hier fortgesetzt wird? Dies sind jedoch nicht die einzigen Layout-bezogenen Klassen. Hier sind alle verfügbaren Klassen, wie im WordPress Block Editor Handbook dokumentiert.

Justin Tadlock hat einen hervorragenden Artikel, der diese Layout-Typen und semantischen Klassen mit Anwendungsfällen und Beispielen erklärt. Sie können auch auf meinen Artikel „Using The New Constrained Layout In WordPress Block Themes“ verweisen, um noch mehr Informationen zur Verwendung verschiedener Layouts zu erhalten.

Zusätzliche Quellen für Benutzerstile

Wir wissen bereits, dass wir die Einstellungen für globale Stile im Site Editor verwenden können, um die CSS-Stile zu überschreiben, die von WordPress Core und theme.json stammen. Diese nannten wir Benutzerstile.

Aber das ist nicht der einzige Ort, an dem Benutzerstile herkommen können. Angenommen, Sie schreiben zum Beispiel einen neuen Beitrag und möchten einen bestimmten Absatz auf eine bestimmte Weise gestalten. Und nehmen wir an, Sie haben eine CSS-Klasse, die Sie entweder in theme.json oder vielleicht sogar in Ihrem eigenen Stylesheet definiert haben! Solange das CSS für diese Klassen auf der Seite geladen wird, können Sie sie im erweiterten Einstellungen jedes Blocks hinzufügen.

Diese Anleitung zum Hinzufügen zusätzlicher CSS-Klassen zu Blöcken führt Sie durch die Verwendung benutzerdefinierter CSS-Klassen auf Ihrer Website.

Es gibt noch einen weiteren Ort, an dem Benutzerstile platziert werden können. Ab Gutenberg 14.8 wurde eine neue benutzerdefinierte „Zusätzliche CSS“-Box zu den Einstellungen für globale Stile hinzugefügt.

Und, hey, eine wichtige Benachrichtigung: Das CSS aus diesen Benutzerstilquellen kann die CSS-Einstellungen in theme.json überschreiben oder sogar entfernen. Eine weitere wichtige Sache, die Sie wissen sollten, ist, dass alle Stile, die Sie hier definieren, verloren gehen könnten, wenn Sie das Theme wechseln. Es ist wahrscheinlich besser, diese Stile tatsächlich in theme.json zu erstellen oder Ihr eigenes Stylesheet einzubinden.

Block-Stylesheets

Es gibt noch einen weiteren Ort, von dem die WordPress Style Engine Styling-Daten beziehen kann, und das sind Ihre eigenen Stylesheets! Das stimmt: Sie können Ihrem Theme eigene Stylesheets hinzufügen.

Sicher, Sie könnten auch die erforderliche style.css-Datei als Ihr Stylesheet verwenden. Die meisten Block-Themes werden sie sowieso nicht verwenden. Aber es gibt einen noch effizienteren Weg: Stylesheets für bestimmte Blöcke enqueuen.

Zunächst einmal sind Sie mit dem Konzept des „Enqueuens“ von Dateien aus der Arbeit mit klassischen WordPress-Themes und der Funktion wp_enqueue_style() vielleicht schon vertraut. Das lädt eine CSS-Datei, indem es einen Pfad angibt, wo WordPress sie finden kann.

Das Gleiche können wir tun, aber auf Block-Basis. Jeder WordPress-Block hat sein eigenes zugehöriges Stylesheet, und wir können eigene Stylesheets für sie enqueuen. Hier füge ich zum Beispiel ein Stylesheet mit benutzerdefinierten Stilen für den Quote-Block in die functions.php-Datei meines Themes ein:

add_action( 'init', 'emptytheme_enqueue_block_styles' );

function emptytheme_enqueue_block_styles() {
  wp_enqueue_block_style( 'core/quote', array(
    'handle' => 'emptytheme-block-quote',
    'src'    => get_theme_file_uri( "assets/blocks/quote.css" ),
    'path'   => get_theme_file_path( "assets/blocks/quote.css" )
  ) );
}

Schauen Sie sich das an – es ist praktisch die gleiche Art und Weise, wie wir benutzerdefinierte Stylesheets in einem klassischen WordPress-Theme laden würden, PHP und alles.

Wenn Sie Stile zu mehreren Blöcken hinzufügen möchten, müssen Sie CSS-Dateien über ein Array enqueuen und dann durch diese iterieren. Das WordPress Developer Blog hat ein schönes Beispiel von Justin Tadlock geschrieben.

add_action( 'init', 'themeslug_enqueue_block_styles' );

function themeslug_enqueue_block_styles() {
  // Add the block name (with namespace) for each style.
  $blocks = array(
    'core/button'
    'core/heading',
    'core/paragraph'
  );

  // Loop through each block and enqueue its styles.
  foreach ( $blocks as $block ) {

    // Replace slash with hyphen for filename.
    $slug = str_replace( '/', '-', $block );

    wp_enqueue_block_style( $block, array(
      'handle' => "themeslug-block-{$slug}",
      'src'    => get_theme_file_uri( "assets/blocks/{$slug}.css" ),
      'path'   => get_theme_file_path( "assets/blocks/{$slug}.css" )
    ) );
  }
}

Das alles ist in aktiver Entwicklung!

Bitte beachten Sie, dass die WordPress Style Engine noch ziemlich neu ist und die Arbeit daran noch läuft. Das Style Engine-Dokument listet einige der geplanten zukünftigen Arbeiten auf:

• Konsolidierung von globalen und Block-Stilrendering und Enqueuing (laufend)
• Untersuchung der Vor-Rendering-Verarbeitung von CSS-Regeln mit dem Ziel, andere gängige und/oder wiederholende Blockstile zu duplizieren (laufend).
• Erweiterung des Umfangs semantischer Klassennamen und/oder Design-Token-Ausdrücke und Kapselung von Regeln in stabile Utility-Klassen.
• Vorschlag eines Weges zur Steuerung von Hierarchie und Spezifität und zur Bereitstellung einer zugänglichen und vorhersagbaren Kaskade von Stilhierarchien. Dies kann die Vorbereitung auf CSS-Kaskadenebenen beinhalten, bis diese breiter unterstützt werden, und die Ermöglichung der Opt-in-Unterstützung in Gutenberg über theme.json.
• Refaktorisieren aller Blöcke zur konsistenten Verwendung des „style“-Attributs für alle Anpassungen, d. h. Verwerfen von Preset-spezifischen Attributen wie attributes.fontSize.

Sie können den Entwicklungsstatus auf dem GitHub-Projektboard verfolgen.

Selbst mit diesen Einschränkungen zeigen dieser Tweet von Rich Tabor und das folgende Video die unbegrenzten Möglichkeiten, das Erscheinungsbild eines Block-Themes anzupassen – ganz ohne Code!

⚠️ Enthält automatisch abspielende Medien

Alles möglich gemacht, dank der WordPress Style Engine und ihrer JSON-Parsing-Superkräfte.

Zusätzliche Ressourcen

Wir haben in diesem Artikel viel Boden gutgemacht! Ich dachte, ich teile einige der Ressourcen, auf die ich mich für die Informationen verlassen habe.

Dokumentation

• Block Style Generation (Style Engine) (WordPress 6.1 Field Guide)
• Core Styles und Theme Customization: die nächsten Schritte (Make WordPress Core)

Tutorials

• Standardisierte Design-Tokens und CSS für eine konsistente, anpassbare und interoperable WordPress-Zukunft (MR Web Design)
• Eine Übersicht über Layout-bezogene Klassen (Gutenberg Times)

GitHub-Probleme

Ein Großteil des Kontexts für diesen Artikel stammt aus Vorschlägen und gemeldeten Problemen im WordPress GitHub-Repo.

• Der Block – Theme Vertrag (#35470)
• Allgemeine CSS-Konzepte: Deklarieren von Stilen vs. Beschreiben von Zuständen (#38694)
• Optionen zur Wiedereinführung semantischer Klassennamen für Block-Wrapper (#38719)
• Vorschlag: Standardisierte Block-Markup, theme.json-Design-Tokens und CSS-Klassen zur Verbesserung der Interoperabilität (#38998)
• Layout: Semantische Klassennamen verwenden, Layout-Definitionen zentralisieren, Duplizierung reduzieren und blockGap in theme.json beheben (#40875)
• Roadmap für globale Stile (laufend) (#41232)
• Heading-Block – Hinzufügen einer CSS-Klasse wp-block-heading (#42122)

Als Nächstes…

Wir sind tatsächlich fertig! Aber ich habe eine Seite erstellt, die alles zusammenfasst, was wir über CSS in WordPress Block Themes gelernt haben, und Ihnen eine zentrale Anlaufstelle bietet, auf die Sie jederzeit verweisen können, wenn Sie sie benötigen.