Seiten-Template im Child-Theme deaktivieren oder überschreiben

Vorletzte Woche hat ein Kollege an einem neuen Projekt gearbeitet, bei dem ein Seiten-Template im Parent-Theme defekt war. Es gab ein besseres und sehr ähnliches Template, das stattdessen verwendet werden konnte. Aber es besteht weiterhin die Gefahr, dass jemand das defekte Seiten-Template beim Erstellen einer Seite auswählen würde. Also habe ich mich mal auf die Suche nach einer Lösung begeben, mit der man ein Seiten-Template aus der Auswahl entfernen kann.

Deaktivieren eines Seiten-Templates

In einem Child-Theme kann man ja sehr einfach ein neues Seiten-Template hinzufügen oder ein bestehendes überschreiben, indem man es aus dem Parent-Theme kopiert. Aber wie kann man ein bestehendes Template aus dem Parent-Theme aus der Auswahl entfernen. Glücklicherweise gibt es fast immer einen passenden Hook. Wenn ihr also ein Seiten-Template deaktivieren wollt, dann verwendet diesen Filter:

function child_theme_disable_page_template( $post_templates, $theme, $post, $post_type ) {
	unset( $post_templates['page-templates/tpl-hero-light.php'] );

	return $post_templates;
}
add_filter( 'theme_templates', 'child_theme_disable_page_template', 10, 4 );

Der Filter theme_templates bekommt ein Array aller Templates übergeben mit den relativen Pfaden als Schlüssel und den (übersetzten) Namen als Werten. Es könnte in etwa wie folgt aussehen:

$post_templates = array(
	'page-templates/tpl-fullscreen-light.php'  => 'Fullscreen, light header',
	'page-templates/tpl-fullscreen.php'        => 'Fullscreen',
	'page-templates/tpl-fullwidth-notitle.php' => 'Full Width, no page title',
	'page-templates/tpl-fullwidth.php'         => 'Full Width',
	'page-templates/tpl-hero-light.php'        => 'Hero, light header',
	'page-templates/tpl-hero.php'              => 'Hero',
);

Das Array enthält sowohl die Seiten-Templates aus dem Parent-Theme, als auch die aus dem Child-Theme. Falls beide ein Template mit dem gleichen Pfad haben, ist dieses nur einmal im Array enthalten.

Ersetzen eines Seiten-Templates

Jetzt wisst ihr also, wie ihr verhindern könnt, dass jemand ein Seiten-Template verwendet, das ihr nicht haben möchtet. Aber was ist mir den Seiten, bei denen das falsche Template bereits eingestellt ist? Nun, eine Möglichkeit wäre es, in der Datenbank das „postmeta“ mit dem Schlüssel _wp_page_template mit dem neuen Wert zu ersetzen. Aber vielleicht möchtet ihr den aktuellen Wert in der Datenbank intakt lassen. Dann könnt ihr einen von mehreren Filtern verwenden, um den Pfad zum Template zu überschreiben. Dies ist einer der Filter, den ihr nutzen könnt:

function child_theme_overwrite_page_template( $template ) {
	if ( get_parent_theme_file_path( '/page-templates/tpl-hero-light.php' ) === $template ) {
		return get_theme_file_path( '/page-templates/tpl-hero.php' );
	}

	return $template;
}

add_filter( 'template_include', 'child_theme_overwrite_page_template' );

In diesem Beispiel würde also jede Seite, die das Template page-templates/tpl-hero-light.php aus dem Parent-Theme verwenden würde, stattdessen das Template page-templates/tpl-hero.php aus dem Child-Theme verwenden.

Fazit

Während es sehr einfach ist ein Seiten-Template in einem Child-Theme hinzuzufügen oder zu überschreiben ist es nicht so einfach eines zu deaktivieren. Aber da WordPress normalerweise für jede gewünschte Anpassung einen passenden Filter anbietet, ist es auch nicht wirklich schwer.

Plugins und Themes mit WordPress 5.5 aktualisieren oder zurücksetzen

Die aktuelle WordPress Hauptversion 5.5 wurde Mitte August veröffentlicht. Es gab viele schöne neue Funktionen. Aber eine davon wurde nur in wenigen Beiträgen zur neuen Version erwähnt. Die Möglichkeit ein installiertes Plugin oder Theme durch das Hochladen einer ZIP-Datei zu ersetzen.

Einige bisherige Möglichkeiten, um installierte Plugins oder Themes zu ersetzen

In WordPress ist es wirklich sehr einfach eine Plugin oder Theme auf die neueste Version zu aktualisieren (zumindest für solche, die auf WordPress.org verfügbar sind). Das Zurücksetzen auf eine ältere Version oder das aktualisieren einer Premium-Version ist nicht ganz so einfach.

Mit der WP-CLI

Falls du die WP-CLI verwendest, kannst du den install Befehle für Plugins oder Themes verwenden und dabei eine spezifische Version installieren. Falls das Plugin oder Theme bereits installiert ist, kann man die Installation erzwingen:

wp plugin install gutenberg --version=8.9.0 --force

Dies überschreibt die aktuell installierte Version mit der angegebenen Version. Möglich ist das aber nur für Plugins und Themes aus den WordPress.org Verzeichnissen.

Hochladen einer alten Version mit SFTP/FTPS/FTP

