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. 😁

Neues Jahr, neues Projekt, neues Theme – was 2024 kommen wird

Es ist zwar nicht das neue „Blog-Jahr“, aber ein neues auf unseren Kalendern. In den letzten Jahren habe ich mir über die Feiertage oft vorgenommen, das Theme meines Blogs neu zu machen. Dieses Jahr habe ich endlich damit begonnen … am 1. Januar 😅

Weiterführung von #projekt26

Eines vorweg: Ich werde auch weiterhin am #projekt26 teilnehmen, also alle zwei Wochen etwas posten. Normalerweise plane ich hierbei die Beiträge nicht wirklich im Vorfeld. Aber dieses Jahr habe ich mir ein zweites Projekt vorgenommen, wodurch ich hoffentlich sehr viel einfacher Themen finden werde. Ich werde aber zwischendurch vermutlich auch über anderes bloggen.

Ein neues, altes Theme

Aktuell verwende ich das schöne Waipoua Theme von Elmastudio. Ich verwende es schon seit Juli 2012 und liebe noch immer das klassische Blog-Design. Aber da es sehr als ist, gibt es auch einige Dinge, die es niciht mehr zum perfekten Theme machen. Gerade wegen der Probleme bezüglich der Barrierefreiheit möchte ich es ersetzen.

Frisch starten, aber das Aussehen übernehmen

Das optimale Ergebnis wäre natürlich eines, das auf eine neue technische Basis gestellt wird, aber eine exakte „Pixel-perfekte“ Kopie ist. Weil ich aber auch den Website-Editor für das neue Theme verwenden möchte, scheint das nicht möglich zu sein. Da ich mir unsicher war, welches Ziel ich verfolgen sollte, habe ich mal auf Twitter gefragt:

Hier klicken, um den Inhalt von twitter.com anzuzeigen

„Inhalt“ direkt öffnen

Im Resultat und den Kommentaren haben die meisten gesagt, dass ich nur das generelle Aussehen des Themes übernehmen sollte und genau das werde ich versuchen.

Eine Beitrags-Serie mit Schritt-für-Schritt-Anleitung

Für die zukünftigen Beiträge habe ich geplant, jeden einzelnen Schritt in der Erstellung des neuen Themes zu dokumentieren. Ich hoffe, dass das für viele von euch hilfreich sein wird, die eine ähnliche Idee haben. Und da ich normalerweise in meiner täglichen Arbeit keine (neuen) Themes erstelle, kann ich dabei auch viel lernen und mich besser mit dem Website-Editor vertraut machen.

Meine erste lange Beitrags-Serie

Ich habe schon ein paar Beitrags-Serien gemacht, aber diese hier wird wohl mindestens ins zweite Quartal dieses Jahres reichen. Vielleicht schaffe ich es ja, mit dem neuen Theme zum Blog-Geburtstag im Juni zu starten.

Ich werde auch versuchen, den ganzen Code-Fortschritt öffentlich zu machen und auch eine Staging-Seite des aktuellen Stands erstellen. Aber mehr hierzu im nächsten Beitrag.

Falls ihr das Theme selbst verwendet, würde ich mich sehr freuen, wenn ihr mit Feedback dazu geben könnt, was ihr gerne im neuen Theme sehen möchtet. Oder vielleicht habt ihr selbst mal etwas Ähnliches gemacht, dann hinterlasst sehr gerne einen Kommentar.

Schnelles Debugging von SSH-Verbindungen

Zum wiederholten Male hatte ich diese Woche Probleme, mich per SSH mit einem Server zu verbinden. Es war mit einem anderen User und irgendetwas hat nicht funktioniert. Wenn ich solche Fehler debugge, muss ich immer wieder danach suchen, wie man den Debug-Modus aktivieren kann. Daher schreibe ich das jetzt mal in meinem eigenen Blog auf, damit ich es nächstes Mal schneller wiederfinde.

Starten eines zusätzlichen OpenSSH-Daemon im Debug-Modus

