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:

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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:

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

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.

Migrieren der Mediathek von einer Seite zu einer anderen

Beim letzten WP Meetup Potsdam, einem gemütlich Treffen bei Essen, Trinken und netten Gesprächen, hat eine neue Teilnehmende eine einfach klingende Frage gestellt, zu der wir aber verschiedene Antworten hatten:

Wie kann ich alle Bilder von einer WordPress Seite zu einer andere migrieren?

Verschiedene Teilnehmende kamen auf verschiedene Lösungen. Hier sind die, über die wir diskutiert haben.

Migration der Bilder mit FTP

Viele, die mit Website arbeiten, verwenden auch FTP zum Upload/Download von Dateien zu einem Server. Wieso also nicht einfach alle Bilder von der Ursprungsseite herunterladen und in den wp-content/uploads Ordner der neuen Seite hochladen.

Alle, die wissen, wie WordPress mit Anhängen (Bildern und anderen Dateien) umgeht, wird vermutlich wissen, dass, dass die Datei alleine nicht ausreicht. Es muss auch ein Eintrag in der Datenbank vorhanden sein. Ansonsten kann man die Bilder zwar per Direktlink auf deren URL verwenden, aber sie werden nicht in der Mediathek angezeigt.

Importieren der Bilder aus einem Ordner mit einem Plugin

Um die Bilder in die Mediathek zu importieren, könnte man Plugins wie Add From Server verwenden, das einige vielleicht kennen. Es wurde aber seit 3 Jahren nicht mehr aktualisiert. Es mag noch funktionieren, aber in der Plugin-Beschreibung wird auch erwähnt, dass es nicht wirklich für Migrationen gedacht ist. Ich habe Media Sync als eine aktuellere Alternative gefunden, aber ich habe dieses Plugin selbst noch nie getestet.

Importieren der Medien-Dateien mit der WP-CLI

Ihr könnt auch die WP-CLI zum Import von Medien-Dateien aus einem Ordner verwenden. Hier mal ein Beispiel zum Import von Dateien einer anderen WordPress-Installation in einer andere auf dem gleichen Server:

$ wp media import ../source/wp-content/uploads/**\/**\/*.jpg
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391-1024x683.jpg' as attachment ID 6.
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391-150x150.jpg' as attachment ID 7.
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391-1536x1024.jpg' as attachment ID 8.
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391-2048x1365.jpg' as attachment ID 9.
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391-300x200.jpg' as attachment ID 10.
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391-768x512.jpg' as attachment ID 11.
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391.jpg' as attachment ID 12.
Imported file '../source/wp-content/uploads/2023/08/28164a88367399c18.97744391-scaled.jpg' as attachment ID 13.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317-1024x683.jpg' as attachment ID 14.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317-150x150.jpg' as attachment ID 15.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317-1536x1024.jpg' as attachment ID 16.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317-2048x1365.jpg' as attachment ID 17.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317-300x200.jpg' as attachment ID 18.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317-768x512.jpg' as attachment ID 19.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317.jpg' as attachment ID 20.
Imported file '../source/wp-content/uploads/2023/08/41864a882e698f3d6.67081317-scaled.jpg' as attachment ID 21.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907-1024x683.jpg' as attachment ID 22.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907-150x150.jpg' as attachment ID 23.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907-1536x1024.jpg' as attachment ID 24.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907-2048x1365.jpg' as attachment ID 25.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907-300x200.jpg' as attachment ID 26.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907-768x512.jpg' as attachment ID 27.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907.jpg' as attachment ID 28.
Imported file '../source/wp-content/uploads/2023/08/75364a8821590f529.41962907-scaled.jpg' as attachment ID 29.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704-1024x683.jpg' as attachment ID 30.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704-150x150.jpg' as attachment ID 31.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704-1536x1024.jpg' as attachment ID 32.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704-2048x1365.jpg' as attachment ID 33.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704-300x200.jpg' as attachment ID 34.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704-768x512.jpg' as attachment ID 35.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704.jpg' as attachment ID 36.
Imported file '../source/wp-content/uploads/2023/08/89264a87feebb12a4.11887704-scaled.jpg' as attachment ID 37.
Success: Imported 32 of 32 items.

In diesem Beispiel werden alle *.jpg Bilder aus den Monats-Unterordnern importiert. Ihr könnt hier aber bereits ein großes Problem erkennen. Da WordPress viele unterschiedliche Größen für ein Originalbild erstellt, würdet ihr hiermit alle davon als separate Medien-Datei in die Mediathek importieren. Ihr müsstet also vor dem Import alle per FTP kopierten Dateien manuell löschen. Wenn ihr große Mengen migriert, kann das recht zeitaufwändig und fehleranfällig sein. Aber wie können wir es sonst lösen? Es gibt andere (Premium-)Plugins, die besser funktionieren, aber es gibt auch einen einfacheren und kostenlosen Weg.

Migration der Mediathek mit dem WordPress Export/Import

Bei jeder WordPress-Installation gibt es einen Standard-Export-Mechanismus. Diesen findet ihr unter „Werkzeuge > Export“ in eurem Dashboard. Hier könnt ihr auswählen, welchen Inhaltstyp ihr exportieren wollt und ihr könnt ihn auch noch nach einem Datumsbereich filtern.

Exportieren der Medien-Dateien

Wir wollen nur Median-Dateien exportieren und wählen keinen Datumsbereich aus, um alle auf einem zu exportieren:

Das Werkzeug zum Exportieren von Medien-Dateien.
Das Werkzeug zum Exportieren von Medien-Dateien

Nach dem Klick auf „Export-Datei herunterladen“ bittet euch der Browser, eine XML-Datei zu speichern. Diese kann dann auf der Zielseite zum Import der Dateien verwendet werden. Das Export-Werkzeug exportiert also nicht alle Bilder (oder andere Dateitypen), sondern es exportiert nur die Information, wo diese zu finden sind.

Importieren der Medien-Dateien

Jetzt meldet ihr euch im Dashboard der Zielseite an. Dort navigiert ihr dann zu „Werkzeuge > Daten importieren“. Ganz am Ende findet ihr den „WordPress“ Importer. Diese ist nicht standardmäßig installiert, aber ihr könnt ihn über den Link einfach direkt installieren:

Übersicht der Import-Werkzeuge mit dem hervorgehobenen "Jetzt installieren" Link.
Übersicht der Import-Werkzeuge mit dem hervorgehobenen „Jetzt installieren“ Link

Das installiert und aktiviert das Plugin direkt. Der Link ändert sich dann zu „Importer ausführen“. Er führt euch dann zu einer Seite mit einem Dateiupload. Dort wählt ihr die zuvor heruntergeladene XML-Datei aus und klickt auf „Datei hochladen und importieren“. Anschließend solltet ihr eine Seite wie diese sehen:

Schritt 2 des XML-Imports, der euch um eine Zuordnung der Autoren bittet und die Option "Anhänge importieren" anbietet.
Schritt 2 des XML-Imports, der euch um eine Zuordnung der Autoren bittet und die Option „Anhänge importieren“ anbietet

Auf dieser Seite werden alle Autoren der Ursprungsseite angezeigt und ihr habt die Möglichkeit diese entweder zu einem neuen Benutzer zu importieren, oder aber einem bestehenden Benutzer zuzuordnen.

Der wichtigste Teil dieser Seite ist aber die Checkbox „Dateianhänge herunterladen und importieren“, die ihr aktivieren müsst. Nach einem Klick auf „Senden“ startet der Import. Abhängig von der Anzahl an Dateien kann das eine Weile dauern.

Möglichet Skript-Timeout

Da dieser Prozess alle Dateien per HTTP von der Urspungsseite lädt (und dabei auch die anderen Bildgrößen erstellt), kann es vorkommen, dass die Abfrage mit einem Timeout abbricht. Ihr könnt dann entweder die gleiche XML-Datei erneut importieren (bereits existierende Inhalte werden übersprungen), oder aber ihr teilt die Datei beim Export in mehrere XML-Dateien auf, indem ihr die Datums-Filter verwendet, um Dateien zu erstellen, die klein genug sein.

Fazit

Es gibt viele Wege, um Medien-Dateien von einer Seite zu einer anderen zu migrieren. Obwohl ich sehr gerne die WP-CLI für so etwas verwende, hat der WordPress Export/Import doch einige Vorteile. Alles, was ihr dafür braucht, ist die Möglichkeit Plugins zu installieren. Ihr benötigt also keinen FTP- oder SSH-Zugang, um die WP-CLI zu installieren und auszuführen (wozu ihr vielleicht keine Berechtigung habt). Man kann dabei dann auch die Medien-Dateien filtern. Und wenn man weiß, wie man eine XML-Datei bearbeitet, kann man noch besser anpassen, was importiert wird.

Ein weiteres Plugin geht in den Ruhestand

Gestern habe ich ein weiteres meiner alten Plugins schließen lassen: Kau-Boy’s Opensearch. Ja, früher habe ich noch ein Präfix für meine Plugins verwendet, so wie viele andere auch. 😀

Es war das vierte Plugin, das ich im WordPress Plugin-Verzeichnis veröffentlicht habe. Der Einsatzzweck war es, eine OpenSearch Format-Beschreibung zur Seite hinzuzufügen. Früher haben es Browser im Suchfeld rechts neben dem Adressfeld dann ermöglicht, die Suche der WordPress Installation hinzuzufügen. Etwa 2019 hat aber Firefox aufgehört, dieses zusätzliche Suchfeld anzubieten.

Auch Chrome hat die Suche auf Websites nicht mehr automatisch angeboten. Damit konnte man die Domain eintippen, und nach Drücken von TAB dann direkt auf der Seite suchen. Das hat noch nicht einmal das OpenSearch Feature benötigt. Aber auch diese automatische Suche gibt es für neue Seiten nicht mehr. Wenn man es heute noch nutzen möchte, dann muss man die Website-Suchen manuell in den Einstellungen von Firefox und Chrome hinzufügen.

Da Browser also diese Funktionalität nicht mehr anbieten und das Plugin zuletzt nur noch 10+ aktive Installationen hatte, habe ich mich dazu entschlossen es zu entfernen. In den 13 Jahren, in denen es im Plugin-Verzeichnis verfügbar war, gab es nur 1627 Downloads. Es war also schon immer ein Nischen-Plugin.

Alternativen

Wie schon zuvor erwähnt gibt es keine echten Alternativen, es sei denn, ihr wollt solche Website-Suchen manuell im Browser hinzufügen. Eine Zeitlang gab es noch Firefox Add-ons für Suchen, aber die scheinen auch alle entfernt worden zu sein. Chrome scheint so etwas auch nicht mehr anzubieten.

Suche-Shortcuts

Während der Recherche der aktuellen Suchoptionen in Chrome bin ich aber auf einige nützliche Such-Shortcuts gestoßen. Wenn ihr @tabs in die Adresszeile eintippt, könnt ihr direkt nach offenen Tabs suchen. Mit @lesezeichen sucht ihr innerhalb eurer Lesezeichen und mit @verlauf entsprechend in eurem Browser-Verlauf. Firefox hat ähnliche Shortcuts, verwendet aber verschiedene Symbole, die ich euch merken müsst.

Zukünftige Plugin-Pläne

Von meinem 13 Plugins habe ich nun zwei geschlossen und zwei weitere folgen noch im September und Oktober. Das gibt mir mehr Zeit, um mich um die verbliebenen Plugins zu kümmern und diese auf Kompatibilität mit den neuen WordPress-Versionen zu testen. Ich habe aber auch einige neue Plugins in der Vorbereitung. Bleibt also gespannt!

Das Upload-Limit auf einer Multisite setzen

Letzte Woche wurde ich von einem Kollegen gefragt, wie man das Upload-Limit in WordPress erhöhen kann. Er hat es auf verschiedene Arten probiert, aber es wurde dennoch nicht erhöht. Schauen wir uns also an, was man tun muss, um es zu erhöhen.

Überprüfung des aktuellen Limits

Einer der einfachsten Wege das aktuelle Upload-Limit zu kontrollieren ist es, eine neue Datei hochzuladen. Wenn ihr in die Mediathek navigiert, könnt ihr hier das aktuelle Limit sehen:

Die Mediathek, die eine "Maximale Dateigröße für Upload: 64 MB" anzeigt.
Die Mediathek, die eine „Maximale Dateigröße für Upload: 64 MB“ anzeigt

Man sieht hier also, dass meine Dateien bis zu einer Größe von 63 MB hochladen kann. Es gibt noch einen zweiten Ort im WordPress-Dashboard, an dem ihr das Limit sehen könnt, nämlich unter Website-Zustand > Bericht > Medien-Handhabung:

Der "Medien-Handhabung" Bericht im Website-Zustand, der eine max. Uploadgröße von 64 MB anzeigt
Der „Medien-Handhabung“ Bericht im Website-Zustand, der eine max. Uploadgröße von 64 MB anzeigt

Auch auf dieser Anzeige sehen wir ein Limit von 64 MB. Aber wie können wir es nun erhöhen, um größere Dateien hochzuladen?

Erhöhung des Limits auf Server-Ebene

Um größere Dateien hochladen zu können, müssen diese vom Server akzeptiert werden. Das ist, was „Maximale Anzahl erlaubter POST-Daten“ aussagt. Diese Werde setzt man in der Regel in der php.ini Datei:

post_max_size = 128M
upload_max_filesize = 128M

Ich habe einen Blogbeitrag dazu geschrieben, wie man Änderungen macht, ohne diese beim nächsten Update zu verlieren. Abhängig vom eingesetzten PHP-Interpreter müsst ihr diese nach dieser Änderung noch neu starten. Anschließend können wir die neuen Werte in unserer Installation prüfen:

Der "Medien-Handhabung" Bericht im Website-Zustand, der eine max. Uploadgröße von 128 MB anzeigt.
Der „Medien-Handhabung“ Bericht im Website-Zustand, der eine max. Uploadgröße von 128 MB anzeigt

Jetzt sollten wir also in der Lage sein, Dateien mit einer Größe von bis zu 128 MB hochzuladen, richtig? Schauen wir in der Mediathek nach:

Die Mediathek, die eine "Maximale Dateigröße für Upload: 64 MB" anzeigt.
Die Mediathek, die eine „Maximale Dateigröße für Upload: 64 MB“ anzeigt.

Nein, können wir noch immer nicht! Es zeigt noch weiterhin nur 63 MB an. Aber wieso? Der Grund hierfür ist, dass es auf einer Multisite noch eine weitere Option gibt, die wir anpassen müssen.

Festlegen des Upload-Limits auf einer Multisite

Navigiere hierzu zu „Netzwerk-Einstellungen“ und dann fast ganz nach unten zu „Upload-Einstellungen“. Hier findest du das Feld mit dem zu niedrigen Wert:

Die "Upload-Einstellungen" in den "Netzwerk-Einstellungen" zeigen noch immer 64000 KB an.
Die „Upload-Einstellungen“ in den „Netzwerk-Einstellungen“ zeigen noch immer 64000 KB an

Setzen wir den Wert nun auf 128000 KB, speichern die Einstellungen und navigieren zurück zum Datei-Upload in der Mediathek:

Die Mediathek, die eine "Maximale Dateigröße für Upload: 125 MB" anzeigt.
Die Mediathek, die eine „Maximale Dateigröße für Upload: 125 MB“ anzeigt

Jetzt sehen wir die erhöhte Dateigröße. Falls wir hier genau 128 MB haben wollen, müssen wir den Wert zuvor mit 1,024 multiplizieren. Aber das sollte so gut genug sein.

Fazit

Du weißt vielleicht bereits, wie man das Upload-Limit auf vielen Servern und WordPress-Installation erhöhen kann und hast damit nie Probleme gehabt. Auf einer Multisite ist aber noch eine zusätzliche Einstellung notwendig, auf die du achten musst.

Und was ist mit dir? Verwendest du auch eine Multisite-Installation? Wieso oder wieso nicht? Hast du auch schon komische Unterschiede gefunden, die du manchmal wieder vergisst?

Verschiedene Methoden zum Debuggen von PHP-Code

Diese Woche wurde ich um Hilfe bei der Einrichtung von Xdebug mit PhpStorm auf einem Linux-Laptop in Verbindung mit Docker gebeten. Darüber schreibe ich vielleicht in einem kommenden Blogbeitrag. Heute möchte ich mich aber auf verschiedene Methoden zum Debuggen von PHP-Code konzentrieren.

1. echo, print_r, var_dump – der schnelle, aber hässliche Weg

Wer schon einmal etwas in PHP entwickelt hat, ist wohl nicht um eine der „Ausgabefunktionen“ herumgekommen. Mit echo kannst du einen generischen Wert wie einen String oder eine Zahl ausgeben. Für Arrays und Objekte verwendest du eher print_r oder var_dump.

Vorteile:

  • Einfach: Die Methoden können einfach verwenden werden. Du musst nichts installieren, um sie nutzen zu können.
  • Schneller Einblick: Wenn du einfach nur den Wert an einer bestimmten Stelle ausgeben möchtest, ist es mit den Funktionen sehr einfach, den aktuellen Wert an dieser Stelle auszugeben.

Nachteile:

  • Ausgabe-Einschränkungen: Die Methoden sind eher einfach. Du erhältst nur den Wert dieser einen Variable, aber keinen „Kontext“. Da die Ausgabe oft in ein HTML-Dokument gerendert wird, musst du sie möglicherweise in ein <pre>-Tag für Arrays/Objekte einbetten oder sie im Quellcode anzeigen lassen.
  • Störend: Wenn du die Variablen ausgibst, dann tust du das möglicherweise beim Rendern eines Templates. Das bedeutet, dass dein Layout/Design verzerrt wird.
  • Unsicher: Wenn du diese Methode auf einer Live-Website verwendest, dann ist die Ausgabe für alle sichtbar. Das sieht nicht nur wie ein Fehler aus, es kann auch ein Sicherheitsrisiko darstellen, wenn der Inhalt der zu debuggenden Daten nicht sichtbar sein sollte.
  • Aufräumen erforderlich: Selbst wenn du diese Methode nur beim lokalen Entwickeln verwendest, musst du daran denken, den Code wieder zu entfernen, bevor du ihn hochlädst oder du einen Commit und Push in eine Versionskontrolle machst. Es passiert recht schnell, dass man einige Zeilen übersieht, die dann auf einer Live-Website landen.

2. error_log, file_put_contents – Ausgabe in eine Datei

Anstatt die Debug-Ausgabe direkt auf dem Bildschirm auszugeben, könntest du sie in eine Datei schreiben. Dies hat einige Vorteile, aber auch einige Nachteile:

Vorteile:

  • Trennung der Zuständigkeiten: Wenn du die Debug-Informationen in eine Datei schreiben lässt, dann hälst du den Anwendungscode frei von Debug-Ausgaben. Du könntest sogar deine eigene Debugging-Funktion als Wrapper für die error_log oder file_put_contents Funktionen einführen und innerhalb dieser Funktion prüfen, ob der „Debug-Modus“ aktiv ist.
  • Dauerhafte Speicherung: Wenn du diesen „Debug-Modus“ aktiviert hast, kannst du die Daten über einen längeren Zeitraum in der Datei speichern und diese Datei dann später auf die möglichen Fehler hin überprüfen. Es ermöglicht dir auch das Debuggen von Anfragen von anderen Personen, womit du möglicherweise Probleme finden kannst, die du selbst nicht „siehst“.
  • Keine störende Ausgabe: Deine Ausgabe auf der Website bleibt sauber, da alle Debug-Daten nur die Datei geschrieben werden.

Nachteile:

  • Manuelle Überprüfung: Du erhältst die Debug-Informationen nicht sofort. Wenn du dies auf einer Live-Website ausführst, siehst du möglicherweise sogar die Debug-Informationen einer anderen Person. Mithilfe des tail Befehls kannst du die Datei aber fast in „Echtzeit“ debuggen.
  • Schwieriger zu debuggen: Wenn du eine gemeinsame Debug-Datei für alle Funktionen verwendest, erhältst du alle Debug-Daten ohne jeglichen „Kontext“. Wenn du also die Datei/Zeile einer bestimmten Meldung identifizieren möchtest, musst du sie vielleicht noch __FILE__ und __LINE__ voranstellen und zusätzlich auch Datum/Uhrzeit voranstellen, damit du weißt, wann der Eintrag geschrieben wurde.
  • Overhead: Das Loggen von Daten in eine Datei kann die Leistung der Website beeinträchtigen, insbesondere wenn du eine große Menge Daten debuggst. Du solltest auch die Dateigröße der Debug-Datei von Zeit zu Zeit überprüfen und sicherstellen, dass der Debug-Modus nur dann deaktiviert ist, wenn du ihn wirklich braucht, da du sonst leicht den gesamten verbleibenden Speicherplatz auf deinem Server mit einer riesigen Protokolldatei füllen kannst.
  • Sicherheitsrisiko: Ja, auch die Verwendung einer Debug-Datei kann ein Sicherheitsrisiko darstellen, falls diese öffentlich zugänglich ist. Wenn sie allerdings nicht öffentlich zugänglich ist, dann ist das Debuggen mit einer Datei wieder schwieriger, du den Inhalt dann nur über ein Terminal oder durch Herunterladen einsehen kannst. WordPress beispielsweise speichert die debug.log Datei im wp-content Ordner und macht sie für alle aufrufbar. Du kannst aber den Pfad anpassen, um den direkten Zugriff zu verhindern.

Debug-Plugins – das Beste aus beiden Varianten bekommen

Für WordPress verwende ich normalerweise immer das Query Monitor-Plugin. Dieses Plugin bietet mehrere Actions zum Debuggen von Variablen. Eine davon ist die qm/debug Action.

Vorteile:

  • Keine direkte Ausgabe: Durch die Verwendung dieser Action gibst du die Debug-Daten nicht auf der Seite aus, die Website wird also nicht verzerrt dargestellt.
  • Sicherheit: Du siehst die Debug-Daten von Query Monitor (und dem Hook) normalerweise nur denn, wenn du ein Administrator der Website bist. Aber du kannst es sogar (mithilfe eines Cookies) verwenden, wenn du ausgeloggt bist.
  • Keine Debug-Datei erforderlich: Es sendet die Debug-Daten mit der Response und speichert keine Datei auf dem Server ab. Damit hast du nicht die Nachteile der vorherigen Methode.

Nachteile:

  • Debug-Code in deinem Anwendungscode: Wie bei den anderen Methoden musst du immer noch Code zum Debuggen in deinen Anwendungscode schreiben. Du würdest diesen Code dann auch auf einer Live-Website haben oder einem Repository haben. Das sollte für „unveröffentlichten“ Code in Ordnung sein, aber du möchtest ihn lieber nicht in einem Plugin/Theme veröffentlichen. Bevor du also eine neue Version des Plugins/Themes veröffentlichst, müsstest du den Debug-Code wieder entfernen.
  • Kann keine defekten Seiten debuggen: Da diese Debugging-Methode das Query Monitor-Plugin erfordert, kannst keinen schwerwiegenden Fehler debuggen, der den Query Monitor daran hindert angezeigt zu werden.
  • Du siehst nur deine eigenen Fehler: Du kannst diese Methode nicht verwenden, um Probleme zu debuggen, die eine andere Person mit deiner Website hat, und du möchtest der anderen Person wahrscheinlich auch nicht die Berechtigung geben, Query Monitor selbst zu verwenden.

Xdebug – die nächste Stufe des Debuggens

Wenn du noch nie von Xdebug gehört hast und/oder es noch nie verwendet hast: verwende es direkt, nachdem du diesen Blogbeitrag gelesen hast! Für mich ist es das beste Tool, um komplexe Probleme zu debuggen. Xdebug ist eine PHP-Erweiterung, die installiert und aktiviert werden muss. Du benötigst auch eine IDE wie PhpStorm oder VS Code, um es zu verwenden, aber dann kann es dir wirklich helfen, diese schwer zu debuggenden Probleme zu finden.

Vorteile:

  • Kein zusätzlicher Code erforderlich: Anstatt Debugging-Funktionen in deinen Code zu schreiben, setzt du einfach einen „Breakpoint“ in deiner IDE in einer bestimmten Zeile.
  • Du kannst alles debuggen: Sobald ein Breakpoint erreicht ist, kannst du jede Variable debuggen! Du bist also nicht auf eine einzelne Variable beschränkt, sondern du kannst den Wert aller Variablen einsehen. Du kannst auch den „Aufrufstapel“ sehen, also jede Funktion, die vor dem Erreichen dieses Punktes aufgerufen wurde. Du kannst auch zu diesen Funktionen zurückgehen und die Parameter untersuchen, mit denen sie aufgerufen wurden.
  • Nur bestimmte Fälle untersuchen: Angenommen, dein Code bricht nur in Fällen ab, in denen eine Variable einen bestimmten Wert hat. In diesem Fall kannst du einen bedingten Breakpoint verwenden, der nur anhält, wenn diese Bedingung erfüllt ist.
  • „Was-wäre-wenn“: Du hast also ein Problem mit einer Variable und ihrem Wert gefunden und nun fragst du dich, ob der Code mit einem anderen Wert funktionieren würde? Wenn du an einem Breakpoint bist, kannst du den aktuellen Wert einer Variable überschreiben und dann fortsetzen, um zu sehen, was in diesem Fall passieren würde.

Nachteile:

  • Schwierige Einrichtung: Wenn du Xdebug noch nie zuvor verwendet hast, könnte es schwierig sein, es einzurichten. Du musst die PHP-Erweiterung auf dem Rechner, auf dem du den Code ausführst, installieren und aktivieren und deine IDE konfigurieren. Wenn du es mit Docker verwendest, musst du auch sicherstellen, dass der PHP-Container mit deiner IDE „kommunizieren“ kann. Obwohl es viel einfacher geworden ist und PhpStorm heutzutage (fast) keine Konfiguration mehr benötigt, könnte es schwierig sein, es beim ersten Mal zum Laufen zu bringen. Ich verwende es normalerweise in Kombination mit DDEV und weiß jetzt, wie ich es schnell zum Laufen bringen kann. Aber deine Konfiguration könnte eine andere seit.
  • Könnte deinen Request abbrechen: Da du den Request beim Debuggen „anhältst“, könnte es möglich sein, dass deine Website nicht mehr angezeigt wird, wenn du den Code hast durchlaufen lassen. Das ist normalerweise der Fall, wenn du nginx als Webserver verwendest. Du erhältst dann einen Error 500, weil die Anfrage an das „PHP-Backend“ abgelaufen ist.
  • Auf Live-Umgebungen nicht wirklich verwendbar: Xdebug ist super für die Entwicklung in einer lokalen Umgebung, aber es nicht das beste Tool für den Einsatz auf einer Live-Website. Xdebug hat einen großen Einfluss auf die Performance. Da Xdebug mit deiner IDE „kommunizieren“ muss, könnte es auch schwierig bis unmöglich sein, eine Konfiguration zu finden, die mit deiner IDE und einer Live-Site funktioniert.

Fazit

Es gibt verschiedene Methoden zum Debuggen von PHP-Code, und alle von ihnen haben ihre Vor- und Nachteile – sogar mehr, als ich in diesem Blogbeitrag erwähnt habe. In einigen Fällen reicht ein schnelles Debuggen mit echo aus. Aber es gab in der Vergangenheit einige Probleme, die ich ohne die Hilfe von Xdebug niemals gefunden hätte. Daher empfehle ich dringend, eine Konfiguration zu finden, die für dich funktioniert.

Ich habe einige Leute nach ihren Debugging-Methoden gefragt. Etwa 40% verwenden häufig Methode 1, etwa 5% Methode 2 und „nur“ 55% haben schonmal Xdebug benutzt. Ich hoffe, dass ich die anderen 45% auch endlich davon zu überzeugen, Xdebug als ihr Debugging-Tool zu benutzen.

Und was ist mit dir? Hast du Xdebug schon mal benutzt? Verwendest du andere Methoden, die ich nicht erwähnt habe und die für dich gut funktionieren? Dann hinterlasse bitte einen Kommentar.

WordCamp Leipzig 2023 – Kleiner, aber genauso großartig!

Gestern habe ich das WordCamp Leipzig besucht. Es was das erste WordCamp vor Ort in Deutschland seit 2019. Es war ein WordCamp, aber in mancher Hinsicht auch speziell.

Anreise nach Leipzig mit dem Zug

Wenn ich normalerweise ein WordCamp besuche, dann muss ich Züge (oder Flüge) und eine Unterkunft buchen. Für dieses WordCamp konnte ich meine Wohnung kurz nach 7 Uhr verlassen, 10min zum Bahnhof laufen, 1:40h den ICE nehmen, am Hauptbahnhof Leipzig ein kleines Frühstück und Kaffee mitnehmen, in die Tram steigen und knapp 2h nach Verlassen der Wohnung schon beim WordCamp sein. Es war also fast wie ein lokales WordCamp in Berlin.

Treffen der lokalen Communtiy

Dieses WordCamp wurde von Anfang an für die Community aus Leipzig ausgerichtet. Einige Teilnehmende sind von weiter her angereist, mindestens einer sogar aus dem Ausland. Aber dennoch hatte ich die Chance, neue Community-Mitglieder kennenzulernen. Einige davon kannte ich schon aus dem WP Meetup Berlin, allerdings nur per Zoom.

Ein Zeitplan mit nur einem Track und eingeladenen Vortragenden

Normalerweise schreibe ich immer über die ausgesuchten Vorträge, die ich auf einem WordCamp besucht habe, aber dieses Mal was es einfacher, da es nur einen Track gab: ich habe alle besucht 🙂

Alle Vortragenden wurden vom Organisationsteam eingeladen. Einige Themen waren nicht unbedingt solche, die ich mir auf einem WordCamp ansehen würde, aber mir haben alle gefallen. Ein paar gingen mehr in die Tiefe und haben Wissen vermittelt, andere waren allgemeiner.

Maja aus der Berliner Community hat auch einen Vortrag zu Barrierefreiheit gegeben. Auch wenn ich viele Dinge schon kannte, so waren doch einige der neuen Regelungen, die 2025 in Kraft treten, noch neu für mich:

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Kein Mittagessen!

Das WordCamp Leipzig wollte „so minimalistisch wie möglich“ sein. Daher wurden wir zur Mittagspause alle gebeten, uns selbst etwas zum Essen zu suchen. Der Veranstaltungsort war aber so gut gelegen, dass im Umkreis von 100 m sehr viele Angebote für jeden Geschmack dabei waren. Ich habe mich einer Gruppe angeschlossen, die (vegetarische) Burger essen gegangen ist. Wir haben dabei viel über Plugins, Einstellungen/Optionen und andere Entwicklungsthemen gesprochen.

Es war aber nicht so, als hätte sich das Organisationsteam nicht um uns gekümmert. Es gab kostenlose (alkoholfreie) Getränke und mit Mate und Cola war man dann auf für das Nachmittagsprogramm noch fit genug. Am Nachmittag gab es auch noch Kuchen und Muffins. Zwischen den Vorträgen sind wir meistens rausgegangen, um ein wenig Sauerstoff zu tanken und zu reden.

Ein langer kurzer Tag

Wenn man 7 Vorträge ab Stück hört, und keine Chance hat etwas anderes zu tun, wie mit Sponsoren zu sprechen, wie auf größeren WordCamps, dann fühlt sich so ein Tag schon lang an. Aber er war auch wiederum recht kurz, denn plötzlich war schon der letzte Vortrag vorbei und es war Zeit für die Verabschiedung.

Darin wurde dann dem Organisationsteam (5 Personen), sowie den globalen und lokalen Sponsoren gedankt. Das Team hat dann auch angekündigt, dass es auch 2024 wieder ein WordCamp Leipzig geben wird:

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Die Organizer haben dann alle gebeten zu gehen, und sich einfach abzusprechen, wer im Anschluss noch woanders hingehen möchte. Aber währen wir schon draußen standen hat uns ein Organizer mitgeteilt, dass wir doch noch länger bleiben könnten. Und da die Getränke schon bezahlt und noch nicht leer waren, man jetzt auch auf eigene Kosten Bier und ähnliches kaufen konnte und jemand vorgeschlagen hat Pizza zu bestellen, sind wir geblieben und es gab eine „Afterparty“:

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Ich bin noch etwa 4h geblieben und habe mit anderen über verschiedene Themen gesprochen. Jemand konnte mir auch endlich mal erklären, wie Instagram funktioniert ?

Zeit nach Hause zu fahren

Ich habe wieder eine Tram zum Hauptbahnhof genommen, und musste zum Glück nicht ganz alleine fahren. Heiko wohnt fast bei mir um die Ecke und hatte den gleichen Zug gebucht. Kurz vor Mitternacht war ich dann nach diesem WordCamp endlich zu Hause, was sich wirklich wie ein lokales angefühlt hat.

War es wirklich ein WordCamp?

Letzte Woche hat WP Tavern über die neuen WordCamp Formate geschrieben, mit denen das Community-Team experimentieren möchte. Das WordCamp Leipzig war eines der Events, die darin erwähnt wurden. Manche haben dann auf Twitter darüber diskutiert, ob es denn wirklich ein WordCamp sei oder nicht doch eher ein Meetup.

Meiner Meinung nach war es sehr wohl ein WordCamp. Ich habe schon andere WordCamp besucht, die nur einen Track hatten und auch solche, bei denen alle Vortragenden eingeladen wurden. Kein Mittagessen zu haben, was für mich kein Problem, denn so hatte man die Chance die anderen kennenzulernen und alle konnten das Essen finden, das sie gerne essen.

Also was genau hätten Leute erwartet, um es als WordCamp zu bezeichnen und nicht als „Ganztagesmeetup“?

Ein neues Format für mehr Communitys

Ich habe bereits erfahren, dass auch die Britische Community darüber nachdenkt, ein ähnliches Event zu veranstalten. Dort wird es wohl mehr Teilnehmende und auch Mittagsessen geben, aber ebenfalls maximal eine kleine Afterparty.

Dies war zumal, mit Ausnahme des „inoffiziellen“ WordCamp Jena 2019, das erste WordCamp im Osten von Deutschland. Zu sehen, dass die Organisatoren bereits für 2024 planen, ist ein tolles Zeichen! Und da wir gerade vom Organisationsteam sprechen, sie haben einen tollen Job gemacht. Danke also an alle im Team!

Würde ich auch ein solches Event veranstalten?

Ich habe über so etwas für Berlin nachgedacht. Tatsächlich hatten wir das ja für 2015 geplant, es wurde dann aber doch wieder ein größeres und „traditionelles“ WordCamp. Aktuell habe ich keine Pläne in diesem oder nächsten Jahr ein WordCamp zu organisieren. Ich würde dann aber wohl mal eines der neuen Formate ausprobieren. Bevor ich aber ein WordCamp organisiere, möchte ich einen do_action: Charity Hackathon in Berlin organisieren!

Vierzehn Jahre Bloggen und ein bisschen Wehmut

Heute ist es mal wieder so weit. Mein Blog hat Geburtstag. Angefangen hat es am 21. Juni 2009, der Grund dafür war vor allem, dass ich zwei Tage zuvor mein erstes Plugin veröffentlicht hatte.

Schließung meines ersten Plugins ?

Nachdem dieses Plugin zuletzt aber nur noch 10+ aktive Installationen hatte und auch seit langem nicht mehr gepflegt wurde, habe ich es dann gestern, 14 Jahre nach der ersten Version, endgültig schließen lassen.

Aber keine Angst, ich werde heute nicht auch noch meinen Blog endgültig abschalten, ganz im Gegenteil!

Zahlen, Zahlen, Zahlen!

Einen neuen Besucherrekord hat es nicht gegeben. Aber dennoch ist ein Block auf die Zahlen der vergangenen 12 Monate interessant. Während auf der deutschen Seite etwa 9,8% mehr Besuche stattfanden, waren es auf der englischen Seite 181% mehr. Und nachdem ich früher etwa einen Anteil von 15-20% bei den englischen Seitenaufrufen hatte sind es nun durch diesen starken Zuwachs ca. 53,4% und somit lese mehr Menschen meinem Blog auf Englisch als auf Deutsch! Es hat sich also gelohnt, weiter alle zwei Wochen einen Beitrag in beiden Sprachen zu schreiben.

Top3 im letzten Jahr

  1. Fatale Fehler in WordPress mit PHP 8+ und einer fehlerhaften Übersetzung
  2. Formatierten Quellcode mit Syntaxhervorhebung in Word einfügen
  3. Direkte Downloads mit dem „download“ Attribute

Es gibt einen neuen Platz 1 in den Top3 und es ist ein Artikel, den ich erst am Dezember 2022 veröffentlicht habe. In also nicht einmal einem halben Jahr hat er mehr Aufrufe gehabt, als die alte Nummer 1, die zwei Plätze einbüßen musste. Dafür ist der drittstärkste Beitrag wieder auf dem zweiten Platz gelandet. Im Vorjahr hatten sie die Plätze gewechselt, nun geht es wieder zurück, mit noch größerem Abstand als letztes Jahr.

Kein neues Theme

Vor einem Jahr hatte ich groß angekündigt, dass ich das aktuelle Theme einmal komplett neu als FSE-Theme programmieren wollte. Leider ist aus dem Vorhaben nichts geworden. Vermutlich dachte ich, dass ich ohne die Orga-Arbeit für das WCEU dafür mehr Zeit hätte, aber so ein Jobwechsel und ein erneuter Umzug in eine neue Wohnung verschlingen dann eben auch Zeit und Energie. Daher möchte ich an dieser Stelle nicht wieder etwas versprechen, was ich vielleicht in den nächsten 12 Monaten wieder nicht halten kann. 😅

WordCamps sind wieder da!

Auch wenn ich aktuell nicht in der Orga eines WordCamps dabei bin, so habe ich doch bereits drei vor Ort dieses Jahr besucht. Übernächstes Wochenende bin ich dann beim WordCamp Leipzig, was versucht, ein anderes und sehr reduziertes Format zu zeigen. Im August geht es dann zum WordCamp US, im September (sehr wahrscheinlich) zum WordCamp London und schließlich im Oktober zum großen WordCamp Deutschland. Ihr könnt euch also wieder auf einige Blogbeiträge mit Berichten dazu freuen. Und im nächsten Jahr bin ich (hoffentlich) wieder beim WordCamp Europe in Turin dabei, entweder nur als Attendee, oder aber das erste Mal als (normaler) Speaker. Um wie immer den Blogbeitrag mit einem Video abzuschließen, könnt ihr hier das Video mit der Ankündigung sehen:

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

WordCamp Europe 2023 – Eine andere Perspektive auf das größte WordPress Event

Ich schreibe diesen Blogbeitrag, während ich noch immer in Griechenland bin. Dieses Jahr habe ich das WordCamp in einer anderen Rolle erlebt. Nachdem ich 2017 dem Organisationsteam beigetreten und bis letztes Jahr alle Veranstaltungen vor Ort mitorganisiert habe, bin ich zum Event in Athen in einer anderen Rolle gereist.

Meine erste Reise nach Griechenland

Wie schon so oft in den vergangenen Jahren hatte ich auch dieses mal wieder die Gelegenheit ein neues Land durch ein WordCamp kennenzulernen. Es was meine erste Reise nach Griechenland und somit natürlich auch mein erster Besuch von Athen. Begonnen habe ich die Reise am Freitag vor zwei Wochen. Wir haben ein wenig die Sehenswürdigkeiten der Stadt angesehen. Der Besuch der Akropolis was natürlich Pflicht und die Erfahrung war es auf jeden Fall wert. Aber Athen hat sehr viel mehr zu bieten. Nicht nur historische Plätze, sondern auch tolles Essen.

Remote Arbeiten

Seit ich am 1. Oktober zu Inpsyde gewechselt bin, habe ich die Freiheit, von überall aus zu arbeiten. Und da Athen nur 1 Stunde Zeitunterschied zu Berlin habe, konnte ich recht einfach von Montag bis Mittwoch arbeiten. Andere Inpsyder kamen am Mittwoch an und wir haben uns dann abends zu einem schönen Abendessen getroffen.

Donnerstag: Contributor Day

Genau wie in den vorherigen Ausgaben des WordCamp Europe begann das Event mit dem Contributor Day. Ich hatte am Morgen noch ein paar Dinge zu erledigen und war daher erst vor Ort, als sich die Gruppen bereits gefunden hatten. Ich bin an den „Meta + WordCamp“ Tisch gegangen und habe versucht ein wenig an dem Ticket zu arbeiten, das ich beim WordCamp Asia im Februar angefangen hatte. Aber da ich auch zu einem Panel eingeladen wurde, habe ich auch etwas Zeit damit verbracht, um mit zwei anderen Panelists an den Themen zu arbeiten. Direkt um Anschluss musste ich auch schon wieder gehen, weil wir das Hotel wechseln mussten. Es war also insgesamt kein so effektiver Contrbutor Day, wie ich es mir gewünscht hatte.

Am Abend war ich dann als Speaker zu „Social“ eingeladen. Eine tolle Gelegenheit, um alte Freude zu treffen und neue zu machen.

Freitag: der erste Konferenztag

Obwohl ich etwa 10min zu spät war, habe ich die Opening Remarks nicht verpasst. Wendie, die Leiterin des Volunteer-Teams, hat als Einhorn verkleidet das Publikum etwas aufgeheizt:

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Direkt nach den Opening Remarks bin ich in den ersten Vortrag gegangen.

Test instead of guessing – generate more leads through growth hacking

Dieser Vortrag wurde von meiner Kollegin Viola gehalten. Selbst wenn ich mit dem Thema in meinem Job nicht viel zu tun habe, war es doch ein faszinierendes Thema und Viola hatte es perfekt vorbereitet. Man konnte spüren, dass sie sehr für das Thema brennt und es war kaum zu glauben, dass dies ihr erster Vortrag auf einem WCEU (oder anderen Event dieser Größe) war.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Nach diesem ersten Slot habe ich mich erneut mit den anderen Panelists getroffen und wir haben die Themen für Samstag gesammelt, über die wir sprechen wollten, und auch Antworten auf Fragen vorbereitet, die vielleicht aufkommen werden. Nach dem Mittagessen bin ich dann in eine Runde von drei Lightning-Talks zum Themenkomplex AI gegangen.

Take your WordPress website to another level using AI translation

Dario hat eine kurze Einführung in das Problem von Übersetzungen gegeben und wieso es wichtig ist, eine Website in mehrere Sprachen zu übersetzen, um potenziell mehr Menschen anzusprechen. Er hat über die verschiednene Lösungen zur Übersetzung einer WordPress-Website gesprochen und wieso es für diese wichtig sein wird, die verschiedenen Überserzungs-AIs zu integrieren.

Innovating inclusion: harnessing AI for accessibility

Im zweiten Lightning-Talk hat Sarah den Fokus auf Barrierefreiheit gelegt und gezeigt, wie eine AI helfen kann, diese zu verbessern. Sie hat ein paar Tools vorgestellt, die automatische Tests auf Barrierefreiheit für eure Website durchführen können. Sie hat auch einen Dienst gesprochen, der ein WordPress-Plugin zur Verfügung stellt, mit der man über ein „Overlay“ die Barrierefreiheit verbessern könnte. Ich persönlich empfehle solche Lösungen habe nicht, da sie oft die eigentlichen Probleme nicht wirklich beheben können.

Content creation with the help of AI

Der finale Lightning-Talk dieser Runde wurde vom deutschen Community-Mitglied Silvio gehalten. Man hat gemerkt, dass es sein erste WCEU-Vortrag war, denn er war sehr nervös. Er hat aber eine sehr interessante Fallstudie gezeigt, bei der er einmal einen Menschen und einmal eine AI zu den gleichen Themen Beiträge schreiben ließ. Dabei war die Conversion Rate der AI etwas besser als die des Menschen. Ich hoffe, das wird kein Trend.

Women and non-binary folx of WordPress

Nach diesen Vorträgen in Track 1 bin ich dann in den Track 2 geeilt. Dort habe ich mit ein spannendes Panel von Menschen aus der WordPress Community angesehen, die über ihre persönlichen Erfahrungen als Frauen oder nichtbinäre Personen in der Community gesprochen haben. Es gab eine paar sehr spannende Themen, eine davon zum Thema Fragen nach Vorträgen. Es wurde empfohlen, dass diese optional sein sollten. Ich mag diese Idee wirklich sehr und bin gespannt, ob einige zukünftige WordCamp damit experimentieren werden.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

You say you support women in tech

Den letzten Vortrag des Tages hat Amy gehalten. Darin hat sie sehr persönliche Erfahrungen als alleinerziehende Mutter, Frau in der IT und Opfer von häuslicher Gewalt erzählt. Die hat viele gute Tipps gegeben, was Unternehmen tun können, wenn sie Frauen in der IT wirklich unterstützen wollen. Das ist genau dir Art der Vorträge, die ich auf einem WordCamp Europe sehen will.

Am Abend war ich dann zu mehreren Parties eingeladen, habe es aber nur zur „Pride“ Party geschafft, die von Yoast mitorganisiert wurde. Schon in Bangkok hatte ich daran teilgenommen.

Samstag: der zweite Konferenztag

Den zweiten Tag habe ich etwas später begonnen und die Zeit vor dem Panel genutzt, um ein paar Sponsoren zu besuchen und mich mit mehr Leuten zu treffen. Dann war es an der Zeit mich für mein erstes Panel (meinen ersten Talk) auf einem WordCamp Europe.

WCEU Globals: future of WCEU

Ich durfte die Bühne mit Lesley, Taeke, Rocío, Moncho und Tess, den vorherigen Global Leads von WCEU 2020 – 2022, teilen. Leider konnte Jonas nicht mit dabei sein in Athen. Wir haben über verschiedene Aspekte der Organisation eines Events dieser Größe gesprochen und was wir uns für die Zukunft wünschen würden. Ich weiß noch immer nicht, ob ich in Zukunft erneut dem Orga-Team beitreten würde, aber ich bin sehr offen dafür als Mentor für zukünftige Generationen von Organizern zur Verfügung zu stehen, wie alle anderen Global Leads auch.

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Direkt nach dem Panel sind wir dann alle rausgegangen für das obligatorische Familienfoto. Seht nur, wie viele Menschen dieses Jahr dabei waren – und es rechtzeitig auf das Foto geschafft haben 😉

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Nach dem Mittagessen habe ich vor allem mit mehr Teilnehmenden gesprochen und weitere Sponsoren besucht. Ich habe es nur irgendwie fast verpasst, Swag mitzunehmen. Dann war auch schon die Zeit für die letzte Session.

Variations on a theme: 20 years of WordPress

Der Tradition eines WordCamp Europe folgend gab es auch wieder einen Talk von Matt. Er wurde auf der Bühne begleitet von Josepha und Matías. Die Themen waren die Phasen 3 und 4 von Gutenberg sowie der Community Summit. Es wurden aber auch einige faszinierende Dinge gezeigt, auf die wir uns in Zukunft freuen können. Im Anschluss war auch wieder viel Zeit für Fragen. Bei der Frage zu Mehrsprachigkeit, welche erst in Phase 4 dran ist, wurde das Publikum gefragt, wer nicht Englisch als erste Sprache spricht und es fühlte sich an, als würden alle die Hand heben. Matt hat uns auch aufgefordert „learn AI deeply“, na so ungefähr zumindest 😉 Er hat auch fast gespoilert, wo das WCEU nächstes Jahr stattfinden wird ?

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Closing remarks

Aber natürlich ist die Verkündung für das nächste Jahr etwas, dass ein WordCamp Europe immer abschließt. Zuvor wurde aber das Organisatoinsteam auf die Bühne gebeten, gefolgt von allen Volunteers. Dann kam endlich der Moment, auf den alle gewartet hatten, die nächste Stadt wurde verkündet. Hier ist das Video dazu SPOILER ALERT! Lest nicht den Text zum Tweet 😉

Hier klicken, um den Inhalt von twitter.com anzuzeigen

Wir sehen uns also nächstes Jahr in Turin, Italien. Ich hatte bereits das Vergnügen, die Stadt durch ihr lokales WordCamp 2017 kennenzulernen. Eine schöne Stadt mit tollem Essen! Ihr solltet also auf jeden Fall auch dabei sein!

Die After-Party

Da ich am nächsten Tag sehr früh aufstehen musste, um eine Fähre zu erreichen, konnte ich nicht allzu lange auf der After-Party bleiben. Zuvor habe ich mich aber mit den anderen Inpsydern auf ein schnelles Abendessen getroffen, bevor ich mich dann etwa 90min in die Menge begeben habe. Die Venue hat mich sehr stark an Sofia erinnert. Drinnen war es echt laut, weshalb viele Teilnehmende den Platz direkt vor der Venue bevölkert und die warmen Abendtemperaturen genossen haben.

Ein wenig Urlaub

Da dies meine erste Reise nach Griechenland war, und ich ohnehin für ein WordCamp Europe immer mindestens eine volle Woche einplane, habe ich noch eine weiter Woche in Griechenland dran gehängt. Wir haben also am Sonntag eine Fähre nach Ikaria genommen, und sind dann am Freitag nach Kos gefahren. Heute sind wir dann zurück nach Berlin geflogen, voller schöner Erinnerungen.

Ein anderes WordCamp Europe

Das war mein erstes WordCamp Europe, bei dem ich nicht mitorganisiert habe, seit einer ganzen Weile und es hat sich ziemlich anders angefühlt. Ich bin der Tradition folgend den Kreislauf Local Lead -> Global Lead -> Speaker durchlaufen und kann mich nun zur Ruhe setzen. Ich werde auch dem nächsten Orga-Team nicht beitreten, da aktuell andere Dinge in meinem Leben wichtig sind, bis das nächste WordCamp Europe stattfindet. Ich bin mir noch nicht einmal sicher, ob ich dabei sein kann. Aber falls es klappt, dann habe ich vielleicht endlich den Mut, mich mit einem richtigen Vortrag zu bewerben, oder zumindest als Volunteer zu melden, was ich bisher nur einmal 2016 gemacht habe. Was also auch immer die Zukunft bringen mag, wir sehen und in Turin … oder wo immer es 2025 stattfinden wird ?