Wenn du keinen SSH-Zugang zum Server hast oder dort die WP-CLI nicht verwenden kannst, dann ist die Übertragung mit einem FTP-Programm eine Alternative. Hierzu löscht man zuerst die aktuelle Version und ersetzt sie dann mit der alten Version. Dies hat aber den Nachteil, dass während der Übertragung der Dateien, was je nach Größe eine Zeit lang dauern kann, die Seite eventuell Fehler produziert. Man kann diese Ausfallzeit ein wenig reduzieren, indem man die alte Version in einen anderen Ordner hochlädt, dann die aktuelle Version löscht und schließlich den zuvor hochgeladenen Ordner umbenennt. Aber diese Weg ist nicht wirklich ideal.

Deaktivieren und Deinstallieren der aktuellen Version

Manche von euch haben jetzt vielleicht die Idee, einfach die aktuelle Version zu deaktivieren und deinstallieren, um anschließend die alte Version zu installieren. Aber das ist sehr gefährlich. Viele Plugins löschen ihre Einstellungen, wenn sie deaktiviert/deinstalliert werden. Manche löschen sogar all ihre Daten. Dieser Weg sollte also vermieden werden.

Ersetzen der aktuellen Version mit der neuen WordPress 5.5 Funktion

Falls ihr eure Seite schon auf WordPress 5.5 aktualisiert habt, könnt ihr den neuen Weg versuchen. Hierzu müsst ihr einfach die alte Version als ZIP-Datei hochladen. Diese habt ihr entweder in einem Backup oder ihr ladet sie aus dem Plugin- oder Theme-Verzeichnis von WordPress.org runter.

Download einer alten Version of eines Plugins

Für Plugins ist das sehr einfach. Hierzu navigiert ihr auf die Plugin-Seite auf WordPress.org und klickt auf den Link „Erweiterte Ansicht“ auf der rechten Seite:

Auf der folgenden Seite scrollt ihr dann ganz ans Ende. Dort findet ihr ein Auswahl von ältere Versionen. Dass sind all die Versionen, die getagged/veröffentlicht wurden:

Wählt hier die gewünschte Version auf und klickt auf den Herunterladen-Button. Ihr erhaltet dann die ZIP-Datei für diese Version. Falls im Auswahlfeld keine älteren Versionen verfügbar sein, dann wurden leider keine explizit veröffentlicht.

Hochladen der alten Version und ersetzen der aktuellen Version

Jetzt könnt ihr die Version hochladen. Das funktioniert genau so wie bei der ersten Installation eines Plugins oder Themes. Navigiert also im Dashboard zu „Plugins | Installieren“ und klickt dort auf den „Plugin hochladen“ Button neben der Überschrift. Auf der nächsten Seite könnt ihr dann die zuvor heruntergeladene Datei auswählen und mit einen Klick auf „Jetzt installieren“ hochladen. Anschließend solltet ihr folgendes sehen:

Auf der Seite seht ihr eine Übersicht zur aktuell installierten und zur hochgeladen Version. Für beide wird euch angezeigt, welche Versionen von WordPress und PHP jeweils erforderlich sind. Wenn ihr fortfahren wollt, klickt einfach auf den „Ersetze bestehendes mit hochgeladenem“ Button.

Fazit

Manchmal sind es die kleinen Änderungen in einer neuen Version, die einen Großen Unterschied machen. Das Zurücksetzen eines Plugins oder Themes war bisher keine einfache Aufgabe. Wenn allerdings deine Seite nach einem Update nicht mehr funktioniert hat, gab es die Notwendigkeit ein Plugin oder Theme zurücksetzen zu können. Mit der neuen Funktion ist das nun sehr viel einfacher. Aber auch die Aktualisierung einer Premium-Version eines Plugins oder Themes, die sich nicht in den Update-Mechanisum von WordPress integrieren, wird hiermit sehr viel einfacher.

Beitragsnavigation nach Namen sortieren

Bei vielen Kundenprojekten gibt es die Notwendigkeit eigene Inhaltstypen zu hinzuzufügen. In der Regel erstelle ich diese über den wp scaffold post-type Befehl der WP-CLI. Das erstellt die notwendigen PHP Funktionen inkl. eines Arrays von Labels, die dann übersetzt werden können. In der einfachsten Form kann man einen eigenen Inhaltstyp wie folgt registrieren:

function optn_register_post_type() {
	register_post_type(
		'sponsor',
		array(
			'label'       => __( 'Sponsor', 'optn' ),
			'public'      => true,
			'has_archive' => true,
			'show_ui'     => true,
		)
	);
}
add_action( 'init', 'optn_register_post_type' );
Weiterlesen →

Organisation von WordCamps in Zeiten einer weltweiten Pandemie

Vor etwa drei Wochen haben die Global Leads, der Local Lead und die Mentorin des WordCamp Europe 2021 die schwierige Entscheidung getroffen, das Vor-Ort-Event 2021 in Porto um ein weiteres Jahr zu verschieben und auch das nächste WCEU online zu veranstalten. Nach einem sehr erfolgreichen Event in diesem Jahr wird das neue Organisationsteam die Chance haben, ein noch größeres Event im nächsten Jahr zu veranstalten, da sie mehr Zeit haben werden sich auf die speziellen Anforderungen an ein Online-Event einzustellen. Ich wünsche dem neuen Team das Allerbeste – dem ich nicht angehören werde.

Weiterlesen →

