Das HTML lang Attribut und wie man es überschreibt

Da ich mein aktuelles Projekt mit dem neuen Thema erst einmal gestoppt habe, kann ich auch wieder über andere Themen zu schreiben. Diese Woche möchte ich über ein wichtiges globales HTML-Attribut schreiben: das lang-Attribut.

Vielleicht haben einige von euch dieses Attribut noch nie (aktiv) verwendet, aber es ist ziemlich wichtig. Es teilt nicht nur Suchmaschinen mit, in welcher Sprache der Inhalt eurer Website verfasst ist, sondern auch einer „Assistive Technology“ wie einem Screenreader, welche Stimme es beim Lesen des Textes verwenden soll. Es kann sogar „inline“ für ein einzelnes Wort oder Teile eines Textes gesetzt werden.

Das wichtigste lang Attribut wird aber im <html> Tag gesetzt. In WordPress wird das durch die Funktion language_attributes() erledigt, die man normalerweise in der Datei header.php eines klassischen Themes finden. In einem Block-Theme wird dies automatisch im Core erledigt.

Gründe für das Überschreiben des lang-Attributs

Normalerweise möchten man den Wert des lang Attributs nicht ändern, da WordPress immer den richtigen Wert verwendet, je nach Spracheinstellung eurer Website. Es gibt aber auch Fälle, in denen man es ändern möchte.

Mehrsprachige Websites

WordPress kann nur eine Frontend-Sprache haben, es sei denn, man installieren ein Plugin für Mehrsprachigkeit. Ich verwende MultilingualPress, welches auf Multisite basiert. In einer WordPress-Multisite kann man die Sprache für jede Unterseite festlegen. Dadurch wird automatisch das richtige lang Attribut in jeder Site verwendet.

Wenn deine Website kein Mehrsprachigkeit-Plugin verwendet, du aber eine Seite mit einer anderen Sprache hast, kannst du das lang Attribut mit etwas Code überschreiben.

Laden von externem Code

Ein weiterer Anwendungsfall ist die Verwendung von Plugins, die das lang Attribut zum Laden externer Daten verwenden. Ich bin diese Woche auf ein Cookie-Banner-Plugin gestoßen, das den Text für das Banner von einer externen Ressource lädt. Es hat den genauen Wert des lang Attributs verwendet. Dabei hat aber es einen Wert wie en erwartet, also einen Wert mit nur zwei Zeichen. WordPress verwendet jedoch einen Wert wie en-US, was für dieses Cookie-Banner nicht funktionieren würde. Wir müssen also den zweiten Teil des Wertes entfernen.

CSS verwendet das Attribut

Ein gutes Beispiel für einen Anwendungsfall in CSS ist die quotes Eigenschaft. In verschiedenen Sprachen werden unterschiedliche Anführungszeichen verwendet. Wenn man die richtigen Anführungszeichen in einem <q> HTML Tag verwenden möchte, muss man normalerweise nichts tun. Der Browser übernimmt dies für einen, weil der Wert auf quotes: auto gesetzt ist. Wenn man das überschreiben will, kann man Folgendes tun:

q {
	quotes: "«" "»" "‹" "›";
}

Dies würde immer die Anführungszeichen verwenden, die im Französischen und anderen Sprachen verwendet werden, auch wenn das lang Attribut auf en gesetzt ist.

Einige CSS-Bibliotheken verwenden das lang Attribut wie folgt, um Stile zu ändern:

[lang="en"] q {
	/* Some styles */
}

Dies würde nicht funktionieren, wenn der Wert für das lang Attribut auf en-US gesetzt ist. Es gibt allerdings die CSS-Pseudoklasse :lang(), mit der es funktionieren würde:

:lang(en) {
	/* Some styles */
}

Wenn man hier en verwenden, würde es auch für die Werte en-US, en-GB, usw. funktionieren. Aber wenn man es auf en-US setzt, würde es umgekehrt nicht auch nur für den Wert en funktionieren.

Da das CSS in einem solchen Framework statisch sein könnte, wäre das Überschreiben vielleicht etwas zu kompliziert. In diesen Fällen möchte man einfacher den Wert des globalen lang Attributs des <html> Tags ändern.

Wie ändert man den Wert?

Angenommen, wir wollen den Wert für eine bestimmte Seite auf einen anderen statischen Wert ändern, dann könnte man es wie folgt umsetzen:

function my_static_lang_attribute( $output ) {
	$object = get_queried_object();
	if ( $object && str_contains( $object->post_name, 'english' ) ) {
		return 'lang="en-US"';
	}

	return $output;
}

add_filter( 'language_attributes', 'my_static_lang_attribute' );

Dies würde das lang Attribut des <html> Tags für jede Seite und jeden Beitrag mit „english“ im Permalink mit lang="en-US" überschreiben.

Wie man aus der Funktion herauslesen kann, würde der Filter nicht nur den Wert, sondern auch den Namen des Attributs zurückgeben. Wenn man sich den vollständigen Code der Funktion get_language_attributes ansieht, wird klar, dass die Funktion auch andere Attribute wie dir zurückgeben kann:

function get_language_attributes( $doctype = 'html' ) {
	$attributes = array();

	if ( function_exists( 'is_rtl' ) && is_rtl() ) {
		$attributes[] = 'dir="rtl"';
	}

	$lang = get_bloginfo( 'language' );
	if ( $lang ) {
		if ( 'text/html' === get_option( 'html_type' ) || 'html' === $doctype ) {
			$attributes[] = 'lang="' . esc_attr( $lang ) . '"';
		}

		if ( 'text/html' !== get_option( 'html_type' ) || 'xhtml' === $doctype ) {
			$attributes[] = 'xml:lang="' . esc_attr( $lang ) . '"';
		}
	}

	$output = implode( ' ', $attributes );

	/**
	 * Filters the language attributes for display in the 'html' tag.
	 *
	 * @since 2.5.0
	 * @since 4.3.0 Added the `$doctype` parameter.
	 *
	 * @param string $output A space-separated list of language attributes.
	 * @param string $doctype The type of HTML document (xhtml|html).
	 */
	return apply_filters( 'language_attributes', $output, $doctype );
}

Plugins könnten sich ebenfalls in diesen Filter einhängen, womit das Überschreiben von $output mit etwas Statischem möglicherweise nicht funktioniert. Unglücklicherweise gibt es auch keinen Filter, der nur den $lang Wert ändert, und ein Hook in get_bloginfo(), um die Sprache zu überschreiben, könnte an einigen anderen Stellen zu Problemen führen, an denen dieser Code verwendet wird. Wenn man den zweiten Teil des Wertes entfernen will, könnten man aber einen regulären Ausdruck wie diesen verwenden:

function my_dynamic_lang_attribute( $output ) {
	return preg_replace( '/lang="(\w+)([^"]+)"/', 'lang="$1"', $output );
}
add_filter( 'language_attributes', 'my_dynamic_lang_attribute' );

Wenn man etwas noch Komplexeres benötigen, ist es wahrscheinlich am besten, einfach die gesamte Funktion zu überschreiben.

Fazit

Das lang Attribut ist ein sehr wichtiges Attribut, das jede Website immer setzen sollte. Aber der Wert ist vielleicht nicht immer so, wie man ihn brauchen. Für diese Fälle gibt es einen Filter, mit dem der Wert überschrieben werden kann. Dabei sollte man aber immer darauf achten, dass man keinen ungültigen Wert zurückgibt.

Zu viel zusätzliches CSS: Ich muss aufhören!

Mein letzter Blogbeitrag war im Juli. Ich habe es nicht geschafft, meinen üblichen Rhythmus von einem neuen Blogbeitrag alle zwei Wochen einzuhalten. Dafür gab es viele verschiedene Gründe, einige davon waren persönliche und einige betrafen Menschen, die mir wichtig sind. Aber ein anderer Grund war der sehr langsame Fortschritt an meinem neuen Theme. Und heute muss ich sagen: Stopp!

Ich habe die Demo-Inhalte verwendet, die ich normalerweise verwende, wenn ich ein Theme programmiere. Dabei habe ich versucht, jedes kleine Element „so pixelgenau wie möglich“ zu replizieren. Aber da ich jetzt bei ~900 Zeilen zusätzlichem CSS-Codes angelangt bin und dies die Nutzenden daran hindern würde, Stile im Website-Editor zu überschreiben, funktioniert dieser Ansatz einfach nicht.

Wie soll es mit dem Projekt weitergehen?

Mein Hauptziel bestand darin, ein Theme zu erstellen, das von möglichst vielen Nutzenden des ursprünglichen Waipoua-Themes verwendet werden kann, mit möglichst wenigen „Migrationsschritten“. Aber ich muss feststellen, dass dies einfach nicht machbar ist. Ich wusste immer, dass ich auch ein „Begleit-Plugin“ anbieten müsste, das alle Shortcodes beinhaltet, die Waipoua angeboten hat. Aber ist es das wirklich wert? Wie viele gibt es noch, die Waipoua verwenden und die mutig genug wären zu migrieren?

Option 1: Zwei verschiedene Varianten meines Themes anbieten

Mein erster Gedanke war es schon vor einiger Zeit, zwei Varianten meines Themas anzubieten. Die erste würde es versuchen, nahezu „pixelperfekt“ zu sein, ohne die Stile von Elementen auf bestehenden Websites zu ändern. Die zweite würde den Site-Editor in vollem Umfang nutzen, indem nur Stile über den Site-Editor mithilfe der theme.json hinzugefügt würden.

Bei diesem Ansatz würde die erste Variante diese ~900 Zeilen CSS-Datei laden, die zweite würde nur eine kleinere Datei laden, die für die Gestaltung der Kopfzeile mit der Suche erforderlich wäre. Oder sie würde gar nicht erst versuchen, die Suche genau so zu replizieren, wie sie ist. Stattdessen würde sie einfach eine andere Suche im Header anbieten.

Option 2: Dies als Möglichkeit zum Lernen sehen und weiterziehen

