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:

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

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.

Das erste „offizielle“ WordCamp Deutschland in Gerolstein

Vor zwei Wochen bin ich in die kleine Stadt Gerolstein gefahren, um am ersten „WordCamp Deutschland“ teilzunehmen. Moment mal, das erste WordCamp Deutschland? Waren da nicht schon welche?

Die Geschichte deutscher WordCamps

Das erste WordCamp in Deutschland, war 2008 in Hamburg. Es war sogar das erste WordCamp in Europa! Aber damals waren es keine „offiziellen“ WordCamps, wie wir sie heute haben, mit Unterstützung von WordPress Foundation / WordPress Community Support.

Ein Jahr später gab es das zweite WordCamp in Jena, an dem auch ein Gast aus den USA teilgenommen und eine State of the Word Rede gehalten hat.

Es ging weite 2010 in Berlin, mein erstes WordCamp, sowie 2011 in Köln. Auch wenn diese WordCamp Deutschland genannt wurden, waren sie noch immer unabhängig organisiert. In den folgenden beiden Jahren hatten wir dann die beiden WP Camps. Die Geschichte hinter dem anderen Namen ist eine lange, die auch der Communtiy nur schwer erklärt werden konnte.

2014 hatten wir dann endlich das erste „offizielle“ WordCamp in Deutschland, welches wieder in Hamburg stattfand. Aber es war ein „Städte-WordCamp“. Alle folgenden WordCamps waren ebenfalls nach den jeweiligen Städten benannt. Deshalb hatten wir dieses Jahr das „erste offizielle regionale WordCamp“.

Mittwoch: Pluginkollektiv Hackathon

Am Tag vor dem WordCamp gab es ein kleines Seiten-Event: den Pluginkollektiv Hackathon. Diese Gruppe von Freiwilligen kümmert sich um einige bekannte und weit verbreitete Plugins, besonders in der deutschen und europäischen Community.

Wir haben einige Plugins getestet, an neuen Versionen gearbeitet, aber auch viel über die Zukunft des Pluginkollektivs und einiger Plugins diskutiert. Einige übernommene Plugins wurden bereits geschlossen und für einige neue haben wir ebenfalls die schwere Entscheidung getroffen, diese zu schließen.

Donnerstag: Contributor Day

Der Tag vor den Konferenztagen war wieder für den Contributor Day reserviert. Ich habe als Table-Lead für das Meta-Team teilgenommen. Drei neue Contributoren haben sich mir anschlossen und wir haben an verschiedenen Tickets gearbeitet. Ich habe an einem WordCamp.org Ticket weitergearbeitet, die anderen an WordPress.tv Tickets. Eines davon war ein 8 Jahre altes Ticket zur Schriftgröße, aber wir haben auch drei neue Tickets erstellt.

Nach dem Contributor Day gab es ein kleines Abendessen mit allen, die beim Event mithelfen. Im Anschluss gab es dann die „Eröffnungsparty“.

Freitag: Der erste Konferenztag

Nach der Eröffnung habe ich die Gelegenheit genutzt, einige Teilnehmende zu treffen, die ich schon seit Jahren nicht mehr gesehen habe, oder noch nie persönlich treffen konnte.

WooCommerce Blocks: Ein aktueller Blick auf die neuen Blöcke für Produktseiten, Cart und Checkout

Dies war der erste von drei Lightning-Talks. Obwohl ich das Thema E-Commerce nicht wirklich mag, was der Vortrag von Manja Neumann wirklich toll! Sie hat gezeigt, was mit den neuen Blöcken möglicht ist. Ich mag wirklich die große Flexibilität, die Elemente auf den WooCommerce Seiten für den Warenkorb und den Abschluss der Bestellung zu arrangieren. Falls ich doch mal wieder mit WooCommerce arbeiten muss, freue ich mich schon, die neuen Blöcke mal anzuprobieren.

Ein-Klick-Entwicklungsumgebung mit GitHub Codespaces

Ich habe schon häufiger den Projektnamen „GitHub Codespaces“ gehört, aber nicht richtig verstanden, was diese sind. Nach diesem Vortrag von Thomas Rose kann ich es gar nicht abwarten sie mal in einem meiner Projekte zu probieren.