Verwendung von Startup-Tasks als Ersatz für File-Watcher in PhpStorm

Vor einigen Tagen habe ich ein neues Projekt begonnen und ein Theme mit Underscores als Basis-Theme entwickelt. Dabei verwende ich immer die „sassified“ Version und erstelle das Theme über den WP-CLI Scaffold-Befehl. Als ich mir danach die Dateien angesehen habe, ist mir aufgefallen, dass es eine paar neue Dateien im Verzeichnis gibt. Einige Dateien, die allerdings schon einige Zeit enthalten ist, war die package.json Datei, in der verschiedene npm Tasks definiert sind, die für die Kompilierung von Sass-Dateien bzw. die Überwachung von Veränderungen an diesen zuständig sind.

Verwendung von File-Wachtern in PhpStorm

In der Vergangenheit habe ich File-Watcher verwendet und in einem früheren Beitrag erklärt, wie man diese nutzen kann um Sass-Dateien zu kompilieren. Das ist ein guter Weg, wann man keinen anderen Mechanismus in der Software oder dem Theme/Plugin enthalten ist, der sich darum kümmert. Wenn man aber an etwas entwickelt, das einen solchen Task mitbringt, dann machen es File-Watcher schwieriger, vor allem, wenn man in einem Team an dem Projekt arbeitet und jeder ein anderes Betriebssystem und andere Kompiler verwendet. In der Vergangenheit habe ich den empfohlenen Ruby-Compiler verwendet, der allerdings seit März 2019 als veraltet gilt. Seitdem werden entweder Dart Sass oder Lib Sass für die Kompilierung empfohlen. Ich habe zuletzt Dart Sass verwendet, da es der einzige Compiler war, der unter Windows, Linux und Mac in meinen Tests identische CSS-Dateien erstellt hatte.

Wieso sollte man also nicht einfach einen der neuen Compiler in PhpStorm in Kombination mit File-Watchern verwenden? Nun, hierzu gibt es zwei Gründe. Zum einen sind die File-Watcher nicht einfach einzurichten, vor allem dann nicht, wenn die Ordnerstruktur nicht dem Standard entspricht. So befindet sich zum Beispiel bei Underscores die style.scss Datei im Unterordner sass, die style.css Datei allerdings im Hauptordner. Der zweite Grund ist, dass in der package.json eventuell nicht nur Tasks zum Kompilieren von Sass-Dateien definiert sind. Ein häufiges Beispiel sind hier PostCSS Plugins, wie etwa der Autoprefixer. Diese Compiler würden beim File-Watcher in PhpStorm nicht ausgeführt werden.

Ausführen eines Watchers aus der package.json Datei

Man kann einen npm (oder ähnlichen) Task in PhpStorm auf zwei Wege ausführen. Entweder startet man ein Terminal und führt den Befehl dort aus (was den Befehl aber beendet, sobald man das Terminal schließt) oder aber man verwendet „Task | Run Gulp/Grunt/npm Task“ aus der Menüzeile:

Screenshot des "Run npm Task" Fensters

Hier macht man einfach einen Doppelklick auf den Task, den man ausführen möchte und dieses startet in einem neuen Fenster innerhalb von PhpStorm. Allerdings muss man nun jedes Mal, bevor man mit der Arbeit an einem Projekt beginnt, daran denken, den Task manuell zu starten, währen ein File-Watch automatisch „starten“ würde. Gibt es also einen besseren Weg?

Verwendung eines Startup-Starts für den Watcher

Glücklicherweise gibt es einen sehr einfachen Weg, den ich vor ein paar Wochen gefunden habe. Man kann Startup-Tasks definieren, die jedes Mal ausgeführt werden, wenn man ein Projekt in PhpStorm öffnet. Hierzu wählt man in den Settings den Punkt „Tools | Startup Tasks“ und kann dann hier aus einer Vielzahl von Tasks auswählen. Einer davon ist npm. Hier erstellt du zuerst einen solchen Startup-Task:

Screenshot des "Settings | Tools | Startup Tasks" Fensters mit "npm" ausgewählt als neuem Task

Falls du wie zuvor beschrieben den npm Task schon einemal manuell ausgeführt hast, dann kannst du ihn auf der linken Seite einfach direkt auswählen. Ansonsten erstellst du einfach einen neuen Task, gibst ihm einen Namen, wählst die pcackage.json Datei aus und davon dann den passenden Task für den Start:

Screenshot of the npm run configuration setting

Wenn du das alles eingestellt hast, kannst du PhpStorm neu starten oder das Projekt schließen und wieder öffnen, um den Startup-Task zu testen. Du solltest hierbei dann das gleiche Fenster wie beim manuellen Ausführen sehen.

Fazit

Die File-Watcher in PhpStorm sind wirklich sehr nützlich, wenn du an einem Projekt arbeitest, das keine Task-Runner verwendet. Aber sie sind recht limitiert und nicht einfach einzurichten. Die Verwendung von Startup-Tasks ist sehr viel einfacher, wenn das Projekt bereits Tasks mitbringt und es stellt sicher, dass alle im Team die gleichen Tasks verwenden. Das kann erheblich die Fehlersuche verringern oder das Auflösen von Merge-Konflikten vermeiden, falls Dateien mit unterschiedlichen Compilern erstellt wurden.

Speicherplatz in deinem Entwicklungsordner frei machen

