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
Der neue Header
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:
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>© <?php echo date( 'Y' ); ?> </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 ', '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. 🙌