Dieses Projekt hat wirklich Spaß gemacht! Aber es war manchmal auch echt sehr frustrierend. Eines habe ich aber daraus gelernt: Ein gutes Theme zu schreiben ist nicht einfach! Mein Respekt für die Arbeit von Ellen und Manuel ist mit jeder Stunde gewachsen, in der ich versucht habe, ihre Arbeit zu replizieren.

Und weiter geht’s?

Ich habe immer noch vor, ein neues Thema zu erstellen, das Waipoua ähnlich genug ist, damit die Menschen meine Seite wiedererkennen und vielleicht nicht einmal merken, dass es ein anderes Thema ist. Wenn man die neue und die alte Version nicht direkt nebeneinander vergleicht und nur die Farben, die Schriftarten und die Struktur betrachtet, wird man wahrscheinlich denken, dass es nur ein paar kleine Anpassung am aktuellen Theme gab.

Mir gefällt der Gedanke einfach nicht, in meinem allerersten Theme so viel zusätzliches CSS hinzuzufügen zu müssen, welches dann nicht im Site-Editor überschrieben werden kann. Und ich möchte auch nicht erzwingen, dass ein zusätzliches Plugin verwendet werden muss, damit es mit den aktuellen Inhalten funktioniert. Ich selbst gehöre ja auch zu denen, die einige Shortcodes in alten Blogbeiträgen verwendet haben, als es noch keinen Block-Editor gab, mit dem man „Buttons“ oder Spalten im Text erstellen konnte.

Helft mir mit eurem Feedback!

Ich bitte in meinen Blogbeiträgen häufiger um Kommentare, aber meistens bekomme ich keine. Dieses Mal würde ich mich wirklich über Ihr Feedback freuen. Vor allem von allen, die Waipoua auf einer Seite verwenden. Was soll ich eurer Meinung nach tun? Ein Theme mit zwei Varianten erstellen (Option 1)? Oder einfach versuchen, ein echtes Block-Theme zu erstellen, das nicht versucht, „Legacy-Inhalte zu unterstützen“ (Option 2)?

Ziel verfehlt: Ich musste CSS zum Theme hinzufügen

Als ich dieses Projekt angefangen habe, war es mein Ziel, das Theme so weit wie möglich nachzubauen und dabei nur den Website-Editor zu verwenden. Mein Endgegner war der Header. Nur mit den Optionen des Website-Editors und der Core-Blöcke war es mir einfach nicht möglich, das generelle Aussehen zu erreichen. Besonders der Suche-Block war einfach zu eingeschränkt in den verfügbaren Optionen.

Hinzufügen einer CSS-Datei

Schon alleine die Hintergrundfarbe (transparent) zu setzen und das Suche-Icon zu gestalten war nicht möglich. Als ich dann noch versucht habe Styles und Effekte für das Suchfeld zu setzen und den Platzhalter-Text zu stylen, kam ich an einem Punkt, an dem es unmöglich wurde, nur die theme.json Datei zu verenden und ich musste mein Ziel aufgeben und nun doch eine CSS-Datei zum Theme hinzufügen.

Ein paar Änderungen später wurde mir dann bewusst, dass ich sehr viele lange und sich wiederholende CSS-Selektoren schreiben musste und habe mich dann dazu entschieden, auch noch SASS zu verwenden.

Nach dieser Niederlage wurde es dann aber sehr viel einfacher. Da ich mich gut damit auskenne CSS zu schreiben, war das Styling des Headers viel einfacher. In den letzten vier Wochen habe ich am Header und dem Rest des Themes gearbeitet und der aktuelle Stand des Themes kommt schon sehr nahe an das originale Theme heran.

Der Header

Wie zuvor erwähnt war der Header der Grund dafür eine CSS-Datei einzufügen. Aber einige Styles waren sogar nur unter Verwendung des Website-Editors möglich. In einem ersten Versuch konnte ich sogar den Home-Link umsetzen, indem ich die "css" Eigenschaft in den "core/home-link" Block-Styles verwendet habe. Um aber alle Styles des originalen Themes nachzubauen, brauchte ich ~100 Zeilen CSS. Aber das Ergebnis sieht sehr gut aus:

Der originale Header

Screenshot des originalen Waipoua Theme Header, mit Navigation und Suche rechts, sowie dem Seite-Titel und Untertitel und der Social-Media-Icons in der zweiten Zeile.

Der neue Header

Der neue Header, der die gleichen Elements zeigt mit kleineren Unterschieden in den Abständen.

Könnt ihr die Unterschiede erkennen? Vermutlich würdet ihr ein Tool brauchen, um diese zu visualisieren. Einige Elemente sind um ein paar Pixel verschoben, aber insgesamt sieht es sehr ähnlichen aus. Für das Home-Icon habe ich eine SVG erstellt, bei der die originale (sehr kleine) PNG als Vorlage diente.

Einen Unterschied, den ihr vielleicht entdeckt habt, ist die Verwendung der „nach unten Caret“ nach den Navigationspunkten mit einer Subnavigation. Hierzu gibt es unter „Darstellung > Untermenüs“ im „Navigation“ Block eine Option, um diese zu deaktivieren, aber da ich mein Theme von Anfang an barrierefreier machen möchte, habe ich diese Option aktiviert gelassen.

Erstellung zusätzlicher Templates

Nachdem ich das initiale Design fertig hatte, habe ich mit einigen Templates weitergemacht. Die ersten beiden waren „Einzelne Beiträge“ und „Seiten“.

Das „Einzelne Beiträge“ Template

Ich dachte, dass das schnell gehen sollte. Nur das Datum und die Anzahl der Kommentare (mit einem Anker-Link zum Kommentar-Formular) im „Eintrags-Header“ einfügen, sowie die Kategorien, Schlagwörter und Kommentare zum „Eintrags-Footer“ hinzufügen. Ich lag so falsch. 🙈

Bei der Entwicklung eines Themes verwende ich in der Regel die „Theme Unit Test“ XML-Import-Datei. Diese erstellt viele Inhalte und Menüs, um euer Design zu testen. Um die verschiedenen HTML Tags und deren Styles im neuen Theme zu testen, habe ich den Beitrag „Template: Comments“ verwendet. Das war dann der Punkt, an dem viel CSS im Theme gelandet ist. Elmastudio hat sich sehr viel Mühe gegeben, die verschiedenen Elemente, die man im Inhalt haben kann, schön zu gestalten, wie etwa Listen, Zitate, Tabelle, usw. Und sie haben diese auch (anders) für Kommentare gestaltet, um der geringen verfügbaren Breite im Kommentar-Inhalt Rechnung zu tragen. Da man aber nur recht wenige dieser nativen Elemente in der theme.json Datei gestalten kann, musste ich mehr CSS schreiben. Am Ende sind ~160 Zeilen für diese Elemente im Inhalt und nochmal ~100 Zeilen für Anpassungen im Kommentar-Inhalt zusammengekommen. Ich realisiere jetzt, wie viel Arbeit es macht und viel Gedanken man sich machen muss, um ein Theme mit tollen Styles zu erstellen und ich habe nun noch mehr Respekt davor, was Ellen und Manuel in all ihren Themes gemacht haben.

Einführung einer neuen Template-Vorlage: comments

Da das die Kommentare-Liste und das Kommentare-Formular sowohl in Beiträgen, als auch in Seiten verwendet wird, habe ich daraus eine neue Vorlage gemacht. Dieser „template part“ enthält die Blöcke „Kommentar-Template“, „Seitennummerierung der Kommentare“ und „Formular für Kommentare“.

Für das Kommentare-Formular musste ich nochmal ~75 Zeilen CSS schreiben (selbst mit SASS) und mir wurde einmal mehr bewusst, wie frustrierend es ist, Styles für Formulare zu schreiben:

Click here to display content from Twitter.
Erfahre mehr in der Datenschutzerklärung von X.

Aber hey, am Ende waren es dann doch „nur“ ~75 Zeilen und ich konnte dabei auch noch ein wenig CSS Grid üben.

Beitrags-Navigations-Link

Zwei andere Blöcke, bei denen ich mit der aktuellen Implementierung nicht ganz glücklich bin, sind „Vorheriger Beitrag“ und „Nächster Beitrag“. Sie bieten zwar einen Stil-Variante „Pfeil“ an, aber hier werden die Pfeile vor/nach dem Link eingefügt und können nicht angeklickt werden. Da ich aber ein „Button-Design“ haben wollte, musste ich den „Pseudo-Content-Trick“ verwenden, um den klickbaren Bereich auf den gesamten „Button“ zu vergrößern. Auch das Hinzufügen einer Hintergrundfarbe für den Button war nicht so einfach, da das Wrapper DIV auch dann sichtbar war, wenn sich darin kein Link befand. Insgesamt brauchen diese Blöcke also noch ein paar Verbesserungen in zukünftigen Versionen des Block-Editors.

Das „Seiten“ Template

Nachdem ich das Template für Beiträge fertig hatte, war die Erstellung des Templates für Seiten ziemlich einfach. Ich musste lediglich das Datum und den Kommentar-Link aus dem „Eintrag-Header“ entfernen, sowie die Kategorien und Schlagwörter aus dem „Einträge-Footer“. Der Rest des Templates blieb gleich. Und da wir ja ein „comments“ Template-Vorlage erstellt haben, wird dieser Teil auch viel einfacher, wenn wir mal etwas an der Gestaltung dieses Bereichs ändern wollen.

Der Footer

Nach der Fertigstellung des „Eintrag-Inhalts“ für Beiträge und Seiten, habe ich auch Footer fertiggestellt. Da es fast ausschließlich statischer Inhalt ist, war das schnell getan. Nur beim Speichern der Änderungen ins Theme über das Create Block Theme Plugin gab es einige Probleme.

Statischer Text wird in Übersetzungsfunktionen eingebettet, was toll ist! Leider wurden diese Übersetzungen nicht escaped. Und auch die Jahreszahl war dann fest kodiert. Selbst wenn man das manuell ändern, die Übersetzungen escaped, und die Jahreszahl dynamisch macht, wird er bei jeder Änderung am Footer wieder überschrieben.