Selbst die größte Festplatte hat ein Limit. Von Zeit zu Zeit muss man daher aufräumen, um wieder Platz für neue Projekte zu haben.Wenn gleichzeitig an einer Vielzahl von WordPress Projekten arbeite, alten und neuen, kommt schnell einiges zusammen. In einem früheren Blogbeitrag habe ich euch gezeigt, wie man Speicherplatz sparen kann, indem man Bilder von einem Live-Server lädt. Da Bilder und andere Dateien im Uploads-Ordner oft den größten Teil einer WordPress-Website ausmachen, kann man hierdurch schon viel einsparen. Aber es gibt noch andere Arten von Dateien, die sehr schnell die Festplatte füllen: Datenbank-Dumps.

Große Datenbank-Dumps finden

Wenn du an Projekten arbeitest, die bereits Live gegangen sind, dann möchtest du dir sicher die aktuellen Datenbank von der Live-Seite holen, bevor du mit der Arbeit beginnst. Aber vielleicht hast du vorher Änderungen in der lokalen Datenbank gemacht, die du nicht verlieren möchtest, also machst du ein Backup, bevor du die Datenbank mit der Live-Datenbank überschreibst. Das sind also schon zwei Dumps. Während du an der Seite arbeitest und Dinge veränderst oder löschst, machst du nochmal zu Sicherheit ein Backup. Und da manche WordPress-Datenbanken auch mal mehrere hundert Megabyte groß sein können, kommt schnell einiges an verbrauchtem Speicherplatz zusammen. Der erste Schritt zum Freimachen ist es also, diese großen Datenbank-Dumps zu finden. Hierzu führst du einfach folgenden Befehl in deinem Entwicklungsordner aus:

find . -type f -size +10M -name "*.sql"

Dieser Befehl findet alle SQL-Dumps, die größer als 10 MB sind. Unter Umständen möchtest du sogar nach noch kleineren Dateien suchen, wenn es viele davon gibt, die ebenfalls in Summe mehrer hundert Megabytes groß sind. Wenn du die Dateien nicht nur finden, sondern auch sehen möchtest, wie groß sie sind, dann kannst du den Befehl ergänzen und die gefundenen Dateien an den du Befehl weitergeben:

find . -type f -size +10M -name "*.sql" -exec du -h "{}" \;

Nachdem du nun alle großen Dateien gefunden hast kannst du diejenigen löschen, die du nicht mehr brauchst. Aber was ist, wenn du sie noch immer brauchst?

Alle Datenbank-Dump komprimieren

Nun, das ist ganz einfach. Du verwendest einfach einen anderen Befehl und komprimierst alle Dateien in einem Durchlauf. Hierzu verwendet du einfach folgenden Befehl:

find . -type f -size +10M -name "*.sql" -exec gzip "{}" \;

Dieser Befehl komprimiert also alle Datenbank-Dump, die größer als 10 MB sind, mit dem gzip Befehl. Als ich diesen Befehl vor einigen Tagen auf meinem Arbeits-Laptop ausgeführt habe, konnte ich mehr als 3,5 GB auf der Festplatte frei machen. Der Befehl hat dazu nur etwa 90 Sekunden benötigt. Wenn ich nun einen der Dumps wieder einspielen möchte, dann muss ich ihn nur mit dem Befehl ungzip wieder enpacken, bevor ich ihn in die Datenbank importiere.

Andere große Dateien finden

Nachdem du alle Datenbank-Dumps komprimiert hast, könntest du doch gleich mal nach anderen großen Dateien such, die du einfach löschen oder komprimieren kannst. Gute andere Kandidaten sind hier etwa das debug.log im wp-content Ordner, wenn du bei einer Installation mal das WP_DEBUG_LOG aktiviert hattest. Um solche Dateien zu finden, kannst du entweder das Suchmuster anpassen oder einfach ganz weglassen, um alle großen Dateien zu finden:

find . -type f -size +10M -exec du -h "{}" \;

Wenn du ohne eine Dateiendung suchst, wirst du vermutlich auch Mediendateien finden. Dann kannst du den Trick verwenden, den ich zuvor erwähnt habe und die Dateien einfach von einem Remote-Server laden lassen.

Eventuell findest du auch XML-Dateien, die sehr groß sind. Diese könnten beispielsweise vom WordPress XML Exporter stammen. Es könnten aber auch andere Dateien sein, die eventuell unkomprimiert belassen werden müssen.

Einschränkung

Vielleicht fragst du dich nun „wieso komprimiere ich nicht einfach alle .sql Dateien?“, aber das verursacht eventuell Probleme. Wenn du die Suche mal ohne Filter nach der Dateigröße durchführst, dann wirst du vermutlich auch SQL-Dateien in Plugin-Ordnern finden. Diese Dateien werden in der Regel verwendet um notwendige Tabellen beim Installieren oder Aktivieren von Plugins anzulegen und dürfen daher nicht komprimiert werden. Verwende also keine zu kleine Dateigröße, wenn du die Datenbank-Dumps auf deinem System komprimierten willst. Auf meinem System hätte selbst eine minimale Dateigröße von 1 MB nur Datenbank-Dumps gefunden und keine dieser speziellen Dateien. Die gleiche Einschränkung gilt aber auch für einige XML-Datien und auch für Log-Dateien. Ist eine solche Datei komprimiert, kann nicht mehr darin geschrieben werden. Also komprimiere nicht einfach alle Textdateien, die zu groß sind.