Ihr könnte recht einfach den Debug-Modus im Client aktivieren, aber oft liegt das Problem auch auf dem Server. Um das zu debuggen, könnt ihr den Debug-Modus im Hauptprozess aktivieren. Aber es ist oft einfacher und sicherer, einen zusätzlichen SSH-Daemon unter einem anderen Port und mit aktiviertem Debug-Mode zu starten. Das könnt ihr mit dem folgenden Befehl machen:

/usr/sbin/sshd -ddd -D -p 22222

Ihr müsst hier den vollständigen Pfad zu sshd verwenden. Mit dem -D Parameter wird sshd nicht als Daemon im Hintergrund ausgeführt und ihr könnt die Log-Ausgabe sehen. Mit -ddd wird das maximale Debug-Level aktiviert. Und mit -p 22222 verwenden wir einen anderen Port.

Den Debug-Mode des Clients verwenden

Nachdem wir nun einen Server-Prozess mit aktivierten Debugging haben, der auf einkommende Verbindungen wartet, können wir uns mit einem Client verbinden. Dazu verwenden wir den folgenden Befehl:

ssh -vvv -p 22222 -i ~/.ssh/id_ed25519 user@example.com

In diesem Beispiel verwenden wir den zuvor gesetzten Port 22222. Wir spezifizieren hier auch einen anderen Secret-Key mit -i ~/.ssh/id_ed25519 und schließlich setzen wir mit -vvv auch das maximale Debug-Level für den Client.

Zwei typische Fehler für SSH-Server und Client

Jetzt sollten wir in der Lage sein, die Fehler von Server und/oder Client zu finden. Hier sind zwei typische Fehler, denen ich oft begegne.

Falsche Dateiberechtigungen auf dem Server

Fehler mit SSH sind sehr oft falsch gesetzte Berechtigungen für Dateien und Ordner. Das ist ein typischer:

debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: Could not open authorized keys '/home/user/.ssh/authorized_keys': Permission denied

Wenn ihr diesen Fehler seht, dann habt ihr vielleicht den Public-Key korrekt zu authorized_keys Datei hinzugefügt, die Datei ist aber nicht durch den SSH-Daemon lesbar. Um das zu korrigieren, solltet ihr die Berechtigungen in etwa so anpassen:

chmod 700 /home/user/.ssh/
chmod 644 /home/user/.ssh/authorized_keys

Wenn ihr einen Fehler beim letzten Verbindungsversuch bekommen habt, dann wurde der Server-Prozess vermutlich beendet. Ihr solltet also sicherstellen, dass ihr ihn vor dem nächsten Versuch neu startet.

Falsche Dateiberechtigungen im Client

Auch beim Client führen sehr oft falsche Berechtigungen zu Fehlern. Wenn die Berechtigungen „zu offen“ sind, dann bekommt ihr eine Meldung, die in etwa so aussieht:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for 'id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_ed25519": bad permissions
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
user@example.com: Permission denied (publickey).

Die Lösung hierfür ist sehr ähnlichen zum Server. Aber in diesem Fall müsst ihr sicherstellen, dass die Berechtigungen nicht zu weitgefasst sind und nur der User Zugriff auf den Private-Key hat:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Der Public-Key kann auch durch andere lesbar sein. Der zweite Befehl ist also optional.

Fazit

Es gibt viele Probleme, auf die ihr bei der Arbeit mit SSH stoßen könnt. SSH ist wirklich sehr strikt, wenn es um Berechtigungen geht. Wenn ihr den Fehler mit einem zu offenen Private-Key hattet und auf einem Client/Computer arbeitet, auf dem es auch andere User gibt, dann solltet ihr den Key am besten wegwerfen und einen neuen erstellen. Wenn ihr hierzu ssh-keygen verwendet, dann hat das eine Schlüsselpaar auch gleich die richtigen Berechtigungen.

Ich verwende zheutztage nur noch SSH um mich per Terminal zu Servern zu verbinden oder Dateien zu übertragen. Die Verwendung von Schlüsselpaaren ist hierbei oft der beste Weg. Aber diese Berechtigungen können echt schwierig sein. Hoffentlich wisst ihr nun, wie ihr solche Fehler debuggen könnt – genau wie ich, denn jetzt kann ich hier nächstes Mal nachlesen, wie ich den Debug-Modus verwenden kann. 😀