Dynamischer Footer mit sicherer Ausgabe

Hier ist ein Teil des Footers, wie er in meiner verbesserten und dynamischen Version aussieht:

<p>&copy; <?php echo date( 'Y' ); ?>&nbsp;</p>

<!-- ... -->

<p><?php echo wp_kses_post( __( 'Proudly powered by <a href="https://wordpress.org/">WordPress</a>', 'kauri' ) ); ?></p>

<!-- ... -->

<p class="has-text-align-center">
	<?php echo wp_kses_post( __( 'Theme: Kauri by <a href="https://kau-boys.com">Bernhard Kau</a>, based on Waipoua by <a href="https://www.elmastudio.de/en/">Elmastudio</a>', 'kauri' ) ); ?>
</p>

<!-- ... -->

<p class="has-grey-color has-text-color has-link-color">
	<a href="#top"><?php echo esc_html__( 'Top', 'kauri' ); ?> ↑</a>
</p>

Das ist der Code, den das Create Block Theme Plugin erstellt bzw. bei Änderungen überschreibt.

<p><?php echo __('© 2024&nbsp;', 'kauri');?></p>

<!-- ... -->

<p><?php echo __('Proudly powered by <a href="https://wordpress.org/">WordPress</a>', 'kauri');?></p>

<!-- ... -->

<p class="has-text-align-center">
			Theme: Kauri by <a href="https://kau-boys.com">Bernhard Kau</a>, based on Waipoua by <a href="https://www.elmastudio.de/en/">Elmastudio</a>		</p>

<!-- ... -->

<p class="has-grey-color has-text-color has-link-color">
	<a href="#top">Top ↑</a>
</p>

Wie ihr sehen könnt, fehlt das Escaping komplett. Weiterhin sind die letzten beiden Absätze nicht mehr übersetzbar. Ich hatte leider nicht die Zeit, mir mal den Code genauer anzusehen, der diese Zeilen erzeugt und zu prüfen, ob es dafür eine Lösung gibt. In der Zwischenzeit muss ich also jedes Mal diese Änderungen rückgängig machen, wenn ich etwas am Footer-Template anpasse.

Fazit

Ein Theme zu erstellen ist verdammt viel Arbeit! Auch wenn man „nur“ ein klassisches Theme als Block-Theme nachprogrammiert, braucht das sehr viel Zeit, denn man muss auf so viele Dinge achten. Und ich habe das Theme noch nicht einmal ausgiebig mobil getestet – der erste Eindruck ist aber gut.

Es gibt noch immer viel zu tun, aber ich hoffe, dass ich den Wechsel in zwei Wochen einhalten kann. Selbst wenn das Theme dann noch nicht perfekt ist.

Falls ihr die anderen Änderungen sehen wollt, auf die ich in diesem Update nicht eingehen konnte, oder wenn ihr weiterhin die Implementierung nachverfolgen wollt, dann seht euch einfach die Commits im GitHub-Repository an. Ich bin sehr zufrieden mit dem aktuellen Stand der Implementierung und kann es nicht erwarten, das Theme endlich fertigzustellen. 🙌

Ein fünfzehnjähriger Teenie, der nicht weiß, was er anziehen soll

Und schon wieder ist ein Jahr vorbei und ich blogge schon seit 15 Jahren auf dieser Seite. Immerhin sind in der Zeit 401 Beiträge zusammen gekommen. Aber auch heute ist noch nicht Schluss.

Schließung weiterer Plugins

Vor einem Jahr hatte ich verkündet, dass ich mein erstes Plugin habe schließen lassen. Seitdem habe ich noch ein vier weitere aus dem Plugin Directory entfernen lassen, weil entweder deren Funktionalität mittlerweile im Core enthalten ist, oder weil die Technologie dahinter nicht mehr genutzt wird. Ein weiteres werde ich schließen lassen, wenn Preferred Languages endlich im Core landet.

Die Zahlen für das vergangene Jahr

Es gab auch im letzten Jahr keinen neuen Besucherrekord. Ich muss wohl mal etwas zum Thema AI schreiben, damit es hier so richtig rund geht. 😀

Leider haben auf der deutschen Seite auch noch knapp 18% weniger Besuche stattgefunden, auf der englischen waren es nur 2% weniger. Woran das lag, kann ich natürlich nicht genau wissen, aber ich hoffe mal, dass alle, die aktiv lesen, auch die richtigen Inhalte finden. Falls nicht, dann wünscht euch gerne mal ein Thema. 🙂

Die Anzahl der Besuche auf der englischen Seite ist auch weiterhin stärker als auf der deutschen und konnte von 53,4% auf 57,8% zulegen. Vielleicht ist es also an der Zeit, auch diesen Beitrag ins Englische zu übersetzen, was ich bei den „Geburtstags-Beiträgen“ bisher nur einmal gemacht habe.

Top3 im letzten Jahr

  1. Formatierten Quellcode mit Syntaxhervorhebung in Word einfügen
  2. Fehler beim Senden in Contact Form 7 debuggen
  3. Direkte Downloads mit dem „download“ Attribute

Der alte Platz 1 war wohl nur ein zeitlich begrenzter Erfolgsbeitrag, der ganz weit abgestürzt ist. Dafür haben wir einen alten bekannten wieder in der Spitze. Auf Platz 2 war schon häufiger in den Top3 vertreten. Keine Änderung gab es auf Platz 3. Es ist immer wieder spannend zu sehen, welche Beiträge am meisten gelesen werden. Die aktuellen Top3 sind aus den Jahren 2009, 2016 und 2017. Der meistgelesene ist also nur knapp ein halbes Jahr jünger als dieser Blog.

Noch immer kein neues Theme

Vor einem Jahr hatte ich hier verkündet, dass ich an einem neuen Theme arbeiten möchte. Und wie ihr in den vergangenen Beiträgen verfolgen konntet, mache ich sehr gute Fortschritte. Ich hatte eigentlich vor, heute zum Blog-Geburtstag das neue Theme zu verwenden, aber es ist noch nicht so weit, wie ich es gerne hätte.

Ich schreibe diesen Beitrag aus einem Hotel auf dem Rückweg vom WordCamp Europe 2024. Auch deshalb konnte ich nicht ganz so viel daran arbeiten. Gestern noch hatte ich im Zug den Footer endlich fertig und eigentlich waren damit alle Teile grundsätzlich neu erstellt, aber beim Exportieren in die Theme-Dateien war der Footer dann auf einmal kaputt. Das konnte ich heute reparieren, aber es gibt noch sehr viele kleine Details, die zu gestalten habe. Aktuell arbeite ich am Kommentare-Bereich unter den Beiträgen. Aber auch grundlegende Styles, wie etwa für Listen, Tabellen und ähnliches im Inhalt wollen angepasst werden. Mehr dazu dann aber in den zukünftigen Beiträgen.

Und dann habe ich auch festgestellt, dass nicht mein Blog-Geburtstag der perfekte Tag für das neue Theme ist, denn auch vor 12 Jahren habe ich zum Blog-Geburtstag noch nach einem neuen Theme gesucht und dieses dann genau einen Monat später aktiviert. Markiert euch also mal den 21. Juli im Kalender.

Fazit

Es ist also noch immer viel los und ich nutze viele freie Minuten in meiner Freizeit, um weiter am Blog zu arbeiten. Ich hoffe mal, dass fertige Theme dann auch noch andere glücklich machen wird.

Ach ja, während ich diese Zeilen tippe, läuft auf dem Fernseher im Hotelzimmer Fußball-EM. Aber wer mich kennt, wird wissen, dass ich nicht wirklich Fußball schaue. Daher gibt es als Video zum Ende auch nichts zu dem Thema, sondern passend aus der Schweiz das Video mit der Ankündigung zum nächsten WordCamp Europe, bei dem ich auf jeden Fall auch wieder dabei sein werde:

Click here to display content from YouTube.
Erfahre mehr in der Datenschutzerklärung von YouTube.

Erstellung und Gestaltung des neuen Headers

Der Header war immer der Teil des Themes, bei dem ich mir nicht sicher war, ob ich ihn genau so nachbauen könnte. Aber mit jeder neuen Core- oder Gutenberg-Version kamen mehr Optionen hinzu, um das gewünschte Layout umzusetzen. I denke zwar, dass ich noch etwas CSS dazu schreiben muss, um einige Dinge anzupassen, aber schauen wir uns mal an, wie weit ich schon gekommen bin.

Der Original-Header

Bevor ich euch mein erstes Ergebnis zeige, dass ich nur mit dem Website-Editor und den darin vorhanden Einstellungen erreichen konnte, schauen wir uns erst noch einmal den Original-Header an:

Der eigentliche „Header“ im Waipoua Theme ist nur die Zeile mit dem roten Hintergrund. Website-Titel, Website-Untertitel und die „Header Widget Area“ befinden sich im „Wrapper“ für den Inhalt. Ich habe aber für das neue Theme entschieden, den gesamten hier gezeigten Bereich als Header festzulegen.

Der neue Header

Schauen wir uns ohne weiter Umschweife also nun an, wie weit ich gekommen bin, den Header nur mit dem Website-Editor nachzubauen. Da ist das erste Ergebnis:

Man kann schon auf Anhieb einige klare Unterschiede erkennen. Es beginnt schon mit dem „Home-Link“ Block als erstem Element der Navigation. Hier gibt es keine Option, ein Icon anzuzeigen. Ich werde das vermutlich mit etwas CSS lösen, indem ich ein Hintergrundbild verwenden und den „Home“ Text „visuell verstecke“.

Der andere klare Unterschied ist das Suchfeld. Im Waipoua Theme Header hat es einen transparenten Hintergrund. Das Icon ist nur ein Hintergrundbild, die Suche hat also keinen „Button“. Wenn das Feld fokussiert wird, dann wird es ein wenig breiter, der Hintergrund wird weiß und Icon und Platzhaltertext grau. Das ist ein netter Effekt und der „Suche“ Block hat sogar eine ähnliche Option, aber da er rechts ausgerichtet ist, hatte es den Effekt, dass das Feld „nach links springt und sich dann nach rechts vergrößert“. Das was nicht wirklich schön und auch nicht barrierefrei. Daher habe ich mich dagegen entschieden. Ich werde aber dennoch wie zuvor beschrieben die Hintergrundfarbe ändern, nur leider gibt es dafür keine Einstellungen. Lediglich die Hintergrund- und Icon-Farbe für den Button kann man einstellen. Es war mir auch nicht möglich, die Höhe des Suchfeldes zu ändern.