State of TV – Vortragsaufzeichnung, aktueller Stand und Ausblick

Der letzte Lightning-Talk, gehalten von Frank Neumann-Staude, drehte sich um die aktuelle Technik, die für die Aufzeichungen alles Sessions auf deutschen WordCamps verwendet wird. Wie ich vielleicht festgestellt habt, sind alle Titel der Sessions zu den entsprechenden Videos verlinkt. Das ist möglich, da alle Videos bereits in der Nacht nach dem letzten WordCamp Tag bereits hochgeladen waren. Das ist nur möglich gewesen, weil wir ein so tollen TV Team haben!

Digitale Barrierefreiheit fürs Kognitive Spektrum

Ich habe schon viele Vorträge von Maja Benke zum Thema Barrierefreiheit gesehen. Aber dieser war ein außergewöhnlicher. Es hat sich nicht auf die typischen Themen wie Kontrast und Schriftgröße fokussiert. Stattdessen ging es um „Menschen in einem Spektrum“ und was es für diese Menschen bedeutet, wenn es um barrierefreie Websites geht.

Empowering women through code: unleashing the power of diversity in tech

In der nächsten Lightning-Talk-Runde konnte ich mir nur den Talk von Tabea Braun zum Groundbreaker Talents Stipendien-Programm ansehen, das Frauen aus unterprivilegierten Gemeinschaften in Uganda befähigt, Software Engineers zu werden.

Das war auch der letzte Talk, den ich mir angesehen habe. Den Rest des Tages habe ich mir mehr Teilnehmenden und Sponsoren gesprochen.

Samstag: Der zweite Konferenztag

Auch der Zeitplan des zweiten Konferenztages war wieder vollgepackt mit einer weiteren Runde toller Vorträge!

WordPress-Login-Security

Selbst wenn man denkt, dass man schon alles zu einem Thema weiß, lernt man immer wieder etwas Neues! Die Session von Angelo Cali und Simon Kraft war hier keine Ausnahme. Während die „Basics“ noch bekannt waren, fand ich den Teil über Passkeys sehr faszinierend. Ich habe die Sicherheit dahinter noch nicht komplett verstanden, aber es sieht nach einer modernen Alternative zu Passwörtern aus, die man sich auf jeden Fall ansehen sollte.

Meta-Meetup für WordPress-Meetup-Organisator*Innen

Nach einer kleinen Pause und der Mittagspause habe ich mich dann mit anderen Meetup-Organizern im Workshop-Raum getroffen. Wir haben unsere Erfahrungen geteilt und Ideen rund um die Meetup in der deutschsprachigen Community ausgetauscht. Das Berliner Meetup ist noch immer nur online, wir hoffen aber, dass wir uns bereits im nächsten Jahr wieder vor Ort treffen können.

Nach dieser Session wurde ich für einen Podcast interviewt.

Exploring the power of generative styling

Als Nächstes habe ich mir dann den Vortrag meiner Kollegin Tammie Lister angesehen. Ich kann gar nicht richtig zusammenfassen, worum es ging. Daher kann ich nur allen empfehlen, sich das Video anzusehen!

Das war auch schon der letzte Talk für mich auf diesem WordCamp. Danach brauchte ich erst einmal eine kleine Pause, um Energie für den letzten Teil des WordCamps zu tanken: die After-Party! Ich hatte sogar die Chance ein wenig Kizomba und Salsa zu tanzen 😀

Fazit

Das „erste“ WordCamp Deutschland war ein riesiger Erfolg! Wenn man bedenkt, wie schwer es war nach Gerolstein anzureisen, waren etwa 240 Personen vor Ort. Das ist eine normale Zahl für ein „großes“ deutsches WordCamp und nicht selbstverständlich für das erste Event nach der Pandemie.

Wir wissen noch nicht, wo da nächste WordCamp in Deutschland stattfinden wird – vielleicht ja in München, was dieses ja nicht möglich war, da das Team keinen bezahlbaren Veranstaltungsort finden konnte. Ich weiß nur, dass ich wieder dabei sein werde, wie schon bei allen anderen WordCamps in Deutschland seit 2010.