Stylelint Fehler während der Programmierung in PhpStorm anzeigen und beheben

Die Befolgung von Coding-Standards ist nicht nur wichtig, wenn man alleine programmiert, sondern noch viel wichtiger, wenn man in einem Team arbeitet. Es bedeutet weniger Fehler und vermeidet unnötige Änderungen bei der Nutzung einer Versionskontrolle, was auch schnell zu Konflikten führen kann.

Ich nutze PhpStorm als meine IDE und bei der Entwicklung von WordPress Plugins und Themes heutzutage „wp-scripts“ um SCSS oder JavaScript zu kompilieren. Dieses Paket kommt auch mit „Stylelint„, einem Kommandozeilen-Tool für das „linten“ eures Codes.

Ausführen des Linters auf der Kommandozeile

Ihr könnt den „lint-style“ Befehl von „wp-scripts“ in eurer package.json Datei konfgurieren. Anschließend könnt ihr ihn wie folgt ausführen:

$ npm run lint:style

> @2ndkauboy/dark-mode-for-astra@1.0.0 lint:style
> wp-scripts lint-style


src/style-dark-mode.scss
  5:3   ✖  Expected empty line before comment  comment-empty-line-before
 11:22  ✖  Expected a leading zero             number-leading-zero
 22:6   ✖  Expected indentation of 2 tabs      indentation
 27:9   ✖  Expected indentation of 2 tabs      indentation
 72:6   ✖  Expected empty line before at-rule  at-rule-empty-line-before

5 problems (5 errors, 0 warnings)

Nachdem ihr den Befehl ausgeführt habt, seht ihr eine Liste von Problemen, die gefunden wurden. In der letzten Spalte findet ihr auch den Namen der Regel. Falls ihr eine dieser Regel ignorieren/ausschließen wollt, könnt ihr eine eigene Konfigurationsdatei in eurem Projekt anlegen.

Ausführen der Tests im Code-Editor von PhpStorm

Diese Tools können sehr gut auf der Kommandozeile oder später im CI-Prozess (z.B. in einer GitHub Action) verwendet werden. Aber in der Regel kommen die Tests dann zu spät, denn man hat den Fehler schon gemacht und/oder ihn sogar commitet. Wäre es nicht schön, wenn man schon früher auf die Fehler hingewiesen wird? Glücklicherweise hat PhpStorm eine gute Integration für Stylelint. Ihr findet sie unter „Settings | Languages & Frameworks | Style Sheets | Stylelint“. Hier müsste ihr zuerst „Enable“ auswählen und könnt dann die Parameter konfigurieren.

Wenn ihr mit Windows und WSL2 arbeitet, dann könnte eure Konfiguration in etwa so aussehen (ihr müsst hier natürlich die Pfade entsprechend eures lokalen Setups anpassen):