Fazit

Wenn man an vielen Projekten arbeite ist der Speicherplatz schnell verbraucht. Zu wissen, wie man schnell wieder Speicherplatz freigeben kann ist daher wichtig, vor allem dann, wenn man die Festplatte im Gerät nicht einfach durch eine größere austauschen kann. Mir hat es in der Situation sofort geholfen, erst einmal alle Datenbank-Dump zu komprimieren und ich musste mir auch nicht lange Gedanken darüber machen, welche Dateien ich noch brauche und welche nicht.

Den Markdown-Editor in PhpStorm reparieren

Bereits in früheren Beiträgen habe ich sicher schon erzählt, dass ich mit PhpStorm arbeite, wenn ich Webseiten entwickle. Vor ein paar Wochen bekam ich jedes Mal, wenn ich versucht hatte eine Markdown-Datei zu öffnen, die folgende Fehlermeldung angezeigt:

PhpStorm "Error" Dialog: "Tried to use preview panel provider (JavaFX WebView), but it is unavailable. Reverting to default."

Da ich Markdown sehr häufig in einem einfachen Text-Editor schreibe und daher kein Plugin für Syntax-Highlighting oder eine Vorschau braucht, habe ich das Markdown-Plugin einfach deaktiviert.

Bei der Arbeit in der letzten Woche an einem WordPress-Plugin wollte ich einige Zeilen im Text mit einem Zeilenumbruch trennen. Hierzu muss man ans Ende jeder Zeile zwei Leerzeichen einfügen. Aber sobald ich die Datei commiten wollte, hat die Code-Bereinigung von PhpStorm die „unnötigen Leerezeichen“ am Ende wieder entfernt. Daher habe ich das Plugin wieder aktiviert, musste aber feststellen, dass es noch immer defekt war.

Lösen des Problems

Eine schnelle Suche nach dem Problem brachte mich zu einem Support-Ticket und hier fand ich den Hinweis, dass es an JRE Version liegen könnte, die PhpStorm verwendet. Wenn man mehrere JRE Versionen installiert hat, dann kann man über ein Plugin auswählen, welche verwendet werden soll. Jetbrains, der Hersteller von PhpStorm empfiehlt, eine spezielle JRE Version von Jetbrains zu verwenden.

Ich arbeite aktuell mit Manjaro Linux auf meinem Arbeitslaptop, also habe ich dort einfach mal in der Paketverwaltung gesucht und folgendes Paket gefunden:

Installation dialog for "phpstorm-jre 2020", the patched JRE for PhpStorm

Nachdem ich die gepatchte JRE Version installiert und PhpStorm neu gestartet hatte, konnte ich alle Markdown-Dateien wieder wie gewohnt öffnen. Beim Versuch die Markdown-Datei zu commiten wurden auch die zwei zusätzlichen Leerzeichen am Ende der Zeilen nicht mehr entfernt.

Fazit

Manchmal erscheint eine schnelle Lösung wie die Deaktivierung eines Plugins die Lösung für ein Problem zu sein. Aber manchmal handelt man sich damit unerwünschte Seiteneffekte ein. Es lohnt sich also manchmal doch, ein wenig Zeit zu investieren und tiefer nach der Lösung eines Problems zu lösen, denn am Ende wird hiermit das eigentliche Problem sehr viel besser gelöst.

Prost! Die Schnappszahl ist auch erreicht!

Eigentlich wäre ja heute (bzw. diese Kalenderwoche) wieder zurest ein englischer Artikel dran, den ich dann in der nächsten Woche übersetzte. Aber wie es der Zufall will ist es heute mal wieder so weit und mein Blog feiert Geburtstag. Vor genau 11 Jahren habe ich mit dem bloggen angefangen. Darauf habe ich heute angestoßen, aber nicht mit Schnapps, sondern einem alkoholfreien Cocktail.

Wieder mehr Aktivität

Ich habe ja schon in meinem letzten Beitrag von den verrückten letzten Monaten erzählt. Aber ich habe es irgendwie dennoch geschafft in all der Zeit wieder regelmäßig zu bloggen. Ende letzten Jahres hat Torsten zum #projekt26 aufgerufen und ich bin den Ruf gefolgt. Zu Beginn habe ich mich noch bezüglich der Regeln gefragt, ob es eigentlich ausreichen würde, wenn ich nur alle zwei Wochen in einer der beiden Sprachen blogge, mich dann aber dazu entschlossen einfach ein #projekt26 und ein #project26 zu machen, also jeweils auf Deutsch und Englisch zu bloggen, um weiterhin geübt darin zu bleiben. Und ich habe wieder mit der englischen Sprache begonnen, wie auch schon 2017. Nach dem WordCamp Europe 2019, an dessem zweiten Tag das neue „Blog-Jahr“ anfing, habe ich allerdings sehr wenig gebloggt. Ich kam gerade einmal auf je zwei Beiträge Anfang Dezember, als ich noch dachte, ich könnte einen Adventskalender starten, was ich aber sehr schnell aufgeben musste. Daher kam mir dann aber die Idee von Torsten sehr gelegen.