Erstellen eines Super-Administrators und Zuweisung zu allen Seiten einer Multisite mit der WP-CLI

Vor zwei Wochen habe ich angefangen, an einem neuen Projekt zu arbeiten. Die gesamte WordPress Website was in Git versioniert, inklusive einer DDEV-Konfiguration und einem SQL-Dump für die lokale Entwicklung. Das war toll, denn damit konnte ich sehr schnell starten. Aber nach der Installation konnte ich keine Logindaten finden.

Auslesen aller Benutzer der Installation

Die gewöhnlichen „admin“ oder „wordpress“ Benutzer haben nicht existiert. Daher habe ich mir erst einmal eine Liste der verfügbaren Benutzer per WP-CLI geholt:

$ wp user list
+----+------------+--------------+------------------------+---------------------+---------------+
| ID | user_login | display_name | user_email             | user_registered     | roles         |
+----+------------+--------------+------------------------+---------------------+---------------+
| 11 | jo         | jo           | jo@example.com         | 2023-06-01 01:30:30 | administrator |
| 22 | jane       | jane         | jane@example.com       | 2023-06-02 02:30:30 | administrator |
| 33 | john       | john         | john@example.com       | 2023-06-03 03:30:30 | administrator |
+----+------------+--------------+------------------------+---------------------+---------------+

Für keinen dieser User (Namen wurden geändert) konnte ich Zugangsdaten finden. Daher musste ich mir dann erst einmal einen neuen Benutzer anlegen.

Erstellen eines Administrator-Benutzers

Ich verwende normalerweise den --prompt Parameter, wenn ich einen neuen Benutzer (oder andere Einträge) erstelle, damit ich keinen wichtigen Parameter vergesse:

$ wp user create --prompt
1/15 <user-login>: wapuu
2/15 <user-email>: wapuu@example.com
3/15 [--role=<role>]: administrator
4/15 [--user_pass=<password>]: wordpress
5/15 [--user_registered=<yyyy-mm-dd-hh-ii-ss>]: 
6/15 [--display_name=<name>]: 
7/15 [--user_nicename=<nice_name>]: 
8/15 [--user_url=<url>]: 
9/15 [--nickname=<nickname>]: 
10/15 [--first_name=<first_name>]: 
11/15 [--last_name=<last_name>]: 
12/15 [--description=<description>]: 
13/15 [--rich_editing=<rich_editing>]: 
14/15 [--send-email] (Y/n): n
15/15 [--porcelain] (Y/n): 
wp user create --role='administrator' --user_pass='wordpress'
Success: Created user 44.

Jetzt war ich endlich in der Lage, mich an der Seite anzumelden! Aber direkt nach dem Login fiel mir dann auf, dass es sich um eine Multisite-Installation handelte. Ich konnte also mit meinem schönen neuen Administrator-Benutzer die anderen Seiten nicht sehen.

Einen Benutzer zu einem Super-Administrator machen

Mit der WP-CLI kann man mit einem einzigen Befehl einen Benutzer zu einem Super-Administrator ernennen:

$ wp super-admin add 44
Success: Granted super-admin capabilities to 1 user.

Nach der Ausführung des Befehls konnte ich in der „Netzwerkverwaltung“ alle Seiten sehen. Ich hätte auch mit allen arbeiten können. Aber da mein neuer Account nicht direkt mit den Seiten verknüpft war, wurden sie nicht im „Meine Websites“ Dropdown in der Adminbar angezeigt.

Hinzufügen eines Benutzers als Administrators zu allen Seiten

Auf dieser spezifischen Multisite gab es nur drei Seiten. Das Hinzufügen eines Benutzers als Administrators ist also eine schnell zu erledigende Aufgabe. Aber wie sähe es bei einem Netzwerk mit 100 Seiten aus? Das würde wohl recht lange dauern und man könnte eine Seite vergessen. Glücklicherweise gibt es auch hierfür einen WP-CLI-Befehl, der dies lösen kann.

Auflisten aller Seiten

Zuerst einmal benötigen wir die Liste aller Seiten. Hierzu kann der folgende Befehl verwendet werden:

$ wp site list
+---------+---------------------------+---------------------+---------------------+
| blog_id | url                       | last_updated        | registered          |
+---------+---------------------------+---------------------+---------------------+
| 1       | https://example.com/      | 2023-06-01 01:30:30 | 2023-06-01 01:30:30 |
| 2       | https://example.com/de/   | 2023-06-02 02:30:30 | 2023-06-02 02:30:30 |
| 3       | https://example.com/en/   | 2023-06-03 03:30:30 | 2023-06-03 03:30:30 |
+---------+---------------------------+---------------------+---------------------+

Um einen neuen Benutzer diesen Seiten mit einer spezifischen Rolle zuzuweisen, können wir diesen Befehl verwenden:

$ wp user set-role 44 administrator --url=https://example.com/de/
Success: Added wapuu (44) to https://example.com/de as administrator.

Das müssten wir nun aber für jede einzelne Seite wiederholen und jeweils das url Feld verwenden. Aber bei vielen Seiten würde auch das sehr lange dauern und es könnten Fehler gemacht werden. Daher wollte ich einen Befehl haben, der das in einem Einzeiler löst.

Hinzufügen eines Administrators zu allen Seiten

Ich bin nicht der beste Shell-Entwickler, aber nach ein wenig ausprobieren habe ich den folgenden Befehl gefunden:

$ wp site list --field=url | xargs -I {} wp user set-role wapuu administrator --url={}
Success: Added wapuu (44) to https://example.com as administrator.
Success: Added wapuu (44) to https://example.com/de as administrator.
Success: Added wapuu (44) to https://example.com/en as administrator.

Mit diesem Befehl wird zuerst die Liste aller Seiten abgefragt, genau wie zuvor gezeigt. Für jede Seite wird davon nur das url Feld per xargs an den zweiten Befehl weitergegeben, der dann den Benutzer der Seite hinzufügt. Ihr müsst natürlich den richtigen Benutzernamen (hier im Beispiel wapuu) im zweiten Befehl angeben.

Fazit

Mit ein wenig WP-CLI-Magie kann man sehr schnell einen Administrator Benutzer erstellen, diesem Super-Administrator Rechte geben und ihn mit jeder Seite einer Multisite verknüpfen. Ich hoffe, dass das auch für euch in einem (zukünftigen) Multisite-Projekt von Nutzen sein kann.

WordCamp Nederland 2023 – Mein fünfzigstes WordCamp

Vor zwei Wochen habe ich mein erstes niederländisches WordCamp besucht. Es was aber nicht mein erstes WordCamp in den Niederlanden, das war das erste WordCamp Europe 2013. Es war aber mein erstes „echte“ niederländische WordCamp, organisiert durch die lokale Community.

Wie schon im letzten Jahr fand das WordCamp im Burgers’ Zoo in Arnhem statt. Ich war als Volunteer dabei, was ich auch schon eine ganz Weile nicht mehr getan habe – wenn man die Organisation von WordCamps nicht als Volunteering zählt 😉 Am Abend gab es eine Tour durch den Park, die ich leider verpasst habe. Ich habe aber am „Speakers Dinner“ am Donnerstagabend teilgenommen.

Freitag: Der erste Konferenztag

Das WordCamp war ein zweitägiges Event mit Vorträgen und Workshops. Es gab keinen Contributor Day. Meine erste Schicht am Freitag als Volunteer war an der Registrierung. Zum Glück waren viele dafür eingeteilt, denn ich hatte oft Probleme, die Aussprache und Schreibweise von niederländischen Namen hinzubekommen 😀

Performance Awareness and Optimization

Nachdem der erste Ansturm von Teilnehmenden vorbei war, hatte ich etwas Zeit, mir den Vortrag meines Kollegen Thorsten Frommen anzusehen. Es hat einige sehr tiefgreifende Einblicke in die Code-Performance gegeben. Der Vortrag hat sich klar an ein erfahreneres Publikum gerichtet und auch ich konnte noch einige neue Dinge lernen:

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

Dies war auch der einzige Vortrag, den ich mir an dem Tag angesehen habe. Die restliche Zeit habe ich viel mit Leuten gesprochen, die ich schon kannte, aber auch mit einigen anderen Volunteers, sowie mit Sponsoren.