Wenn wir uns die „zweite Header-Zeile“ ansehen, dann sehen wir einen Unterschied im Website-Titel, der unterstrichen und kleiner ist. Das ist auch etwas, das ich im Website-Editor nicht einstellen konnte, da alle Einstellungen wohl über Core-Styles überschrieben wurden, da diese spezifischer waren.

Die Icons hingegen sehen fast gleich aus. Sie sind 1px kleiner (die „normale“ Größe im Core ist etwas kleiner), aber dafür sind die Icons besser zentriert als im Original-Theme und es werden auch die aktuellen Icons verwendet (z.B. bei YouTube oder Instagram). Leider gibt es aber kein „Kommentare RSS“ Icon. Ich muss mal schauen, wie ich das dann in meinem Blog löse. Aber verwendet überhaupt noch jemand diesen RSS-Feed? 🤔

Die Struktur des Headers

Nachdem wir nun das Ergebnis im Frontend gesehen habe, können wir uns mal ansehen, wie die Struktur im Website-Editor aussieht und welche Blöcke ich verwendet habe:

Die meisten Dinge sind keine Überraschung. Aber einige Details sind vielleicht neu für euch. Wusstest ihr zum Beispiel, dass ihr im Navigation Block nicht nur Links, sondern auch Blocke wie „Home-Links“, „Suche“ oder viele andere Blöcke verwenden könnt? Das ist wirklich toll und hat den Vorteil, dass diese Blöcke dann auf kleineren Bildschirmen ebenfalls im „Hamburg-Menü“ verschwinden.

Die zweite „Header-Zeile“ ist größtenteils relative einfach gestaltet. Um Website-Titel und Website-Untertitel unten auszurichten – etwas, zu dem ich zuvor keine einfache Lösung finden konnte – habe ich einfach die Option „Vertikale Ausrichtung ändern“ im Spalten-Block verwenden können.

Der interessantere Teil ist aber vermutliche die Zeile mit den Social-Media-Links. Wie zuvor erwähnt gibt es hierzu in Waipoua die „Header Widget Area“, die ich dann zu einem weiteren Template gemacht habe, wie wir es schon für die Sidebar getan haben.

Fazit: eine Menge an Einstellungen

Es ist schwer, jeden einzelnen Schritt bei der Umsetzung des Headers zu beschreiben. Es waren einfach zu viele Einstellungen notwendig, um zu diesem Ergebnis zu kommen. Ihr könnt alle Änderungen im aktuellen Commit des Git-Repositories zu diesem Theme finden. Ich war sehr überrascht, dass alle Einstellungen nur in den Templates gespeichert wurden. Ich habe lediglich noch einen neuen templateParts Eintrag in der theme.json angelegt, damit man „Header Widget Area“ in der „Listenansicht“ lesen kann und nicht den Slug, wie im Screenshot zu sehen.

Mein nächster Schritt wird die Behebung der vielen kleinen Unterschiede im Header sein, die ich nicht mit dem Website-Editor alleine umsetzen konnte. Mal sehen, wie weit ich komme und wie gut es mir gelingt, das im nächsten Blogbeitrag zu erklären. Da ich gerade meine Reise zum WCEU gestartet habe und noch einige Zugfahrten vor mir haben, gibt es den nächsten Beitrag vielleicht schon nächste Woche.

Verschieben der Sidebar in ein Theme Template

Eigentlich wollte ich, wie im letzten Beitrag erwähnt, mit dem Header weitermachen. Darin hatten wir mit dem Website-Editor eine Sidebar mit einer „synchronisierte Vorlage“ erstellt. Die Umsetzung hatte aber einige Probleme, ich ich erst einmal angehen wollte, bevor ich weitere Vorlagen erstelle. Daher werden wir die erste aktuelle Version erst ainmal verbessern.

Die Sidebar als synchronisierte Vorlage

Für das „Index“ Template hatten wir ein zweispaltiges Layout erstellt und die Sidebar in der rechten Spalte platziert. Wenn wir und den Quellcode der Startseite ansehen, dann erhalten wir das folgende:

<!-- wp:column {"width":"300px","style":{"spacing":{"padding":{"top":"0","bottom":"0","left":"0","right":"0"}}}} -->
<div class="wp-block-column" style="padding-top:0;padding-right:0;padding-bottom:0;padding-left:0;flex-basis:300px">
<!-- wp:block {"ref":1842} /-->
</div>
<!-- /wp:column --></div>

Die Sidebar ist hier mit einer ID referenziert. Diese Beitrags-ID gehört zur synchronisierten Vorlage und hat als post_type den Wert wp_block. Der post_content des Blocks entspricht den Blöcken, die wir zur Sidebar hinzugeführt hatten:

<!-- wp:group {"style":{"spacing":{"padding":{"top":"20px","bottom":"20px","left":"20px","right":"20px"}}},"backgroundColor":"background-secondary","layout":{"type":"constrained"}} -->
<div class="wp-block-group has-background-secondary-background-color has-background" style="padding-top:20px;padding-right:20px;padding-bottom:20px;padding-left:20px"><!-- wp:search {"label":"Search","showLabel":false,"buttonText":"Search","buttonPosition":"button-inside","buttonUseIcon":true} /-->

<!-- wp:heading {"level":3} -->
<h3 class="wp-block-heading">Recent Posts</h3>
<!-- /wp:heading -->

<!-- wp:latest-posts /-->

<!-- wp:heading {"level":3} -->
<h3 class="wp-block-heading">Recent Comments</h3>
<!-- /wp:heading -->

<!-- wp:latest-comments {"displayAvatar":false,"displayDate":false,"displayExcerpt":false} /-->

<!-- wp:heading {"level":3} -->
<h3 class="wp-block-heading">Categories</h3>
<!-- /wp:heading -->

<!-- wp:categories /-->

<!-- wp:heading {"level":3} -->
<h3 class="wp-block-heading">Archives</h3>
<!-- /wp:heading -->

<!-- wp:archives /--></div>
<!-- /wp:group -->

Hier sehen wir auch noch ein anderes Problem an der aktuellen Lösung: alle Headings (Überschriften) sind statisch in die Sidebar geschrieben. Das mag für eine Einzelseite in Ordnung sein, aber da ich einen mehrsprachigen Blog habe und das Theme auch für andere in allen Sprachen nutzbar machen möchte, müssten diese Strings übersetzbar sein. Wie erreichen wir das?

Umwandeln der synchronisierten Vorlage in ein Template bzw. eine Vorlage

Im ersten Schritt nehmen wir den letzten Codeschnipsel und speichern ihn in eine Datei. Wir könnten hierzu eine HTML-Datei verwenden, aber da wir den Inhalt übersetzen möchten, verwenden wir stattdessen eine PHP-Datei. Da die Sidebar nur ein Teil eines Templates, wie etwa dem „Index“ Templates ist, verwenden wir einen anderen Ordner. Am besten eignet sich hierfür das patterns Verzeichnis, was ja auch naheliegend ist, da es sich ja auch schon zuvor um eine Vorlage (Pattern) handelte.

Erstellen der Vorlage

Erstellen wir also zuerst eine Datei mit dem Namen patterns/sidebar.php und kopieren den Quellcode der synchronisierten Vorlage aus dem Website-Editor (gespeichert in der Datenbank) in diese Datei:

<?php
/**
 * Title: Sidebar
 * Slug: kauri/sidebar
 * Inserter: no
 */
?>
<!-- wp:group {"style":{"spacing":{"padding":{"top":"20px","bottom":"20px","left":"20px","right":"20px"}}},"backgroundColor":"background-secondary","layout":{"type":"constrained"}} -->
<div class="wp-block-group has-background-secondary-background-color has-background" style="padding-top:20px;padding-right:20px;padding-bottom:20px;padding-left:20px"><!-- wp:search {"label":"Search","showLabel":false,"buttonText":"Search","buttonPosition":"button-inside","buttonUseIcon":true} /-->

	<!-- wp:heading {"level":3} -->
	<h3 class="wp-block-heading"><?php esc_html_e( 'Recent Posts', 'kauri' ); ?></h3>
	<!-- /wp:heading -->

	<!-- wp:latest-posts /-->

	<!-- wp:heading {"level":3} -->
	<h3 class="wp-block-heading"><?php esc_html_e( 'Recent Comments', 'kauri' ); ?></h3>
	<!-- /wp:heading -->

	<!-- wp:latest-comments {"displayAvatar":false,"displayDate":false,"displayExcerpt":false} /-->

	<!-- wp:heading {"level":3} -->
	<h3 class="wp-block-heading"><?php esc_html_e( 'Categories', 'kauri' ); ?></h3>
	<!-- /wp:heading -->

	<!-- wp:categories /-->

	<!-- wp:heading {"level":3} -->
	<h3 class="wp-block-heading"><?php esc_html_e( 'Archives', 'kauri' ); ?></h3>
	<!-- /wp:heading -->

	<!-- wp:archives /--></div>
<!-- /wp:group -->

Jede Vorlage bekommt einen Header-Kommentar mit Eigenschaften wie Title, Slug und ähnliches. Da wir diese Vorlage nicht in der Auswahlliste der Vorlagen im Website-Editor benötigen, können wir Inserter: no im Header-Kommentar setzen.

Ihr könnt auch erkenne, dass nun alle Headings in Übersetzungsfunktionen stehen. Nun können wir die neue Vorlage in einem Template verwenden.

Die Vorlage verwenden

Da wir das „Create Block Theme“ verwendet haben, wurde die templates/index.html Datei bereits zuvor überschrieben, als wir alle Änderungen aus dem Website-Editor in die Theme-Dateien gespeichert hatten. Wie im ersten Codeschnipsel gezeigt, sollte dies die folgende Zeile enthalten:

<!-- wp:block {"ref":1842} /-->

Um nun die Vorlage zu verwenden, müssen wir dies mit einer Zeile wie der folgenden ersetzen:

<!-- wp:pattern {"slug":"kauri/sidebar"} /-->

Wir könnten das nun einfach direkt in der templates/index.html Datei tun, aber wir fügen noch einen weiteren Schritt dazwischen ein. Stattdessen erstellen wir zuerst eine Datei mit dem Namen parts/sidebar.html und fügen dort diese einzelne Zeile ein.

Aber wieso machten wir das? Neben Vorlagen gibt es noch eine zweite Art von „wiederverwendbaren Templates“. Diese andere Art sind „Template-Teile“, die als „Bereiche“ in eurem Theme betrachtet werden. Zwei davon haben wir bereits, nämlich „Header“ und „Footer“. Unsere „Sidebar“ ist im Grunde nichts anderes und daher macht es Sinn, diese auch als Template-Teil anzusehen. Daher sollten wir diese auch in der theme.json im Abschnitt templateParty hinzufügen:

{
	"templateParts": [
		{
			"area": "header",
			"name": "header",
			"title": "Header"
		},
		{
			"area": "footer",
			"name": "footer",
			"title": "Footer"
		},
		{
			"area": "uncategorized",
			"name": "sidebar",
			"title": "Sidebar"
		}
	]
}

Wenn wir jetzt diesen Template-Teil in das index.htm Template einzufügen, seht ihr noch einen weiteren Vorteil. So setzen wir es um:

<!-- wp:template-part {"slug":"sidebar","tagName":"aside"} /-->

Mit dem tagName Attribut, welches nicht für den wp:pattern Block verfügbar ist, können wir die Sidebar mit einem <aside> Tag umschließen, für eine bessere Barrierefreiheit.

Aufräumen

Nachdem wir die Sidebar in eine Vorlage im Theme verschoben haben, können wir nun gefahrlos zu „Design > Website-Editor > Vorlagen“ navigieren und dort die synchronisierte Vorlage (gespeichert in der Datenbank) löschen.

Fazit

Während man eine Theme/Layout baut, kann man das sehr gut und schnell im Website-Editor machen. Sobald man aber fertig ist, sollte man alle Änderungen in den Theme-Dateien speichern. Während dabei die meisten Änderungen durch das „Create Block Theme“ Plugin automatisch gespeichert werden, muss man manche Dinge noch manuell erledigen.

Ihr könnt alle Änderungen im aktuellen Commit des Git-Repositories zu diesem Theme finden. Ich bin positiv optimistisch, dass wir uns nun daran setzen können, am Header des Themes zu arbeiten.

Etwas Struktur in das Theme bringen: die Sidebar

Nachdem wir nun Schriftarten und Farben haben können wir damit anfangen ein wenig Struktur in das Theme zu bringen. Einer Seite eine klare Struktur zu geben ist wichtig, um sie später responsive zu bekommen.

Waipoua Strukture

Das Waipou Theme hat in etwa die folgende Struktur:

  • Header (roter Hintergrund)
    • Home Icon
    • Navigation
    • Suche
  • Wrapper
    • Zweiter Header
      • Website-Titel
      • Website-Untertitel
      • Alternative: Website-Icon, hinzugefügt durch die Theme-Optionen
      • Social-Media-Icons
    • Inhalt
    • Sidebar (hellgrauer Hintergrund)
    • Footer

Die Hauptidee des „Wrapper“ ist es, etwas Padding links und rechts zu bekommen, wenn das Display kleiner wird. Der rote Header wird aber einem bestimmten Breakpoint zu einem einzelnen Hamburg-Menu-Icon, das vertikal nach unter öffnet und die Navigation sowie die Suche enthält (das Home-Icon fehlt in diesem Menü).

Leeres Theme Strukture

Schauen wir uns im Vergleich die Struktur des „leeren Themes“ an. Das erhaltet ihr bei der Verwendung der „Leeres Theme“ Vorlage aus dem (vereinfacht):

  • Header
    • Website-Icon
    • Website-Titel
    • Website-Untertitel
    • Navigation
  • Inhalt
  • Footer

Wenn wir das mit dem Waipoua Theme vergleichen, sieht das schon sehr viel einfacher aus. Aber etwas Wichtiges fehlt: die Sidebar.

Eine Sidebar hinzufügen

Sidebars findet man heutzutage nicht mehr so häufig auf Websites. Aber bei einem Blog-Theme machen sie meiner Meinung nach noch immer Sinn. Und da ich ja ein Theme nachbauen möchte, das eine Sidebar hat, füge ich auch eine hinzu. Nun, das Theme hat sogar eine Theme-Option für eine zweite Sidebar. In der zweiten, die zwischen Inhalt und Sidebar sitzen, können Sticky Posts angezeigt werden:

A screenshot showing the front page with the content on the left, taking up about 40% of the width, the sidebars with the headline "featured posts" in the middle and the main sidebar on the right.

Ich konnte aber keine Möglichkeit finden, eine Auswahl anzubieten, mit der man dies für alle Seiten auswählen könnte. Daher habe ich mich entschieden, erst einmal nur mit einer einzelnen Sidebar für die erste Version des Themes zu verwenden.

Aber wie bekommen wir überhaupt eine Sidebar? Wir brauchen ein Element, das wir in mehreren Templates verwenden können und das immer den gleichen Inhalt hat. Die Antwort ist also: eine „synchronisierte Vorlage“. Die könnt ihr erstellen unter „Design > Website-Editor > Vorlagen“. Dort klickt ihr dann auf das Plus-Icon neben „Vorlagen“ und wählt „Vorlage erstellen“. Im Fenster wählt ihr dann als Name etwas wie „Sidebar“ und stellt sicher, dass die „Synchronisiert“ Einstellung aktiv ist. Nach einem Klick auf „Erstellen“ könnt ihr die Sidebar mit Inhalten befüllen. Im folgenden Beispiel habe ich die „Widgets“ aus dem klassischen Theme verwendet:

Screenshot der "Listenansicht" mit den Blöcken, über jedem davon eine Überschriften-Block. Auf der rechten Seite die Block-Einstellungen, in denen eine Hintergrundfarbe und Paddings gesetzt sind.

Für die Widget-Titel habe ich Überschriften-Blöcke verwendet. In manchen Blöcken müssen ein paar Einstellungen verändert werden. Im Suchen-Block habe ich den Button in das Feld verschoben und das Lupen-Icon eingestellt. Im Block für die letzten Kommentare habe ich alle Einstellungen deaktiviert, damit nur Name und Beitragstitel zu sehen sind.

Eine Sache, die ich beim ersten Versuch vergessen hatte: das Setzen einer Hintergrundfarbe und Paddings. Wir gruppieren also alle Blöcke in der Sidebar, setzen die Hintergrundfarbe auf „Background Secondary“ und unter „Größe > Innenabstand“ jeweils „20px“ vertikal und horizontal.

Platzieren der Sidebar auf der Seite

Nachdem wir nun die Sidebar haben, müssen wir sie noch in jedem Template einfügen. Fangen wir mit der Startseite an. Wir navigieren zu „Design > Website-Editor > Templates“ und wählen dort „Index“ aus, das einzige Template, das wir aktuell haben. Wie schon zuvor erwähnt, ist das Template eher simpel. Es verwendet lediglich einen „Abfrage-Loop“ Block im Inhalt. Das wird unsere „linke Spalte“. Richtig, wir verwenden einen Spalten-Block, um unser „Inhalt | Sidebar“ Layout zu bekommen. Die linke Spalte enthält dabei den Abfrage-Loop und die recht die Sidebar-Vorlage. So sieht das Egebnis aus:

Screenshot des "Index" Templates mit der "Listenansicht", die den "Abfrage-Loop" in der linken und die "Sidebar" Vorlage in der rechten Spalte enthält.

Ich versuche mal zu erklären, was ich hier gemacht habe. Zuerst einmal habe ich den „Abfrage-Loop“ in die linke Spalte gepackt und die „Sidebar“ in die rechte. Der „Spalten“ Block hat in der „Größe > Innenabstand“ Einstellung einen horizontalen Abstand von „50px“. Die rechte Spalte hat unter „Einstellungen > Breite“ eine Breite von „300px“ eingestellt, da sie Sidebar eine feste Breite hat. Die linke Spalte hat in diesem Feld einen leeren Wert. Das erlaubt ihr, die restliche Breite einzunehmen. Somit erhalten wir also eine responsive linke Spalte und eine rechte mit einer festen Breite.

Die Gruppe um die Spalten ist notwendig, um eine Breite für den gesamten Inhalt zu setzen. Diese Breite setzen wir aber nicht in diesem Gruppen-Block im „Index“ Template, sondern wir stellen es unter „Stile > Layout > Größe“ (das schwarz/weiße Icon oben rechts) ein. Hier setzen wir „Inhalt“ fest auf „1100px“.

Das Ergebnis

OK, nachdem wir all diese Schritte abgeschlossen haben, erhalten wir das folgende Ergebnis, wenn wir die Startseite unseres neuen Themes besuchen:

The frontend view of the front page with the two columns: content on the left, sidebar on the right with a light gray background.

Schön! Nicht wahr? OK, das Ergebnis sieht noch nicht nach dem aus, was wir am Ende haben wollen. Die Blöcke in der Sidebar sehen noch nicht wirklich gut aus. Aber für heute können wir zufrieden damit sein, dass wir es geschafft haben, ein Layout mit dem Inhalt und der Sidebar nebeneinander zu bekommen.

Fazit