Seit Jahresbeginn habe ich also jede Kalenderwoche einen neuen Beitrag geschrieben und somit je 12 englische und 12 deutsche. Da dieses Jahr 53 Kalenderwochen hat passt es auch ganz gut, dass ich den Geburtstagsbeitrag einfach dazwischenschieben kann?

Ich bin sehr guter Dinge, dass ich es wieder bis zum Ende durchhalten werde. Ob es aber wieder einen Adventskalender geben wird, muss ich noch schauen. In der Zeit stecke ich dann wieder voll in der Organisation des WordCamp Europe drin, das dann hoffentlich endlich in Porto stattfinden kann.

Zahlen, Zahlen, Zahlen …

Nachdem ich euch im letzten Jahr die Zahlen vorenthalten habe, da ich ja zwischen 21. Juni 2018 und 21. Juni 2019 nicht einen Beitrag geschrieben habe, möchte ich euch wieder wie gewohnt ein paar Statistiken liefern.

Einen neuen Besucherrekord gab es nicht. Interessant beim Blick auf die Zahlen ist der 5. Mai, da hier um 11 Uhr über 150 Zugriffe registriert wurden. So wirklich erklären kann ich mir das aber nicht, da sch die Zugriffe auf mehrere beliebte Blogbeiträge verteilen. Womit wir auch schon beim nächsten Thema wären, denn die Top-Beiträge aus dem letzten Jahr waren auch an diesem Jahr unter den besten vier Beiträgen. In die Top 3 der letzten 12 Monate haben es folgende Beiträge geschafft:

Top3 im letzten Jahr

  1. Formatierten Quellcode mit Syntaxhervorhebung in Word einfügen
  2. Fehler beim Senden in Contact Form 7 debuggen
  3. Arrays und andere komplexe Daten mit PHP in einer MySQL-Datenbank speichern

Die besten drei sind auch weiterhin in der Liste, allerdings gab es einen Wechsel bei den Plätzen 2 und 3. Etwas erschrocken bin ich nur, dass unter den Top10 noch immer Beiträge zu veralteten Technologien sind?

Es gab 34 neue Kommentar dazu, wovon 10 von mir waren. Ich hatte durch die neuen Regeln des #projekt26 gehofft, dass das noch ein paar mehr wären. Aber das Jahr ist ja noch nicht einmal halb vorbei?

Wie geht es weiter?

Natürlich höre ich nach 11 Jahren nicht auf, auch wenn eine solche Schnappszahl dazu verleiten könnte. Aber das Dutzend mache ich sicher noch voll und auch dann denke ich noch lange nicht ans Aufhören. Wenn erst einmal meine Laufbahn als WordCamp Europe Organizer vorbei ist, habe ich ja noch mehr Zeit zum Bloggen. Aber auch andere Projekte sind in der Planung. So werde ich natürlich weiterhin den capital_P_odcast zusammen mit Maja aufnehmen. Erst heute haben wir nach langer Pause wieder eine Folge aufgenommen. Aber ich habe auch gerade ein Plugin geschrieben, das ich bald auf die Welt loslassen werde. Ein Traum von mir wäre aber ein Online-Videokurs zu einem WordPress-Thema. Worum es dabei geht werde ich aber erst verraten, wenn es soweit ist. Da ich aber nicht davon ausgehe, dass ich bis zum WCEU 2020 dafür viel Zeit haben werde, gibt es hier wohl maximal ein paar Ausschnitte bleibt also gespannt. Die Zeit bis dahin dürft ihr auch gerne damit verbringen bei mir und allen anderen Teilnehmenden am #projekt26 ein paar Kommentare zu hinterlassen?

Ach ja, bevor ich es vergesse. An dieser Stelle kommt ja immer ein witziges Video. Und wie könnte es auch anders sein, geht es hier um Corona. Ob die Macher des Videos wohl wussten, dass die „Juni-Version“ gar nicht mal so weit von der Realität entfernt liegt?

Hier klicken, um den Inhalt von YouTube anzuzeigen.
Erfahre mehr in der Datenschutzerklärung von YouTube.

WordCamp Europe 2020 – Eine unerwartete Reise

Letztes Wochenende endete die achte Ausgabe des WordCamp Europe. Und es war eine beeindruckende Erfahrung. Ich hatte das Vergnügen erneut als Organisator mitzuwirken, aber das Ergebnis war ein ganz anderes als ich erwartet hätte.

WordCamp Europe Porto 2020

Die Reise begann vor 12 Monaten in Berlin. In den „Closing Remarks“ des WCEU 2019 kündigten wir an, dass es im nächsten Jahr nach Porto gehen würde. Ich habe mich erneut bereit erklärt, im vierten Jahr in Folge, als Organisator mitzuhelfen, in der Rolle eines Global Lead. Aber nicht alleine, ich arbeitete Seite and Seite mit Tess und Jonas. Aber das erste Mal in der Geschichte des WCEU, starteten wir mit drei Global Lead Organizern. Das Team wäre aber nicht vollständig ohne José Freitas, den Local Team Lead für Porto

Im September endete unser Call for Organizers und unser Team aus 72 Freiwilligen aus der WordPress Community war ausgewählt und wir konnten mir der Arbeit an einem Event für etwa 3500 Teilnehmende starten. Es würde meine erste Reise nach Porto und auch die erste nach Portugal werden. Doch dann begannen sich Dinge zu verändern.

Die Absage des WordCamp Asia