Am Abend gab es in der Altstadt von Arnheim noch ein kleines Event, organisiert von einem Sponsor.

Samstag: Der zweite Konferenztag

Am zweiten Tag hatten wir nur noch den größeren Raum für Vorträge sowie die beiden „Lodges“, an denen am ersten Tag ebenfalls Vorträge und Workshops stattfanden, zur Verfügung. Ich hatte aber erst einmal wieder eine Schicht an der Registrierung. Da aber die meisten Teilnehmenden schon am ersten Tag angekommen waren, hatte ich nicht zu viel zu tun.

Your Code Can Be Poetry Too

Das gab mir die Gelegenheit, mir den Vortrag von Juliette Reinders Folmer anzusehen. Sie hat über die WordPress Coding Standard im Allgemeinen gesprochen, aber auch erzählt, was für eine riesige Aufgabe es war, die neue Version 3 des WordPressCS Tools zu veröffentlichen. Sie hat auch erklärt, wieso Open-Source-Projekte wie dieses ohne bessere finanzielle Unterstützung nicht nachhaltig weiterentwickelt werden können:

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

Nach diesem Vortrag ging es erst einmal wieder zurück an die Registrierung. Daher habe ich leider den Vortrag „Bytes and Minds: Navigating Mental Health in the Tech World“ von Ryan Hellyer, einem Community-Mitglied aus Berlin, verpasst. Ich habe viel Gutes über den Vortrag gehört und konnte nach dem WordCamp auch ein wenig mit Ryan darüber sprechen. Ich muss ihn mir auf jeden Fall ansehen, sobald er bei wordpress.tv verfügbar ist – hoffentlich sehr bald!

Nach dem Mittagessen habe ich mich der inoffiziellen Session „Zoo Time“ angeschlossen. Zusammen mit anderen Teilnehmenden habe ich mit 2 Stunden lang den Zoo angesehen – da das WordCamp innerhalb des Zoos stattfand, war auch der Eintritt zum Zoo im Ticket enthalten.

Am Abend haben sich einige Teilnehmende noch im Stadtzentrum zum Ausklang getroffen.

Fazit

Das WordCamp war wirklich toll! Es war mein „erstes echtes niederländisches WordCamp“. Aber wie ich auch schon im Titel geschrieben habe, was es gleichzeitig mein 50. WordCamp „vor Ort“. Ich werde zu all meinen WordCamps aber noch einen eigenen Blogbeitrag schreiben, inkl. einiges schöner Statistiken.

WordCamp US 2023 – und meine erste Reise in die Hauptstadt

Letzte Woche war ich in Washington DC, um am WordCamp US teilzunehmen. Dies war das dritte Mal, dass ich das WCUS besucht habe. Es war auch meine erste Reise zurück in die USA seit 2017 und mein erster Besuch in der Hauptstadt der Vereinigten Staaten.

Besuchen von Washington DC

Meine Reise begann am Montagnachmittag. Der Flug hatte bei seiner Ankunft in Berlin schon eine Stunde Verspätung. Nach der Landung am Dulles Airport wurde ich von einer riesigen Warteschlange bei der Grenzkontrolle begrüßt. Nach etwa 90 Minuten hatte ich es dann endlich in die USA geschafft.

Ich habe mich direkt auf den Weg zum Hotel gemacht, dort eingecheckt und mir Tickets für das NFL-Spiel Ravens @ Commanders gekauft – mein erstes NFL-Spiel in den USA.

Etwas Sightseeing in Washington

Nach einem sehr langen Tag, etwas erholsamem Schlaf und einem typisch amerikanischen Frühstück habe ich dann erst einmal versucht, eine Touristen-SIM-Karte zu bekommen, was in den USA nicht ganz so einfach ist. Danach bin ich erst einmal in die Stadt gefahren, um mir einige Sehenswürdigkeiten anzusehen. Der erste Stopp war natürlich das Weiße Haus. Ich habe den Tag dann mit einem Besuch des westlichen Teils der National Mall beendet.