Als ich zum ersten Mal versucht habe dieses Layout umzusetzen, habe ich mich damit recht schwergetan. Ich konnte keinen Weg finden, die „50px“ zwischen die beiden Spalten zu bekommen. Ich hatte zuerst noch eine mittlere Spalte mit „2px“ Breite, die sich dann zusammen mit dem Standardabstand von „24x“ zu „50px“ aufaddierten. Mit der neuen Version von WordPress können wir aber direkt einen Abstand von „50px“ einstellen. Das Twenty Twenty-Four Theme verwendet noch immer eine solche Spalte. Es hat sogar noch Spalten links und rechts, für etwas Padding. Zum Glück müssen wir das nicht mehr machen.

In der nächsten Woche werde ich wohl mit dem Styling des Headers weiter machen. Auch hier werden wir einen „Widget-Bereich“ brauchen, in dem die Social-Media-Icons platziert werden. Wir werden auch versuchen, die Elements auszurichten. Da könnte aber schwierig werden, denn bisher habe ich es noch nicht geschafft herauszufinden, wie ich Elemente unten ausrichten kann.

Etwas Farbe zum Block-Theme hinzufügen

Aus persönlichen Gründen konnte ich einige Zeit lang nicht am Theme arbeiten und daher auch keine neuen Blogbeiträge schreiben. Aber jetzt bin ich wieder zurück und bekomme hoffentlich ein wenig mehr Geschwindigkeit ins Thema und kann vielleicht sogar häufiger als nur alle zwei Wochen bloggen. Ich habe noch immer das Ziel, mein neues Theme vor dem Blog-Geburtstag im Juni fertig zu haben.

Farben hinzufügen

Für viele Leute kann es sehr zur Wiedererkennung beitragen, wenn man die richtigen Farben (einer Marke) verwendet. Fangen wir also mit den Hauptfarben an. Bevor wir aber damit starten können, müssen wir uns mit einem der schwierigsten Probleme in der Informatik beschäftigen: Dinge benennen.

Farbnamen

Es gibt verschiedene Philosophien, sie man Farben benennen kann. Manche verwenden Namen wie primary, secondary, tertiary, usw. Aber als nicht Nicht-Muttersprachler in Englisch, und Legastheniker, kann ich einfach nicht merken, wie man dritten Namen schreibt. Geschweige denn, wie es mit dem vierten, fünften, … dann weiter geht. Daher verwenden andere Namen wie base, contrast, accent und für mehrere Varianten davon fügen sie dann ein numerisches Suffix ein, also z.B. contrast-2, contrast-3, usw. Das ist auch das Schema, das im Twenty Twenty-Four Theme verwendet wird.

Aber ehrlich gesagt weiß ich auch nicht wirklich, was der beste Weg ist, die Namen für die Farben festzulegen. Und da das neue Theme ja eine „Wiederbelebung“ eines ElmaStudio Themes ist, habe ich mir mal angesehen, wie es Ellen und Manuel aktuell handhaben. Wenn ich mir die beiden aktuellsten Themes Mugistore und SolarOne ansehe, dann kombinieren sie die Farbnamen zu etwas wie background-primary, font-primary, accent-primary, usw. Ich werde also versuchen es in meinem Theme genauso zu machen.

Farbwerte den Farbnamen zuweisen

Nachdem ich mich jetzt auf ein Namensschema festgelegt habe, möchte ich allen Farben aus dem Waipoua Theme einen Farbnamen im neuen Theme zuweisen. Daher habe ich erst einmal nach allen Farben im Theme gesucht und insgesamt 26 verschiedene gefunden. Das sind wirklich viele! Aber einige davon werden nur für bestimmte CSS-Selektoren verwendet und andere nur in den farbigen Buttons und Boxen, die Shortcodes verwenden.

Nach der Recherche zu jeder einzelnen Farbe und wo diese verwendet wird, bin ich schließlich bei den folgenden Farbdefinitionen gelandet:

{
	"settings": {
		"color": {
			"defaultPalette": false,
			"palette": [
				{
					"slug": "black",
					"color": "#000000",
					"name": "Black"
				},
				{
					"slug": "white",
					"color": "#ffffff",
					"name": "White"
				},
				{
					"slug": "grey",
					"color": "#909090",
					"name": "Grey"
				},
				{
					"slug": "red",
					"color": "#F55243",
					"name": "Red"
				},

				{
					"slug": "background-primary",
					"color": "#ffffff",
					"name": "Background Primary"
				},
				{
					"slug": "background-secondary",
					"color": "#f6f6f6",
					"name": "Background Secondary"
				},
				{
					"slug": "background-tertiary",
					"color": "#b3b4ae",
					"name": "Background Tertiary"
				},
				{
					"slug": "background-quarternary",
					"color": "#909090",
					"name": "Background Quartenary"
				},

				{
					"slug": "font-primary",
					"color": "#333333",
					"name": "Text Primary"
				},
				{
					"slug": "font-secondary",
					"color": "#4c4a4a",
					"name": "Text Secondary"
				},

				{
					"slug": "primary",
					"color": "#f55243",
					"name": "Brand Primary"
				},

				{
					"slug": "border-primary",
					"color": "#ececec",
					"name": "Border Primary"
				},
				{
					"slug": "border-secondary",
					"color": "#dddddd",
					"name": "Border Secondary"
				},

				{
					"slug": "input-background",
					"color": "#ffffff",
					"name": "Input Background"
				},
				{
					"slug": "input-background-hover",
					"color": "#fcfcfc",
					"name": "Input Background Hover"
				},
				{
					"slug": "input-border",
					"color": "#999999",
					"name": "Input Border"
				},

				{
					"slug": "social-icons-background",
					"color": "#b3b4ae",
					"name": "Social Icons Background"
				},
				{
					"slug": "social-icons-background-hover",
					"color": "#333333",
					"name": "Social Icons Background Hover"
				},

				{
					"slug": "red-btn-box",
					"color": "#e22727",
					"name": "Red Button & Box"
				},
				{
					"slug": "green-btn-box",
					"color": "#71b247",
					"name": "Green Button & Box"
				},
				{
					"slug": "blue-btn-box",
					"color": "#56b3b7",
					"name": "Blue Button & Box"
				},
				{
					"slug": "yellow-btn",
					"color": "#f9d93a",
					"name": "Yellow Button"
				},
				{
					"slug": "yellow-box",
					"color": "#f7ec69",
					"name": "Yellow Box"
				},
				{
					"slug": "white-box",
					"color": "#fff",
					"name": "White Box"
				},
				{
					"slug": "lightgrey-box",
					"color": "#f6f6f6",
					"name": "Lightgrey Box"
				},
				{
					"slug": "grey-btn-box",
					"color": "#d3d3d3",
					"name": "Grey Button & Box"
				},
				{
					"slug": "dark-box",
					"color": "#333",
					"name": "Dark Box"
				},
				{
					"slug": "black-btn",
					"color": "#000",
					"name": "Black Button"
				}
			]
		}
	}
}

Insgesamt sind es 29 Farbdefinitionen. Wenn man den Farbwähler im Block Editor öffnet, beispielsweise in einem Absatz-Block, dann sieht man das folgende:

The color picker with the 29 defined colors, with some of them being shown multiple times.

Einige Farben sind hier „doppelt“, aber es ist genau, wie es auch andere ElmaStudio Themeas machen und ich denke, es ist eine gute Idee. Sagen wir zum Beispiel, dass ihr die Farbe aller Social-Media-Icons verändern möchtet. In diesem Fall müsst ihr nur den Wert von zwei dieser Farben verändern. Das wäre auch im „Style-Book“ möglich, aber über diesen Weg ist es sehr viel einfacher, vor allem dann, wenn ihr es in einem Child Theme anpassen möchtet.

Die Farben verwenden

Nachdem wir nun einige Farben haben, können wir diese verwenden. Um ein wenig mehr „Branding“ in das Theme zu bekommen, könnten wir mit der Header-Farbe anfangen. Das eigentliche Markup für den Header erstellen wir später, fangen wir also erst einmal im Website-Editor an:

Screenshot des Website-Editors mit dem geöffneten "header" Templates, in dem die Farben für den ersten Gruppen-Block wie beschrieben gesetzt wurden.

Wie kommen wir zu diesem Ergebnis? Zuerst einmal navigieren wir zu „Design > Website-Editor“. Dort klicken wir dann zweimal in den Header und anschließend auf den „Bearbeiten“ Button. Ein alternativer Weg hierher ist „Design > Website-Editor >Vorlagen > Header“ und dann den Header auswählen, den ihr bearbeiten wollt (wir haben aktuell nur einen). Dort klick ihr entweder auf das „Bearbeiten Icon“ (den Beistift) oben links oder ihr klickt einfach noch einmal in der Header im Haupt-Fenster.

Anschließend öffnen wir dann die „Listenansicht“ und wählen dort den ersten „Gruppe“ Block aus. In diesem gehen wir dann in den „Block“ Einstellungen auf den „Stile“ Tab (der schwarz/weiße Kreis). Als „Hintergrund“ Farbe wählen wir die „Brand Primary“ Farbe (rot) und klicken dann auf die „Text“ Farbe.

Da Waipoua im Theme eine 75% transparent verwendet, wählen wir erst einmal „White“ (die zweite Farbe in der ersten Reihe) aus. Anschließend klicken wir auf den „Vorschau-Bereich“. Das ist das weiße Quadrat (in diesem Screenshot mit dem „Schachmuster“) über dem Quadrat mit „White #FFFFFF“ (Im Screenshot „Individuell #FFFFFFBF“). Jetzt können wir entweder direkt den HEX Code mit der Transparenz eintragen (in diesem Fall „#FFFFFFBF“), oder aber wir wählen im Drop-Down RGB oder HSL aus und ändern dann den Wert für „A“ auf einen Wert von „75“. Das sollte uns dann das Ergebnis aus dem Screenshot geben.

Ich hoffe, ihr konntet mir bis hierhin folgen. Für jeden einzelnen Schritt einen Screenshot zu machen, wäre etwas viel gewesen. Vielleicht muss ich nächstes Mal doch ein Video aufnehmen. 😀

Die Änderungen ins Theme speichern