Der COVID-19 Ausbruch hatte gerade erst begonnen und am 12. Feburar, nur etwas eine Woche vor dem Event, wurde das WordCamp Asia auf das Jahr 2021 verschoben. Das war nicht nur ein Schock für die globale WordPress Community, sondern auch für uns als Organisationsteam des WordCamp Europe. Da wir Event nur dreieinhalb Monate später veranstalten wollten, konnten wir noch nicht absehen, ob es wie geplant stattfinden lassen könnten. Die nächsten Wochen waren sehr intensiv. Andere Events wurden ebenfalls verschoben und es wurde immer klarer, dass wir etwas unternehmen mussten. Letztendlich mussten wir am 12. März, einen Monat nach dem WordCamp Asia ebenfalls entscheiden, das WordCamp Europe in Porto auf 2021 zu verschieben. Es war eine der schwersten Entscheidungen, die wohl jeder WordCamp Europe Organizer jemals treffen mustte. Aber die Unterstützung der WordPress Community für unsere Entscheidung war überwältigend.

Alles zurück auf Anfang

Als wir die Entscheidung für die Verschiebung des „vor-Ort-Events“ beschlossen haben, wurde auch gleich die Entscheidung getroffen, das Event stattdessen online stattfinden zu lassen. Bis zu diesem Tag wurde noch kein WordCamp, das abgesagt wurde, direkt auf ein Online-Event verschoben. Es gab also eine Erfahrungen in der Community, wie man ein Event einer solchen Größe am besten online umsetzt. Wir mussten im Grunde die Arbeit am lokalen WordCamp stoppen und ganz von vorne beginnen, ein völlig anderes Event zu veranstalten.

Obwohl die Entscheidung durch das gesamte Organisationsteam getroffen wurde, konnten einige aus verschiedenen Gründen nicht dabei helfen, das Online-Event zu veranstalten. Da leider sowohl Tess, als auch Jonas nicht als Global Lead weitermachen konnten, wurde ich von Rocío Valdivia unterstützt, die zuvor unser Mentor war und nun zusammen mit mir das Global Lead Team stellte. Wir wurden von 31 weiteren Organizern unterstützt, die sich in neuen Team zusammenfanden.

Group photo of the WCEU 2020 Online organising team
Das WordCamp Europe 2020 Online Organizsationsteam

Dies war der Start des ersten WordCamp Europe Online und ein neuer Meilenstein für die Community und viele von uns.

Drei Monate Leidenschaft und harte Arbeit

Ein WordCamp Europe in neun Monaten zu organisieren ist verdammt viel Arbeit. Ein Online-Event dieser Größe in weniger als drei Monaten zu organisieren, ist sehr viel schwieriger. Mit der Leidenschaft, Hingabe und harten Arbeit eines tollen Teams haben wir es geschafft ein Event zu organisieren, das hoffentlich eine Inspiration für nachfolgende Online-WordCamps sein wird.

Wir haben sehr viel Hilfe von anderen WordCamp-Organisationsteams bekommen. Das Team des WordCamp Asia hat uns gezeigt, wie man mit der Verschiebung eines Events umgeht, das Team des WordCamp Spain hat ein echtes Community-Event organisiert und uns gezeigt, welche Dinge, die wir geplant hatten, noch einmal überdenken sollten, da wir einige der tollen Ideen übernehmen wollten. Und auch andere WordCamps auf der ganzen Welt hatten einige einmalige Dinge, von denen wir uns haben inspirieren lassen.

Das größte Wor(l)dCamp allerzeiten

Alle, die schon einmal ein WordCamp organisiert haben werden die Erfahrung gemacht haben, dass es von externen Dienstleistern oft als „WorldCamp“ falsch geschrieben wird. Dieses Mal traf diese Bezeichnung absolut zu. Auch wenn der Fokus auf der europäischen Community liegt, wollten wir so vielen Teilnehmenden wie möglich die Teilnahme ermöglichen. Daher habe wir die Zeiten auf 15:00 bis 20:00 Uhr mitteleuropäische Sommerzeit für alle drei Tage gelegt. So konnten Teilnehmende aus Europe an einem Nachmittag teilnehmen, ohne unbedingt Urlaub nehmen zu müssen. Aber auch Teilnehmenden auf beiden Seiten des Pazifiks war hierdurch eine Teilnahme am frühen morgen oder späten Abend möglich.

Für das WordCamp in Porto hätten wir mit 3500 verkauften Tickets und mehr als 3000 Personen vor Ort gerechnet. Letztes Jahr hatten wir mehr als 3000 Tickets verkauft und konnten mehr als 2700 Teilnehmende begrüßen, die aus über 90 Ländern kamen. Dieses Jahr haben wir mehr als 8600 Tickets für den Live-Stream verkauft und in den ersten 24 Stunden gab es mehr als 9000 Aufrufe für Track 1 der Vorträge vom Freitag – einige davon im Live-Stream und andere zeitversetzt in der Aufzeichnung. Aber die Zahl, die am meisten beeindruckte, war die Anzahl von unterschiedlichen Ländern der Anmeldungen. Wir hatten Teilnehmende aus 140 Ländern, also wirklich ein „WorldCamp“:

Weltkarte der Teilnehmenden des WordCamp Europe 2020 Online

Eine Erfahrung, die ich niemals erwartet hätte