Am Mittwoch habe ich meine Tour der National Mall fortgesetzt. Ich habe am Washington Monument angefangen, aber leider konnte ich keine Tickets für den Aufstieg bekommen (für die gesamte Woche). Stattdessen habe ich dann das National Museum of African American History and Culture besucht. Das Museum ist recht neu und zeigt auf seinen Etagen viele faszinierende Dinge, aber auch ziemlich emotionale Geschichten. Ich war drei Stunden im Museum, hätte aber ohne Probleme drei Tage darin verbringen können, und hätte auch dann noch nicht alles gesehen.

Am Abend bin ich dann nach National Harbor gefahren, wo das WordCamp US stattfinden würde, und wo ich die nächsten vier Tage verbringen würde.

Der Contributor Day

Der Donnerstag war für den Contributor Day reserviert. Ich habe mich erneut dem Meta-Tisch angeschlossen, um an einem WordCamp.org Ticket zu arbeiten, mit dem ich schon seit Februar bei WCAsia beschäftigt bin. Da die Personen, die an dem Ticket beteiligt waren, auch bei WordCamp US waren, konnte ich einige Fortschritte erzielen. Aber ich habe auch einige neue Probleme entdeckt und einen neuen Pull Request eingereicht.

Nach dem Mittagessen habe ich dabei geholfen, einen Linux-Laptop wiederherzustellen. Beim Versuch, das Gutenberg-Repository zu installieren, waren die Berechtigungen des Dateisystems „zerstört“ worden.

Ich habe auch etwas über „wp-now“ gelernt. Es verwendet WP Playground und ist die neue Methode, um zu WordPress (und seinen Plugins) beizutragen.

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

Die Konferenztage

Der Zeitplan war dieses Jahr ziemlich anders. Es gab drei Tracks, aber die erste und letzte Session jeden Tages war eine Keynote. Normalerweise gibt es nur eine Keynote am Ende des WordCamps, gehalten von Matt.

Auch die Aufteilung des Veranstaltungsortes war etwas kompliziert. Die Session-Räume waren alle sehr nah beieinander, aber der Sponsoren-Bereich war in einem anderen Teil des riesigen Gebäudes. Man ist sicher gute 3 Minuten von einer Session zu den Sponsoren gelaufen.

For All Userkind: NASA Web Modernization and WordPress

Die erste Keynote wurde von zwei Mitgliedern des Teams gehalten, das für die Neugestaltung der NASA-Website verantwortlich ist. Sie haben darüber berichtet, wie sie die vielen verschiedenen Einzelseiten in eine neue vereinheitlichte WordPress-Website migrieren. Für die Hauptseite nasa.gov verwenden sie aktuell noch Drupal 7 (eine Version, die erstmals 2011 veröffentlicht wurde und im Januar 2025 ihr Ende erreicht). Die NASA hatte schon seit 1994 eine Website und verwendet seit 2015 Drupal.

Es wird also höchste Zeit für einen Neuanfang. Auf beta.nasa.gov kann man sich die neue Website schon ansehen. Sie wurde mit vielen eigenen Gutenberg-Blöcken und Patterns erstellt, die sie mit ihrem Team entwickelt haben. Bisher haben sie 440 Benutzer in das neue WordPress-CMS aufgenommen, 3.023 neue Landing-Pages erstellt und 68.006 Seiten aus dem alten CMS migriert. Aber das ist immer noch nur ein Bruchteil aller Inhalte, die sie auf rund 130 verschiedenen Websites haben. Ich kann euch nur empfehlen, euch die Aufzeichnung dieser faszinierenden Session anzusehen. Es gab eine Folgesession, die ich aber selbst nicht gesehen habe.

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

So, You Pledged to Contribute to WordPress: What Next?

Nach dem Mittagessen habe ich mir ein Panel angesehen, bei der meine Kollegin Tammi auf der Bühne war. Zusammen mit Femy Praseeth, Jonathan Desrosiers und dem Host Hari Shanker haben sie alle ihre Erfahrungen als WordPress-Contributors geteilt und einige Tipps gegeben, wie man als Contributor starten kann. Einige von ihnen werden für ihre Beiträge gesponsert, wie Tammi von meinem Arbeitgeber Inpsyde, und dadurch haben die Teilnehmenden einen ersten Einblick darüber erhalten, wie man aktiver zum Projekt beitragen kann.