Alle Änderungen, die wir bisher am Header gemacht haben, stehen aktuell nur in der Datenbank. Sie spiegeln sich noch nicht in den Dateien unseres Themes wider. Um die Änderungen aus dem Header Template zu kopieren, könnten wir das rohe HTML aus dem Website-Editor in unsere Datei kopieren. Anschließend könnten wir die Änderungen gefahrlos im Website-Editor zurücksetzen.

Ein einfacherer Weg ist hier allerdings wieder die Verwendung des Create Block Theme Plugins. Es fügt im Website-Editor ein Icon hinzu, über dass ihr dann den aktuellen Zustand des Themes als ZIP-Datei herrunterladen oder die Dateien in euren Theme aktualisieren könnt. Beachtet aber, dass hierbei die Dateien ohne weitere Rückfrage sofort überschrieben werden. Ich hoffe, dass ihr alle Versionsverwaltung und eine gute IDE verwendet, dann ist das nicht so schlimm. Aber seid hier vorsichtig.

Screenshot, der die Optionen "Änderungen speichern" und "Export Zip" anzeige, sowie eine "Alter-Meldung", die über das erfolgreiche Speichern in die Theme-Dateien informiert.

Nachdem ihr auf das „Schraubenschlüssel“ Icon geklickt habt, öffnet sich die „Block-Theme erstellen“ Plugin-Seite. Darin könnt ihr dann auf den „Änderungen speichern“ Button klicken. Das speichert alles in euer Theme – nicht nur das aktuell geöffnete Template – und setzt anschließend alle Anpassungen in der Datenbank zurück.

Wir werden diese Option in Zukunft jedes Mal nutzen, nachdem wir Änderungen im Website-Editor vorgenommen haben. Nachtürlich könnten wir auch jedes Mal manuell den Code in die theme.json Datei schreiben, aber wieso sollten wird das tun? Stattdessen können wir das Theme einfach im Website-Editor erstellen und bekommen immer sofort eine Live-Vorschau.

Fazit

Das Setzen von ein paar Farben klingt erst einmal einfach, aber auch hier bedarf es etwas Planung. Ihr solltet wirklich sicher gehen, das von Anfang an richtig zu machen, bevor ihr anfangt Farben zu verwenden. Denn wenn ihr später etwas daran ändern möchtet, ist es sehr viel mehr Aufwand.

Nachdem wir nun unsere ersten Änderungen im Website-Editor gemacht haben, werden wir uns im nächsten Schritt um das Layout kümmern. Das wären zum Beispiel Spalten/Sidebar, Seitenbreite, Elemente im Header und Footer, usw. Es gab ein paar Dinge, bei denen ich mir nicht sicher war, ob diese umsetzbar wären, aber nachdem WordPress 6.5 gerade veröffentlicht wurde, scheinen einge Dinge einfacher geworden zu sein. Wenn das geklappt hat, könnt ihr euch schon bald auf den nächsten Blogbeitrag freuen.

Schriftarten zu unserem Block-Theme hinzufügen

Nachdem wir im letzten Beitrag das rohe Theme erstellt haben, ist es nun an der Zeit, ein paar grundlegende Dinge hinzuzufügen. Um schnell ein ähnlicheres Aussehen zu erhalten, könnten wir mit den Schriftarten anfangen.

Mein Blog verwendet die Standard-Schriftarten von Waipoua, ich habe allerdings die Hauptfarben in einem Child-Theme geändert. Das Theme sieht ohne Änderungen wie folgt aus:

Screenshot of the original design of the Waipoua theme, showing the blog listings front page with social icons in the top right and the gray sidebar on the right.

WIe ihr also sehen könnt habe ich den Rot-Ton im Header geändert, sowie die Hintergrundfarbe der Sidebar. Außerdem habe ich die Social-Icons oben rechts eingefärbt. Der Rest sieht aber ziemlich ähnlich zum Parent-Theme aus.

Hinzufügen der Schriftarten

Das wird ein interessantes Kapitel. Stand heute würde man hierzu folgendes tun:

  1. Herunterladen der Schrifarten – für Google Fonts verwende ich hierzu normalerweise den google-webfonts-helper und lade alle Varianten herunter
  2. Speichern der Schriften in einem Ordner in eurem Theme
  3. Definieren der Schriften in der theme.json Datei

Wenn ihr diesen manuellen Weg gehen wollt, dann ich euch die hervorragende Anleitung von Carolina auf der „Full Site Editing With WordPress“ website sehr empfehlen.

Aber da es bald eine neue Möglichkeit gibt Schriften zu einem Block-Theme hinzuzufügen, möchte ich diesen Weg kurz zeigen. Mit der aktuellen WordPress Version 6.4 müsst ihr hierzu noch zusätzlich das Gutenberg-Plugin installieren, da die Funktion noch nicht „final“ ist und somit noch nicht mit Version 6.4 in den Core gemerged wurde. Wir müssen uns also noch ein wenig gedulden.

Mit dem aktivierten Gutenberg-Plugin navigiert ihr dann zu „Design > Theme-Schriften verwalten“. Hier erhaltet ihr die folgende Ansicht:

Screenshot der "Theme-Schriften verwalten" Ansicht, mit einer Anzeige der installieren Schriften rechts, einer Vorschau dieser Schriften in der Mitte, sowie den zwei Buttons "Google Font hinzufügen" und "Lokale Schrift hinzufügen".

Hier seht ihr eine Übersicht der aktuell im Theme vorhandenen Schriften auf der rechten Seite, sowie eine Vorschau für diese Schriften. Oben rechts könnte ihr die beiden Buttons „Google Font hinzufügen“ oder „Lokale Schrift hinzufügen“ verwenden, um eine neue Schriftart zu eurem Theme hinzuzufügen.

Fangen wir mit der Schriftart für Überschriften an. Hierfür wird die Google Font „Oswald“ verwenden. Wir klicken also auf den Button „Google Font hinzufügen“ und wählen dann im Dropdown die Schriftart aus. Anschließend sehen wir alle verfügbaren Varianten. Ich habe einfach alle über die Checkbox im Tabellenkopf ausgewählt:

Screenshot der "Google Fonts zu deinem Theme hinzufügen" Ansicht mit allen verfügbaren Varianten.

Das Waipoua Theme hatte nur die Stärke 400 verwendet, aber da man mit einem Block-Theme mehr Kontrolle darüber hat, welche Schriften man wo verwenden möchte, fand ich es eine gute Idee einfach alle verfügbaren Varianten zur Verfügung zu stellen. Damit sieht dann der Text immer optimal aus, ganz egal, welche Stärke (sofern verfügbar) man verwendet.

Nach einem Klick auf den „Google Fonts zu deinem Theme hinzufügen“ Button solltet ihr eine Erfolgsmeldung wie „Die Schrift Oswald wurde zum Theme Kauri hinzugefügt“ sehen. Das gleiche machen wir jetzt noch einmal für die Schrift „PT Sans“ und wählen auch hier wieder alle Varianten aus.

Wenn wir nun zu „Theme-Schriften verwalten“ zurück navigieren, dann sollten wir diese neuen Schriften in der rechten Sidebar sehen können. Insgesamt haben wir zwei Schriften mit insgesamt 10 Varianten und einer Gesamtgröße von 1,5 MB hinzugefügt:

Screenshot mit der Übersicht der im vorherigen Schritt hinzugefügten Schriften.

Ergebnis des Schriften-Imports

Sehen wir uns mal an, was wir nach dem letzten Schritt erhalten haben. Die Orderstruktur des Themes sieht nun wie folgt aus:

$ tree .
.
├── assets
│   └── fonts
│       ├── oswald_normal_200.ttf
│       ├── oswald_normal_300.ttf
│       ├── oswald_normal_400.ttf
│       ├── oswald_normal_500.ttf
│       ├── oswald_normal_600.ttf
│       ├── oswald_normal_700.ttf
│       ├── pt-sans_italic_400.ttf
│       ├── pt-sans_italic_700.ttf
│       ├── pt-sans_normal_400.ttf
│       └── pt-sans_normal_700.ttf
├── parts
│   ├── footer.html
│   └── header.html
├── readme.txt
├── screenshot.png
├── style.css
├── templates
│   └── index.html
└── theme.json

Wir haben also einen neuen Ordner „assets/fonts“ und darin liegen die Google Fonts. Da diese aber nur als TTF-Dateien von fonts.google.com heruntergeladen werden können, erhalten wir auch genau dieses Format mit der (aktuellen) Schriften-Verwaltung von Gutenberg.

Aber schauen wir uns mal die theme.json Datei an, denn das ist der interessantere Teil des ganzen Schritts. Ihr solltet nun etwas finden, das in etwa so aussieht:

{
	"settings": {
		"typography": {
			"fontFamilies": [
				{
					"fontFamily": "-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen-Sans, Ubuntu, Cantarell, 'Helvetica Neue', sans-serif",
					"name": "System Font",
					"slug": "system-font"
				},
				{
					"fontFamily": "Oswald",
					"slug": "oswald",
					"fontFace": [
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "200",
							"src": [
								"file:./assets/fonts/oswald_normal_200.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "300",
							"src": [
								"file:./assets/fonts/oswald_normal_300.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "400",
							"src": [
								"file:./assets/fonts/oswald_normal_400.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "500",
							"src": [
								"file:./assets/fonts/oswald_normal_500.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "600",
							"src": [
								"file:./assets/fonts/oswald_normal_600.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "700",
							"src": [
								"file:./assets/fonts/oswald_normal_700.ttf"
							]
						}
					]
				},
				{
					"fontFamily": "PT Sans",
					"slug": "pt-sans",
					"fontFace": [
						{
							"fontFamily": "PT Sans",
							"fontStyle": "normal",
							"fontWeight": "400",
							"src": [
								"file:./assets/fonts/pt-sans_normal_400.ttf"
							]
						},
						{
							"fontFamily": "PT Sans",
							"fontStyle": "italic",
							"fontWeight": "400",
							"src": [
								"file:./assets/fonts/pt-sans_italic_400.ttf"
							]
						},
						{
							"fontFamily": "PT Sans",
							"fontStyle": "normal",
							"fontWeight": "700",
							"src": [
								"file:./assets/fonts/pt-sans_normal_700.ttf"
							]
						},
						{
							"fontFamily": "PT Sans",
							"fontStyle": "italic",
							"fontWeight": "700",
							"src": [
								"file:./assets/fonts/pt-sans_italic_700.ttf"
							]
						}
					]
				}
			]
		}
	}
}

Nach der „System Font“ finden wir nun eine neue Definition für jede Variante unsere beiden neuen Schriften. Das ist eine ganze Menge Code, der uns hier automatisch erstellt wurde, und den wir somit nicht selbst schreiben müssen.

Wenn ihr nun aber die Seite neu ladet, dann werdet ihr erst einmal keine Änderung sehen. Das liegt daran, dass wir nun zwar die neuen Schriften zu unserem Theme hinzugefügt haben, sie aber noch an keiner Stelle in der theme.json Datei verwenden.

Schriften für Inhalt und Überschriften festlegen

Man kann die Schriftart für die ganze Seite, für bestimmte „Arten“ von Elementen, oder aber für individuelle Blöcke einstellen. Um das Ergebnis zu erhalten, das wir wollen, müssen wir das folgende zu unserer theme.json Datei hinzufügen:

{
	"styles": {
		"elements": {
			"heading": {
				"typography": {
					"fontFamily": "var(--wp--preset--font-family--oswald)",
					"fontWeight": "400"
				}
			}
		},
		"typography": {
			"fontFamily": "var(--wp--preset--font-family--pt-sans)",
			"fontWeight": "400"
		}
	}
}

Das legt die Schriften für den Inhalt sowie alle Überschriften fest, also sowohl Überschriften im Inhalt, als auch im core/site-title oder anderen „Überschriften“ Blöcken. Wir werden das später noch einmal etwas genauer anpassen müssen, aber aktuell erhalten wir damit das folgende Ergebnis:

The front page with the two fonts.

Wenn es um die Schriften geht, dann sieht unsere Seite schon sehr viel mehr nach dem Original-Theme aus. Aber das ist natürlich lediglich der erste Schritt. Wir müssen noch viele weitere Dinge anpassen.

Bonus: Eine WOFF2 anstelle einer TTF Schrift verwenden – der beide

An der aktuellen Lösung mag ich nicht wirklich, dass sie TTF Dateien verwendet. Diese werden in der Regel für Desktop verwendet, und nicht im Web. Auch wenn sie von den meisten Browsern unterstützt werden, so sind sie doch sehr viel größer.

Wenn wir den google-webfonts-helper verwenden, können wir alle Schriften im WOFF2 Format runterladen und die theme.json Datei entsprechend anpassen. Ich habe hierzu auch noch alle Schriftarten jeweils in einen Unterordner gepackt, um sie besser zu organisieren.

Mit diesen Änderungen konnte ich die Größe aller Fonts von 1,5 MB auf nur noch ungefähr 590 KB für alle Varianten verringern. Auch wenn dieser Schritt nicht unbedingt notwendig ist, würde ich ihn euch doch sehr empfehlen. Es sei denn, ihr müsst unbedingt noch sehr alte Browser unterstützen. Dann könnt ihr natürlich auch ein anders Format mit dem google-webfonts-helper herunterladen.

Ihr könnt aber auch die TTF-Dateien als Fallback behalten. Dann könnte das in etwa wie folgt aussehen:

{
	"fontFamily": "Oswald",
	"fontStyle": "normal",
	"fontWeight": "200",
	"src": [
		"file:./assets/fonts/oswald/oswald-v53-cyrillic_cyrillic-ext_latin_latin-ext_vietnamese-200.woff2",
		"file:./assets/fonts/oswald/oswald-v53-cyrillic_cyrillic-ext_latin_latin-ext_vietnamese-200.ttf"
	]
}

Das vollständige Beispiel findet ihr im GitHub Repository des Themes.

Versteckte Funktion der „Theme-Schriften verwalten“ Funktionalität

Beim committen der Änderungen am Theme war mit aufgefallen, dass die readme.txt Datei verändert worden war. Zuerst dachte ich, dass ich daran bestimmt etwas geändert hatte. Aber dann sind mir folgende zusätzliche Zeilen aufgefallen:

Oswald Font
Copyright 2016 The Oswald Project Authors (https://github.com/googlefonts/OswaldFont) 
This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL 
License URL: https://scripts.sil.org/OFL 
Source: http://www.sansoxygen.com
-- End of Oswald Font credits --

PT Sans Font
Copyright © 2009 ParaType Ltd. All rights reserved. 
Copyright (c) 2010, ParaType Ltd. (http://www.paratype.com/public), with Reserved Font Names "PT Sans", "PT Serif" and "ParaType". 
License URL: http://scripts.sil.org/OFL_web 
Source: http://www.paratype.com
-- End of PT Sans Font credits --

Die Funktionalität kümmert sich also nicht nur darum, dass die Schriften heruntergeladen, im Theme gespeichert und zur theme.json Datei hinzugefügt werden. Sie stelle auch sicher, dass ihr die notwendigen rechtlichen Angaben in euer readme.txt Datei habt. Wie cool ist das denn?! 🤓

Zusammenfassung

Das Hinzufügen von Google Fonts (oder Schriften aus anderen Quellen) kann über zwei Wege geschehen: manuell oder über „Theme-Schriften verwalten“. Während letzteres noch nicht ganz „fertig“ ist, funktioniert es doch erstaunlich gut. Wenn sie jetzt noch eine Funktion hinzufügen, mit der man ein anderes Format auswählen kann (oder den Standard ändern), dann kann ich es kaum erwarten, bis diese Funktion im Core landet.

Ich hatte eigentlich ursprünglich geplant in diesem Beitrag auch noch darüber zu schreiben, wie man Farben und die Breite der Seite festlegt. Aber ich denke mit dem Thema über Schriften reicht es auch für diesen Beitrag.

Startschuss für mein neues Blog-Theme

Dies ist der Anfang einer neuen Beitrags-Serie für mein neues Blog-Theme. Wie in meinem vorherigen Blogbeitrag erwähnt, ist es mein Ziel, ein Theme zu bauern, das so nah an das aktuelle Design heran kommt, wie möglich. Dabei möchte ich nur den Website-Editor verwenden, um alle Styles und Templates zu erstellen.

Erstellung des Themes

Wenn ich in der Vergangenheit Themes von Grund auf entwickelt habe, dann habe ich hierzu meistens _s (underscores) verwendet. Aber da dies ein „Classic Starter Theme“ ist, brauchte ich etwas anderes. Glücklicherweise gibt es das „Create Block Theme“ Plugin, mit dem man ein Theme innerhalb einer WordPress Installation erstellen kann.

Nach der Installation und Aktivierung des Plugins navigiert man zu „Design > Block-Theme erstellen“ und wählt „Leeres Theme erstellen“ als Option aus. Auf der rechten Seite erscheint dann ein Formular, in dem ihr Name, Beschreibung, usw. für das neue Theme eintragen müsste. Das sind die Daten, die man für gewöhnlich im Header-Kommentar der style.css Datei findet.

Nachdem ihr das Formular ausgefüllt habt, klickt ihr auf den „Erstellen“ Button unten links. Das erstellt das neue Theme in eurer WordPress Installation. Jetzt könnt ihr es aktivieren und euch eure Seite ansehen. Das Ergebnis sollte in etwa wie folgt aussehen:

The frontend result of the theme with the site title in the top left, a navigation sith "Sample Page" in the top right, the "Hello World" blog post in the middle, and the "Proudly Power by WordPress" in the bottom, all with no styles.

Wunderschön, nicht wahr? OK, noch nicht ganz das, was wir brauchen. Aber es ist bereits ein voll funktionsfähiges Block-Theme und wir können anfange, all die Styles hinzuzufügen, die wir brauchen.

Die Dateistruktur des Themes

Bevor wir aber mit unseren Arbeiten an Theme loslegen, schauen wir uns erst einmal an, was wir haben. Die initiale Dateistruktur unseres neuen Themes sieht wie folgt aus:

$ tree
.
├── parts
│   ├── footer.html
│   └── header.html
├── readme.txt
├── screenshot.png
├── style.css
├── templates
│   └── index.html
└── theme.json

2 directories, 7 files

Nicht wirklich viel. Aber wir haben bereits zwei „Parts“ für Header und Footer. Das einzige „Seiten Template“, das wir haben, ist die index.html Datei. Die style.css Datei ist im Grunde leer. Sie enthält lediglich die Header-Kommentare mit den Daten aus dem Formular. Interessanterweise finden wir darin eine Zeile mit der Angabe Requires PHP: 5.7, obwohl es diese PHP Version nie gab. 😅

Die wichtigste Datei ist aber die theme.json Datei. In dieser Basisversion hat sie lediglich 35 Zeilen und definiert ein paar Layout-Größen, Spacing-Einheiten und eine Sytem-Font-Family, sowie die Template Parts für den Header und Footer.

Im nächsten Blogbeiträgen dieser Serie werden wir recht viel mit dieser Datei arbeiten.

Der Name des neuen Themes

Wie ihr vielleicht schon festgestellt habt, habe ich das neue Theme „Kauri“ genannt (sowie die Entwicklungs-Seite). Das aktuelle Theme meines Blogs heißt Waipoua. Elmastudio benennt alle Themes nach Dingen in Neuseeland oder Asien. Der Waipoua Forest ist ein Wald in der Northland Region von Neuseeland. Dieser Forest zeige eine Auswahl von Kauri-Bäumen. Und spätestens jetzt sollte klar sein, wieso ich diesen Namen gewählt habe. 😊

Nächste Schritte

In der nächsten Ausgabe machen wir die ersten Anpassungen an der theme.json Datei. Vielleicht fügen wir ein paar Fonts ein, oder geben dem Theme eine generelle Breite. Bleibt also gespannt.

Wenn ihr dem Code folgen wollt, dann findet ihr den aktuellen Stand auf GitHub. Aber bitte erstellt noch keine Issues oder Pull-Requests, bevor ich diese Beitrags-Serie nicht abgeschlossen habe. 😁