Ich habe bisher an jedem WordCamp Europe teilgenommen und bin seit 2017 im Organisationsteam aktiv. Als wir letztes Jahr das Event in Berlin hatten, fühlte es sich für mich ganz anders an. Dieses Jahr war der Unterschied noch sehr viel größer. Normalerweise reise ich ein paar Tage vorher in ein fremdes Land und verbringe Zeit mit alten und neuen Freunden. Dieses Jahr mussten wir alle von unseren eigenen vier Wänden aus teilnehmen und organisieren. Alle haben den persönlichen Kontakt mit anderen vermisst. Aber die Rückmeldungen aus der Community waren überwältigend!

Ein riesengroßer Dank an die Commmunity!

Ich kann noch nicht in Worte fassen, wie ich mich fühle. Auch eine Woche nach dem Event noch nicht. Die Erfahrung ist noch immer sehr frisch und schwer zu beschreiben. Aber mehr als alles andere fühle ich tiefe Dankbarkeit. Für meine Co-Organizer, für die COmmunity, die an den Vorträgen und am Contributor Day teilgenommen haben, für die Speaker, die „Emcees“ und die anderen Freiwilligen, für die Sponsoren, die geholfen haben, das Event zu finanzieren und auch für alle anderen Personen und Organisationen, die dabei geholfen haben, all dies zu ermöglichen. Auch wenn wir nicht die Möglichkeit hatten und mit Freunden zu treffen, haben wir so vielen Menschen mehr ermöglich, daran teilzunehmen.

Wir sehen uns 2021 in Porto!

Ich hoffe, dass viele von euch letzte Woche beim WCEU 2020 Online dabei waren. Nächstes Jahr werden wir dann hoffentlich die Gelegenheit haben, uns endlich in Porto zu treffen. Ich werde erneut Teil des Organisationsteams als Global Lead sein. Ich werde hierbei mit Lesley, Taeke und Moncho zusammenarbeiten. Falls auch ihr nun Lust bekommen habt dabei zu helfen, ein solches Event zu veranstalten, dann antwortet auf den Call for Organizers. Und falls ihr nur teilnehmen wollt, dann sichert euch schon heute euer Ticket.

Bis nächstes Jahr beim WordCamp Europe im June 2021 in Porto!

Schnellere lokale Entwicklung durch die Blockierung externen Requests

Ich entwickle Seiten immer lokal. Bei der Entwicklung verwende ich dabei Docker was ich in einer zukünftigen Blogreihe vorstellen möchte. Manchmal erlebe ich bei der lokalen Entwicklung sehr lange Request-Zeiten, vor allem im Backend. Da ich normalerweise während der Entwicklung immer das Query Monitor Plugin einsetze, konnte ich schnell feststellen, dass es an einigen HTTP Requests lag, die fehlschlugen. Dieser wurden entweder vom Core oder Premium Plugins/Themes ausgelöst, die nach Updates gesucht haben.

Externe Requests blockieren

Um diese Fehler zu beheben habe ich zuerst einzeln Filters oder Actions deaktiviert, die diese Requests auslösen. Dann bin ich aber auf einen globalen Filter gestoßen, der das noch vereinfacht:

add_filter( 'pre_http_request', '__return_true', 100 );

Das ist nicht der einfachste oder beste Weg, denn er blockiert sämtliche Requests, egal auf welchen Host sie zugreifen. Um nur externe Requests zu blockieren, kann man stattdessen einfach folgende Konstante setzen:

define( 'WP_HTTP_BLOCK_EXTERNAL', true );

Das blockiert keine lokalen Requests, die eventuell für Cronjobs oder ähnliche Funktionalitäten gebraucht werden.

Bestimme externe Hosts erlauben

Manchmal kann man aber nicht einfach alle externen Requests blockieren, da einige Plugins/Themes, die man gerade entwickelt, externe APIs verwenden. Daher kann man mit einer anderen Konstante über eine kommagetrennte Liste diese Hosts definieren:

define( 'WP_ACCESSIBLE_HOSTS', 'example.com, *.example.com' );

Wie ihr in meinem Beispiel sehen könnt, sind auch Wildcard-Subdomains möglich. Hierbei wird über einen regulären Ausdruck das Suchmuster auf eine beliebige Tiefe an Subdomains geprüft.

Mehr als nur HTTP Requests blockieren

Die beiden Konstanten helfen dabei HTTP Requests zu blockieren, die durch WordPRess ausgelöst werden. Dies funktioniert aber nur, wenn diese die WordPreSS API Funktionen für HTTP Requests verwenden. Wenn ein Plugin/Theme allerdings mit file_get_contents, curl oder ähnlichem arbeitet, werden solche Requests nicht blockiert.

Weiterhin werden auch keine Requests blockiert, die vom Browser aus gemacht werden. Wenn man auch solche Requests blockieren will, dann kann man das Plugin „Offline Mode“ von Frank Bültge einsetzen, das man direkt von GitHub aus runterladen und installieren kann. Es versucht so viele externe Requests wie möglich zu blockieren.

Fazit

Lokal zu entwickeln ist immer der beste Weg, wenn man an einem Projekt arbeitet. Sollte man aber eine instabile Internetverbindung haben (oder gar keine, wie z.B. im Flugzeug), dann kann das die lokale Entwicklung extrem verlangsamen. Mit Hilfe der beiden vorgestellten Konstanten mann man die gewohnte Geschwindigkeit wieder zurückholen.