Inpsyde hat auch das Five for the Future Profil mit den aktuellen „Zusagen“ erstellt, einschließlich der 5 Stunden, die ich aktuell beitrage. In Zukunft werde ich wahrscheinlich noch mehr Zeit beitragen können, aber dazu vermutlich später in diesem Jahr in einem eigenen Blogbeitrag.

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

All the President’s Websites

Nach einer kurzen Pause gab es eine weitere Sitzung über ein Regierungsprojekt, das von Helen Hou-Sandí und Andrew Nacin präsentiert wurde. Diejenigen von uns, die an Kundenprojekten gearbeitet haben, kennen Fristen und die Schwierigkeiten damit, diese auch einzuhalten. Es gibt viele Dinge, die schiefgehen können, und am Ende dauert es länger. Aber wie Nacin scherzhaft sagte, entschieden „die Gründungsväter“ der Vereinigten Staaten bereits 1776, dass eine neue Website am 20. Januar um 12 Uhr mittags live gehen muss 😀

Das macht die Sache umso schwieriger. Die neue whitehouse.gov Website für die Biden-Regierung wurde mithilfe der WordPress-Agentur 10up erstellt, bei der Helen zu der Zeit arbeitete. Der Designer Ben Ostrower hat das gesamte Branding in nur etwa 72 Stunden erstellt. Für das Projekt hatte das Team von nur 10 Personen insgesamt gerade einmal 6 Wochen Zeit, um es fertigzustellen. Das ist nicht viel Zeit, wie viele von uns wissen. Glücklicherweise mussten sie sich nicht zu sehr um den Website-Inhalt kümmern, da die neue Administration ein Team hat, das eine Menge Inhalte produziert.

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

Auch in diesem Projekt wurden eigene Blöcke für den Inhalt intensiv genutzt. Helen zeigte einige Videos von der „Editing Experience“. Das Backend hatte fast eine pixelgenaue Vorschau der Seite im Frontend, sodass das Content-Team das endgültige Aussehen jeder Seite ziemlich genau erstellen konnte. Und das alles lange bevor das Full-Site-Editing eingeführt wurde.

Es war wirklich eine beeindruckende Präsentation darüber, was mit WordPress in kurzer Zeit, mit einem erfahrenen Team und einem Kunden erreicht werden kann, der eng und aktiv mit dem Entwicklungsteam zusammenarbeitet.

BlackPress: Amplifying Black Professionals in WordPress

Am zweiten Tag habe ich mir ein weiteres Panel mit Ray Mitchell, Maestro Stevens, Destiny Kanno, George H. Woodard III angesehen. Sie haben das BlackPress-Projekt vorgestellt, eine Community für schwarze WordPress-Profis und Verbündete, mit dem Ziel, sie zu vernetzen und zu unterstützen.

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

Die Panelisten haben ihre individuellen Geschichten und Karrierewege als Eigentümer von Agenturen, Mitarbeiterin und gesponsorte Contributorin von Automattic oder Berater und WordPress-Entwickler geteilt.

Ich hatte zuvor nocht nicht von dieser Initiative gehört, aber es war inspirierend, den Geschichten aller Panelisten zuzuhören. Das sind die Arten von Sessions, die ich gerne auf WordCamps sehe.

Die Abschlusskeynotes

Josepha Haden Chomphosy hat einen kurzen 15-minütigen Vortrag über die Zukunft von WordPress gehalten, einschließlich Themen aus der Community wie den neuen Veranstaltungsformaten und einer kurzen Zusammenfassung des Community-Summits, der an den beiden Tagen vor WCUS stattfand. Zwei meiner Kolleginnen und ein Kollege haben daran teilgenommen.

Diese Keynote folge dann Gutenberg: Next, die Keynote von Matt. Er hat ein Video von der WordPress 6.3-Veröffentlichung gezeigt und über die Dinge gesprochen, die wir in WordPress 6.4 erwarten können, wie etwa das neue Standard-Theme Twenty Twenty-Four. Die Entwicklung dieses neuen Themes wird unter anderem von Jessica Lyschik aus der deutschen Community im Women & Nonbinary Release Squad geleitet.