Stylelint package: \wsl$\Ubuntu\home\bernhard\PhpstormProjects\theme-tests\wp-content\plugins\dark-mode-for-astra\node_modules\stylelint
Configuration file: \wsl$\Ubuntu\home\bernhard\PhpstormProjects\theme-tests\wp-content\plugins\dark-mode-for-astra\node_modules\@wordpress\scripts\config.stylelintrc.json
Run for files: **/src/{**/*,*}.{css,scss}

Auf Linux/Mac, könnte es so aussehen (auch hier die Pfade anpassen):

Stylelint package: ~/PhpstormProjects/theme-tests/wp-content/plugins/dark-mode-for-astra/node_modules/stylelint
Configuration file: ~/PhpstormProjects/theme-tests/wp-content/plugins/dark-mode-for-astra/node_modules/@wordpress/scripts/config.stylelintrc.json
Run for files: **/src/{**/*,*}.{css,scss}

In diesem Beispiel habe ich „Run for files“ auf den src Ordner begrenzt. Auf meinem Linux-System hat PhpStorm nämlich ansonsten jede einzelne CSS/SCSS Datei im gesamten Projekt überprüft und mein System lahmlegt. Falls ihr, wie zuvor erwähnt, eine eigene Konfigurationsdatei verwendet, könnt ihr diese bei „Configuration file“ angeben. Ansonsten könnt ihr die Standarddatei, wie hier gezeigt, verwenden. Wenn ihr den Pfad zum „Stylelint package“ richtig konfiguriert habt, dann seht ihr im Einstellungsfenster in dieser Zeile auf die installierte Versionsnummer:

Einstellung für "Stylelint" mit der Anzeige der Versionsnummer "14.16.1" in der Zeile für das "Styleline package".

Überprüfung der Fehler beim Tippen

Nachdem wir die Integration für Stylelint eingerichtet haben, können wir die Datei mit den vorhanden Fehlern im Editor öffnen:

Anzeige der Fehler im Code-Editor, mit einem davon hervorgehoben, was ein Modal darunter öffnet, das mehr Details zum Fehler anzeigt.

In diesem Screenshot sieht man mehrere Dinge bezüglich der von Stylelint gefundenen Fehlern. In der rechten Scrollbar seht ihr eine rote Hervorhebung für jede Zeile mit einem Fehler. Oben rechts können wir 5 Fehler in der Datei sehen (genau wie bei dem Aufruf auf der Kommandozeile). Im Code-Editor selbst sehen wir jeden Fehler als rote Unterstreichung. Wenn man mit der Maus auf einen dieser Fehler geht, werden mehr Details angezeigt, auch hier wieder mit dem Namen der Regel, gegen die verstoßen wurde.

Fehler auf der Kommandozeile beheben

Stylelint bring einen Parameter mit, mit dem man Fehler automatisch beheben kann – falls das möglich ist. Das sind in der Regel „Whitespace-Fehler“. Um solche behebbaren Fehler automatisch zu beheben, kann folgender Befehl verwendet werden:

npm run lint:style -- --fix

Da wir „wp-scripts“ in einem npm Skript verwenden, müssen wir noch zwei Bindestriche zwischen dem Befehl und dem Parameter hinzufügen, damit dieser weitergereicht wird.

Fehler in PhpStorm beheben

Da wir Stylelint ja schon in den Editor integriert haben, können wir die Fehler auch direkt dort beheben. Hierzu klickt ihr auf einen unterstrichenen Fehler. Nach etwa einer Sekunde könnt ihr dann auf den Pfeil nach unten neben der roten Glühbirne klicken. Hier wählt ihr dann „Stylelint: Fix current file“ – das sollte alle behebbaren Fehler in der aktuellen Datei korrigieren:

Fazit

Es ist sehr wichtig, sich an Coding-Standards zu halten. Die richtigen Tools können euch dabei helfen und die Integration vieler dieser „Quality Tools“ durch PhpStorm macht es euch noch leichter. Ich würde mir nur wünschen, dass PhpStorm diese Tools auch automatisch erkennt und „pro Ordner“ anwendet, statt auf dem gesamten Projekt. Aber mir persönlich spart dieser kleine Konfigurationsschritt in der Programmierung und Behebung solcher Fehler viel Zeit ein.

Text zum „Datenschutz Richtlinien-Leitfaden“ für dein Theme oder Plugin hinzufügen

Mit WordPress 4.9.6 haben wir neue Datenschutz-Tools bekommen. Eines davon was der neue „Datenschutz Richtlinien-Leitfaden“. Hast du schon einmal von diesem Leitfaden gehört oder ihn sogar benutzt? Falls nicht, solltest du ihn dir mal auf deiner Seite ansehen. Du findest ihn unter „Einstellungen | Datenschutz“ und dann im Tab „Richtlinien-Leitfaden“.

Übersicht von Textschnipseln für deine Datenschutzerklärung

Wenn ihr eine WordPress-Seite betreibt und ein paar Plugins installiert habt, gibt es eventuell einige, die personenbezogene Daten speichern. Selbst das Theme könnte dies tun. In solchen Fällen zwingt euch die DSGVO und ähnliche Gesetze dazu, in eurer Datenschutzerklärung darüber zu informieren. Es kann aber schwer sein, zu wissen, welche Daten zu welchem Zweck erhoben werden. Themes und Plugins können aber Textschnipsel zur Verfügung stellen, die ihr dann einfach kopieren könnt.

Hinzufügen von Textschnipseln zum Datenschutz Richtlinien-Leitfaden für euer Plugin oder Theme

Falls ihr Themes oder Plugins entwickelt und personenbezogene Daten speichert, dann solltet ihr sicherstellen, dass ihr einen eigenen Text zu dieser speziellen Seite für euer Plugin oder Theme hinzufügt. Um euren eigenen Text hinzuzufügen, müsst ihr die Funktion wp_add_privacy_policy_content() aufrufen und einen Titel, sowie einen Text übergeben. Das könnte wie folgt aussehen:

function privacy_policy_demo_plugin_content() {
    $content = sprintf(
        '<p class="privacy-policy-tutorial">%1$s</p><strong class="privacy-policy-tutorial">%2$s</strong> %3$s',
        __( 'Privacy Policy Demo Plugin is using local Storage ...', 'privacy-policy-demo-plugin' ),
        __( 'Suggested text:', 'privacy-policy-demo-plugin' ),
        __( 'This website uses LocalStorage to save ...', 'privacy-policy-demo-plugin' )
    );
    wp_add_privacy_policy_content(
        __( 'Privacy Policy Demo Plugin', 'privacy-policy-demo-plugin' ),
        wp_kses_post( wpautop( $content, false ) )
    );
}
add_action( 'admin_init', 'privacy_policy_demo_plugin_content' );

Mit diesen Codeschnippsel in eurem Plugin oder Theme solltet ihr dann auf der Datenschutz Richtlinien-Leitfaden Seite diesen Text finden:

Der "Datenschutz Richtlinien-Leitfaden" mit unserem eigenen Text sowie einem Eintrag für "Twenty-Twenty-One" mit dem Hinweis "Gelöscht am 17. Dezember 2023".

Wie ihr in diesen Screenshot sehen könnt, gibt es hier verschiedene Textschnipsel. Ein Klick auf den Button „Den vorgeschlagenen Richtlinientext…“ kopiert lediglich den Text nach „Suggested text:“ (übersetzt „Textvorschlag:“) Überschrift. Es kann also sinnvoll sein, den Namen eures Themes oder Plugins im Text zu nennen.

Aktualisierungshinweis

Wie ihr ebenfalls sehen könnt, gibt es einen Textschnipsel für „Twenty Twenty-One“ mit dem Hinweis „Gelöscht am 17. Dezember 2023“. Jeder Text, der über diese Methode hinzugefügter Text wird „versioniert“. WordPress stellt dabei automatisch fest, ob sich der Text aktualisiert hat, oder ob, wie in diesem Beispiel, das Theme oder Plugin gelöscht oder deaktiviert wurde. Es ist also ein Hinweis an die Person, die die Seite betreibt, dass sie ihre Datenschutzerklärung aktualisieren sollte oder den alten Text entfernen kann.

Fazit

Obwohl es diese Funktion schon seit Mai 2018 gibt, haben sie viele noch nie entdeckt und/oder die Textschnipsel verwendet, die es hier zu finden gibt. Wenn ihr also, genau wie ich, diese Seite schon länger nicht mehr auf euren Websites besucht habt, dann ich jetzt vielleicht ein guter Zeitpunkt, dies Mal wieder zu tun, oder sie zum ersten Mal überhaupt zu besuchen.

Begrenzung der von Docker verwendeten Ressourcen

Ich Docker verwende Docker schon seit einigen Jahren für meine lokale Entwicklungsumgebung. Am Anfang habe ich noch selbst geschriebene Images verwendet, aber in letzter Zeit verwende ich hauptsächlich „Abstraktionen“ wie DDEV oder wp-env, insbesondere bei der Arbeit mit WordPress-Projekten. Meistens verwende ich hierbei Linux, aber ich habe auch ein Setup auf einem Windows-Dual-Boot-Rechner.

Mein früherer Linux-Arbeitslaptop war nur ein Core i5-7200U Dual-Core mit 16GB RAM. Da ich manchmal an verschiedenen Projekten gleichzeitig gearbeitet habe, war mein Rechner mit mehreren geöffneten PhpStorm-Instanzen und Chrome-Browser-Tabs ziemlich schnell an seiner Grenze. Bei der Überprüfung der Ressourcen wurde schnell klar, dass Docker das Problem war, weil es 50 % aller Ressourcen verwendet hat.

Messung der von Docker verwendeten Ressourcen

Verschiedene Betriebssysteme haben unterschiedliche Tools, um die Auslastung der laufenden Prozesse anzuzeigen. Wenn man herausfinden will, welcher Prozess wie viel verbrauchen, benutzt man diese auch normalerweise. Es gibt aber auch einen in Docker selbst eingebauten Befehl dazu: docker stats. Mit diesem Befehl erhalten ihr eine Ausgabe wie diese:

$ docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
NAME                                                 CPU %     MEM USAGE / LIMIT
34774832e449e0c5323d0c6eb5b88fdf-tests-cli-1         0.00%     628KiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-cli-1               0.00%     1.133MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-wordpress-1   0.01%     15.95MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-wordpress-1         0.00%     16.63MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-mysql-1       0.02%     180.4MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-mysql-1             0.02%     183.1MiB / 15.01GiB
ddev-router                                          0.82%     43.99MiB / 15.01GiB
ddev-theme-tests-web                                 0.03%     144.4MiB / 15.01GiB
ddev-theme-tests-db                                  0.11%     150.6MiB / 15.01GiB
ddev-ssh-agent                                       0.32%     5.805MiB / 15.01GiB
ddev-theme-tests-dba                                 0.01%     20.1MiB / 15.01GiB

Ändern der Ressourcen-Limit in WSL2

Dieses Beispiel stammt aus einem WSL2-Docker-Setup. Ihr könnt hier zwei Projekte mit ihren Containern sehen. Die Spalte „MEM USAGE“ zeigt euch auch das „LIMIT“ an, das alle Container maximale ausnutzen können. Auf dem hier gezeigten Rechner mit 32B RAM sind es 50% des verfügbaren Speichers.

Diese Begrenzung wird von WSL selbst festgelegt. Standardmäßig werden 50% des verfügbaren Arbeitsspeichers oder 8GB verwendet, je nachdem, welcher Wert kleiner ist. Bei älteren Builds (vor 20715) wurden jedoch bis zu 80% des Arbeitsspeichers beansprucht! Das kann selbst leistungsstarke Rechner schnell zum Absturz bringen.

Glücklicherweise ist es recht einfach, dies zu überschreiben. Dazu müsst ihr nur eine .wsconfig Datei im Home-Verzeichnis eures Benutzers (%UserProfile%) erstellen. Hier legen legt ihr dann die Datei mit dem folgenden Inhalt an:

[wsl2]
memory=8G

Anschließend müsst ihr WLS2 mit folgendem Befehl neu starten, was alle laufenden Distros herunterfährt. Stellt also sicher, dass dies in eurer Umgebung in Ordnung ist:

wsl --shutdown

Docker für Windows wird jetzt wahrscheinlich melden, dass Docker gestoppt wurde, und ihr können den „Restart“ Button klicken, um es neu zu starten. Wenn ihr jetzt erneut den Befehl docker stats ausführt, sollten ihr eine Speicherbegrenzung auf 8GB sehen. Es gibt noch weitere Einstellungen, die ihr in der .wslconfig Datei überschreiben könnt, wie z.B. die Anzahl der verwendeten Prozessoren. Da der virtuelle Server, auf dem dieses Blog gehostet wird, auch nur 4GB RAM hat, sind die 8GB, die ich hier definiert habe, immer noch sehr großzügig.

Begrenzung der Ressourcen in anderen Betriebssystemen

Ich benutze keinen Mac, daher kann ich euch nicht sagen, wie die Einstellungen dort geändert werden können. Und unter Linux gibt es viele verschiedene Möglichkeiten, das Gleiche zu erreichen. Es würde aber den Rahmen des Beitrags sprengen, alle verschiedenen Varianten aufzuzählen. Aber ich habe einen Tipp für diejenigen von euch, die Linux verwenden.

Begrenzung der Ressourcen pro Projekt

Anstatt die Ressourcen global zu begrenzen, können ihr sie pro Container oder für ein Projekt, das eine docker-compose.yml Datei verwendet, begrenzen. Bei der manuellen Ausführung eines Containers können ihr die Ressourcen an den Aufruf direkt übergeben. Aber mit einer docker-compose.yml Datei könnt ihr sie auch für einen einzelnen Dienst festlegen, wie in diesem Beispiel, wo ich die Datei für das wp-env Projekt angepasst habe:

version: '3.7'
services:
  mysql:
    image: mariadb
    deploy:
      resources:
        limits:
          memory: 2GB
# ...

Mit dem resources Key könnt ihr die Werte für jeden Dienst ändern. Mit dieser Änderung sehen die Statistiken dann wie folgt aus:

$ docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
NAME                                                 CPU %     MEM USAGE / LIMIT
34774832e449e0c5323d0c6eb5b88fdf-cli-1               0.00%     576KiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-wordpress-1         0.01%     15.87MiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-mysql-1             0.02%     177.6MiB / 2GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-cli-1         0.00%     2.664MiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-wordpress-1   0.00%     16.17MiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-mysql-1       0.03%     86.56MiB / 7.761GiB

Wie ihr sehen könnt, verwenden alle Dienste die zuvor definierten 8GB, aber der MySQL-Dienst ist jetzt auf 2GB begrenzt. Da der MySQL-Dienst in der Regel am meisten Speicher verbraucht, würde ich empfehlen, diesen Dienst zuerst zu begrenzen.

Fazit

Das hier ist kein Blogbeitrag darüber, wie man die Ressourcen für Docker-Container in allen Betriebssystemen und in allen möglichen Szenarien optimiert. Ich hoffe aber, dass er euch zeigen könnte, welche Möglichkeiten es gibt und euch dabei hilft, sie auf einem Rechner mit wenig Gesamtspeicher oder wenigen Prozessoren/Threads schnell zu begrenzen. Bei meinem alten Arbeitslaptop hat das wirklich geholfen, und ich konnte viel schneller arbeiten, da sich die anderen Prozesse nicht die verbleibenden 50% des Speichers unter sich aufteilen mussten.

Wie man den „-2“ Suffix von einer Seite entfernt

Wenn ihr diesen Blogbeitrag lest, dann hattet ihr vermutlich selbst schon einmal dieses Probem. Ihr versucht den Slug einer Seite (oder eines anderen Beitragstyps) zu ändern und WordPress hängt einen „-2“ Suffix an den Slug. Ihr sucht nach einer Seite mit diesem Slug, könnt sie aber nicht finden. Wo also kommt das Problem her?

Das Problem

Nehmen wir mal an, wir haben eine Website über Berlin und wollen eine Seite zum „Brandenburger Tor“ erstellen. Wir verwenden also diesen Titel und veröffentlichen die Seite. Aber anstelle der URL example.com/brandenburger-tor bekommen wir die URL example.com/brandenburger-tor-2, nur wieso?

Die Ursache: Medien-Dateien

Mit WordPress 6.4, das gerade veröffenticht wurde, sind die Anhangs-Seiten weggefallen. Aber nicht wirklich. Falls ihr diese nicht kennt: Anhangs-Seiten konnten im Frontend einer Seite aufgerufen werden und haben lediglich den Titel/Slug sowie die hochgeladene Datei angezeigt. In manchen Themes wurde sogar angezeigt, wer die Datei hochgeladen hat und wann. Mit WordPress 6.3 und TwentyTwenty sieht das wie folgt aus:

Wie ihr hier sehen könnt, gab es für die Anhang-Seite sogar die Möglichkeit Kommentare zu schreiben. Manche Websites mögen das verwendet haben, aber für die meisten war es wohl eher nutzlos.

Mit WordPress 6.4 werden diese Seiten nun „entfernt“. Wenn man deren URL aufruft, dann wird man stattdessen zur Medien-Datei weitergeleitet.

Aber diese Seiten wurden nicht wirklich entfernt. Sie sind nur nicht mehr aufrufbar. Sie existieren aber noch immer in der Datenbank und haben einen Titel/Slug. Wenn wir also nun ein Bild mit dem Dateinamen brandenburger-tor.jpg in die Mediathek hochladen, dann wird der Slug brandenburger-tor auch für Anhang-Seite verwendet, selbst wenn es für diese in WordPress 6.4 keine Frontend-Seiten mehr gibt.

Die Lösung: ändern des Slugs für die Anhang-Seite

Um nun also den Slug für unsere Seite „frei“ zu bekommen, müssen wir den Slug der Anhang-Seite ändern. Schauen wir uns also mal an, die das funktioniert.

Finden der Seite

Zuerst einmal suchen wir nach dem Anhang-Namen (oder direkt nach dem Slug):

Liste der Medien-Dateien zur Suchanfrage "brandenburger-tor" mit einem Bild als Ergebnis

Bearbeiten des Slugs für die Anhang-Seite

Wir klicken dann auf die Medien-Datei. Unten rechts finden wir Links zur Medien-Datei. Mit dem ersten Link könnt ihr euch die Anhang-Seite ansehen (das leitet euch mit WordPress 6.4 zur Medien-Datei weiter). Mit dem zweiten Link können wir „Weitere Details bearbeiten“:

Das "Anhang-Details" Popup mit dem "Weitere Details bearbeiten" Link hervorgehoben

Das öffnet die „Date bearbeiten“ Ansicht, auf der ihr den Permalink zum Bild sehen könnt:

Die "Datei berabeiten" Ansicht mit dem "Permalink" ganz oben

In älteren Versionen von WordPress gab es hier einen „Bearbeiten“ Button daneben, aber diesen gibt es nicht mehr. Stattdessen müsst ihr das „Titelform“ Bildschirm-Element (Meta-Box) aktivieren, dass ihr vermutlich erst über „Ansicht anpassen“ oben „aktivieren“ müsst:

Die "Ansicht anpassen" Ansicht mit demaktivierten "Titelform" Bildschirm-Element

Nun könnt ihr ans Ende des Seite scrollen und dort in der Meta-Box den Slug für die Anhang-Seite ändern. Ihr könntet hier zum Beispiel einfach „-anhang-seite“ als Suffix anhängen:

Meta-Box für Titelform/Slug mit dem „AKtualisieren“ Button darüber

Nach der Änderung des Slugs klick ihr auf den „Aktualisieren“ Button.

Ändern des Slugs für die Seite

Jetzt könnt ihr endlich zur Seite zurücknavigieren und den Slug anpassen. WordPress sollte nun nicht mehr den „-2“ Suffix an den Permalink anhängen.

Bonus: verwenden der WP-CLI

Falls ihr die WP-CLI verwendet, könnt ihr den Slug der Anhang-Seite auch mit dem wp post update Befehl aktualisieren.

Hierzu müsst ihr erst einmal die ID zur Seite finden. Entweder findet ihr diese beim Hover über den „Weitere Details bearbeiten“ Link, ihr könnt sie aber auch mit der WP-CLI selbst finden:

$ wp post list --post_type=attachment
+----+-------------------+-------------------+---------------------+-------------+
| ID | post_title        | post_name         | post_date           | post_status |
+----+-------------------+-------------------+---------------------+-------------+
| 35 | brandenburger-tor | brandenburger-tor | 2023-11-19 16:09:23 | inherit     |
+----+-------------------+-------------------+---------------------+-------------+

Mit der ID könnt ihr dann den Slug wie folgt aktualisieren:

$ wp post update 35 --post_name=brandenburger-tor-anhang-seite
Success: Updated post 35.

Fazit

Eine Seite mit einem „-2“ Suffix ist wirklich nervig. Und wenn ihr eure Medien-Dateien ähnlich wie eure Seiten benennt, und diese vor der Erstellung der Seite in die Mediathek hochladet, dann bekommt ihr eventuell dieses Problem.

Mein Rat wäre es daher entweder erst die Seite anzulegen, bevor ihr die Medien-Dateien hochladet, oder noch besser, den Medien-Dateien bessere (längere) beschreibende Dateinamen zu geben, bevor ihr diese in die Mediathek hochladet.

Falls ihr das Problem aber dennoch habt, dann wisst ihr nun hoffentlich, wie ihr es manuell lösen könnt.