Die Q&A nach diesen beiden Keynotes waren dieses Mal anders gestaltet, da mehrere Community-Mitglieder eine Änderung des Formats für das Stellen von Fragen gefordert hatten. Die Fragen konnten über Slido gestellt werden. Jede Frage musste vom Organisations-Team genehmigt werden. Nach der Genehmigung konnten alle Teilnehmenden über diese Fragen abstimmen. Die Fragen mit den meisten Stimmen wurden von Josepha und Matt beantwortet.

Nach dem Q&A wurde das Organisations-Team des WordCamp US auf die Bühne gebeten. Sie haben allen gedankt, die geholfen haben, das diesjährige WCUS möglich zu machen. Leider haben sie nicht bekannt gegeben, wo und wann das WCUS im nächsten Jahr stattfinden wird.

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

Die After Party

Der Tradition folgend fand die After-Party in einem Museum statt. Nach einem netten Abendessen mit den anderen Inpsydern haben wir uns auf den Weg zum Smithsonian Museum of Natural History in Washington DC gemacht. In der Rotunde wurden einige Desserts und alkoholfreie Getränke serviert. Wenn ich gerade nicht mit anderen Teilnehmenden gesprochen habe, konnte ich durch die Ocean, Mammal, Fossil und Geology Hallen schlendern. Das Museum hat beeindruckende Ausstellungsstücke. Aber da die Party nur drei Stunden ging, hatte man keine Chance auch nur annähernd alles zu sehen.

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

Ein paar weitere Tage in der DMV-Region

Am Sonntag habe ich einige Freunde in Annapolis besucht, die ich seit vielen Jahren nicht mehr gesehen habe. Es war eine tolle Möglichkeit, mich nach all den Eindrücken von der Veranstaltung etwas zu entspannen.

Ich hatte auch das Glück, am Montag eine Tour im Capitol zu bekommen. Nach der Tour konnte ich auch die Galerien von House und Senate besichtigen, da beide Kammern noch Sommerpause hatten. Den Rest des Tages habe ich im National Air and Space Museum verbracht, einem weiteren Smithsonian-Museum. Obwohl etwa die Hälfte des Museums wegen Renovierung geschlossen war, gabe dennoch einige sehr interessante Dinge zu sehen. Von Ausstellungen über „The Wright Brothers & The Invention of the Aerial Age“ bis hin zu „Destination Moon“, in der einige von der NASA für ihre Mondmissionen verwendeten Ausrüstungen gezeigt wurden. Dies hat einen perfekten Kreis zur ersten Keynote des WordCamps geschlossen.

Dienstag war mein letzter Tag. Ich bin erst einmal zum Flughafen gefahren, um mein Gepäck abzugeben. Danach habe ich das Steven F. Udvar-Hazy Center, den zweiten Standort des National Air and Space Museums besucht. Am meisten war ich vom Space Shuttle Discovery beeindruckt, ebenso wie von anderen historischen Ausstellungsstücken zur bemannten Raumfahrt. Weitere beeindruckende Objekte waren ein Lockheed SR-71 Blackbird oder die Boeing B-29 Superfortress „Enola Gay“, die die erste Atombombe auf Hiroshima abgeworfen hat. Leider war es anders als in ähnlichen Museen in Deutschland nicht möglich, einige Flugzeuge von innen zu sehen. Aber es war trotzdem eine beeindruckende Sammlung.

Ich hatte auch nur etwa eine Stunde Zeit, bevor ich zurück zum Flughafen gefahren bin, um genug Zeit für die Sicherheitskontrolle zu haben – die dann aber nur etwa 3 Minuten gedauert hat! So hatte ich genug Zeit, mich auf den Rückflug vorzubereiten.

Insgesamt habe ich die Reise zu einem weiteren WordCamp US wirklich genossen. Ich freue mich schon darauf zu erfahren, wo es nächstes Jahr stattfinden wird, um dann zu entscheiden, ob ich noch einmal teilnehmen werde.