Änderungen an PHP ini Werten machen, ohne dass diese bei einem Update verloren gehen

Wenn ihr schon einmal selbst einen Server aufgesetzt habt, dann wird euch sicher auch aufgefallen sein, dass viele Standardwerte für PHP-Variablen nicht mehr zeitgemäß für eine modere Website sind. Die upload_max_filesize ist beispielsweise auf nur 2 MB festgelegt. Ihr könnt also keine Datei, die größer als 2 MB groß ist, in die WordPress Mediathek hochladen. Diesen Wert wollt ihr also ziemlich wahrscheinlich ändern. Aber wie könnt ihr den Wert am besten ohne zu riskieren, dass eure Anpassung wieder zurückgesetzt werden, sobald ihr PHP oder den Server aktualisiert.

Ändern der globalen PHP ini Werte

Dieser Blog läuft auf einem Ubuntu 22.04 Server mit PHP-FPM und einem nginx Webserver. Wenn ich also Änderungen an einer PHP ini Variable machen möchte, dann muss ich die Änderungen in der Datei /etc/php/8.1/fpm/php.ini global vornehmen. Wie ihr im Dateipfad sehen könnt, müsste ich diese Änderungen dann in jeder php.ini Datei für jede PHP Version vornehmen. Ihr müsstet sie auch für jede „Server API“ vornehmen, wenn ihr also zusätzlich noch CGI/FastCGI für manche Seiten verwendet, dann müsstet ihr auch die Datei /etc/php/8.1/fpm/php.ini anpassen.

Der Vorteil dieser Änderung ist, dass sie für alle Seiten gilt, die auf diesem Server gehostet werden, ihr könnt hier also gute Standardwerte für jede Seite einstellen. Wenn der Paketmanager versucht, die Konfigurationsdateien zu aktualisieren, wird er Änderungen feststellen und euch fragen, ob ihr die neue Datei verwenden wollt, die alte Datei, oder ob ihr euch die Änderungen genauer ansehen und das Problem selbst lösen wollt. Abhängig davon, wie viele Änderungen ihr gemacht habt, kann das recht kompliziert werden.

Um globale Änderungen an PHP ini Werte vorzunehmen, habe ich daher eine neue Datei mit dem Namen /etc/php/conf.d/90-custom.ini erstellt, die per Symlink in den verschiedenen Konfigurationspfaden eingebunden ist:

$ tree /etc/php/   
/etc/php/
|-- 7.3
|   |-- cgi
|   |   |-- conf.d
|   |   |   |-- 10-mysqlnd.ini -> /etc/php/7.3/mods-available/mysqlnd.ini
|   |   |   |-- ...
|   |   |   `-- 90-custom.ini -> /etc/php/conf.d/90-custom.ini
|   |   `-- php.ini
|   |-- cli
|   |   |-- conf.d
|   |   |   |-- 10-mysqlnd.ini -> /etc/php/7.3/mods-available/mysqlnd.ini
|   |   |   |-- ...
|   |   |   `-- 90-custom.ini -> /etc/php/conf.d/90-custom.ini
|   |   `-- php.ini
|   |-- fpm
|   |   |-- conf.d
|   |   |   |-- 10-mysqlnd.ini -> /etc/php/7.3/mods-available/mysqlnd.ini
|   |   |   |-- ...
|   |   |   `-- 90-custom.ini -> /etc/php/conf.d/90-custom.ini
|   |   |-- php-fpm.conf
|   |   |-- php.ini
|   |   `-- ...
|-- ...
|-- 8.1
|   |-- cgi
|   |   |-- conf.d
|   |   |   |-- 10-mysqlnd.ini -> /etc/php/8.1/mods-available/mysqlnd.ini
|   |   |   |-- ...
|   |   |   `-- 90-custom.ini -> /etc/php/conf.d/90-custom.ini
|   |   `-- php.ini
|   |-- cli
|   |   |-- conf.d
|   |   |   |-- 10-mysqlnd.ini -> /etc/php/8.1/mods-available/mysqlnd.ini
|   |   |   |-- ...
|   |   |   `-- 90-custom.ini -> /etc/php/conf.d/90-custom.ini
|   |   `-- php.ini
|   |-- fpm
|   |   |-- conf.d
|   |   |   |-- 10-mysqlnd.ini -> /etc/php/8.1/mods-available/mysqlnd.ini
|   |   |   |-- ...
|   |   |   `-- 90-custom.ini -> /etc/php/conf.d/90-custom.ini
|   |   |-- php-fpm.conf
|   |   |-- php.ini
|   |   `-- ...
|-- ...
|-- conf.d
|   `-- 90-custom.ini

Da die neue Datei 90-custom.ini nicht vom Paketmanager hinzugefügt/überschrieben wird, sind sämtliche Anpassungen dazu sicher vor Upgrades.

Ändern von PHP ini Werten pro Seite

Manchmal möchte man bestimmte Seite nur für eine spezifische Seite ändern. Dann würde die Verwendung der globalen Datei nicht funktionieren. Falls ihr den Apache Webserver verwendet, dann könntet ihr eventuell die Werte über die Apache Konfigurationsdateien anpassen oder sogar die .htaccess Datei verwenden. In dieser Datei würde man dann eine Anweisung wie php_value upload_max_filesize 64M verwenden, um etwa das Upload-Limit zu erhöhen. Das funktioniert allerdings nur, wenn ihr PHP als Apachemodul einsetzt.

Wenn ihr Apache mit PHP-FPM oder einen anderen Webserver verwendet – so wie ich nginx einsetze – dann könnt ihr keine .htaccess Datei nutzen, um Änderungen an den PHP ini Werten vorzunehmen.

Verwendung der „user_ini“ Datei für Änderungen pro Seite

Glücklicherweise gibt es einen anderen Weg, um einen PHP ini Wert zu ändern. Dies kann erreicht weden, indem ihr die „user_ini“ Datei verwendet, die in der Regel im Hauptverzeichnis der Website gespeichert wird. Zuerst einmal müsst ihr herausfinden, sie diese Datei heißen muss. Dies könnt ihr mit der phpinfo() Funktion oder mit dem Befehl php -i tun und darin dann nach dem Wert von user_ini.filename suchen. Ihr erstellt dann eine Datei mit diesen Namen und macht darin die Anpassungen in der gleichen Art und Weise wie in einer php.ini Datei, wie z.B. upload_max_filesize = 64M um das Upload-Limit zu ändern.

Nachdem ihr die Änderungen gemacht habt und dann kontrolliert, ob sie funktionieren, dann wird es vermutlich nicht der Fall sein. Das heißt aber nicht, dass ihr etwas falsch gemacht habt. Es bedeutet vermutlich nur, dass die Datei noch nicht erneut vom PHP-Prozess eingelesen wurde, denn die Datei wird gecacht. Wie lange, könnt ihr über den Wert von user_ini.cache_ttl herausfinden. Dies ist die Zeit in Sekunden für das Caching der Datei. Bei einem Wert von 300 müsst ihr also bis zu 5 Minuten warten, bis die Änderungen für die Seite angenommen werden. Wenn die Änderungen sofort greifen sollen, dann müsst ihr den PHP-Prozess (wie etwa PHP-FPM) oder den Webserver (bei der Verwendung der PHP Apachemoduls) neu starten.

Fazit

Es gibt mehrere Wege Änderungen an PHP ini Werten zu machen. Wenn ihr also Anpassungen machen müsst, dann tut dies mit einer Methode, die nicht zu Problemen mit Updates führt (oder bei der eure Anpassungen bei einem Upgrade verloren gehen). Für meinen eigenen Server habe ich mich für den ersten Ansatz entschieden, der eine globale ini Datei verwendet. Die user_ini Datei hat aber den Vorteil, dass diese Seite sehr einfach zu einem neuen Server übertragen werden können, wenn ihr die Seite migriert. Sie ist also gerade dann sinnvoll, wenn das PHP-System sehr spezifische Werte benötigt.

Den Matomo Opt-out iframe reparieren, wenn sichere Server-Header verwendet werden

Letztes Jahr habe ich einen Beitrag darüber geschrieben, wie man eine Website mit sicheren Server-Headern besser schützen kann. Wenn man etwas an den Security-Headern ändert, dann besteht immer die Möglichkeit, dass Dinge nicht mehr funktionieren, da sie „weniger sichere“ Einstellungen benötigen. Eines dieser Beispiele ist der Matomo Opt-out iframe und in diesem Beitrag möchte ich euch zeigen, wie ihr das Problem lösen könnt.

Das Opt-out wird vom Browser blockiert

Wenn ihr Matomo zum Tracken einsetzt und Statistiken zu den Zugriffen auf eurer Seite erhebt, dann solltet ihr das immer in der datenschutzfreundlichsten Art und Weite tun. Ihr solltet hierzu das Tracking ohne Cookies durchführen und auch die Do-not-Track Unterstützung aktivieren. Aber selbst dann muss es möglich sein, dass jemand dem Tracking durch ein Opt-out widerspricht. Hierzu könnt ihr in den Privatsphäre-Einstellungen einen Opt-out iframe erstellen. Diesen fügt ihr dann auf eurer Datenschutzseite ein. Wenn ihr aber mit Security-Headern für Matomo macht, dann könnte es sein, dass ihr folgende Fehlermeldung im Browser seht:

Refused to display ‚https://matomo.example.com/‘ in a frame because it set ‚X-Frame-Options‘ to ’sameorigin‘.

Das passiert, wenn die Security-Header zu eng eingestellt sind und eine Einbindung der Seite auf einer anderen Domain verboten wurde.

Externe Domains erlauben

Eine Sache, die ihr nun tun könntet, wäre es, den Wert für X-Frame-Options so zu ändern, dass er weniger sicher ist. Aber das wollen wir natürlich nicht. Stattdessen könnt ihr die Einbindung des iframe auf bestimmten Seiten explizit erlauben. Dies macht ihr mit dem Content-Security-Policy Header:

Apache

Header set Content-Security-Policy "frame-ancestors 'self' https://example.com/ https://www.example.com/"

nginx

add_header Content-Security-Policy "frame-ancestors 'self' https://example.com/ https://www.example.com/"

Ihr habt vielleicht schon eine Content-Security-Policy in euren Server-Headern. I diesem Fall könnt ihr diese Optionen einfach anhängen. Wenn ihr nicht wisst, die man zwei Optionen kombiniert, dann kann euch vielleicht der Generator von Report UI dabei helfen.

Fazit

Die Absicherung einer Website ist sehr wichtig. Aber manchmal kann ein höherer Grad an Sicherheit auch anderen Dingen in die Quere kommen. Daher solltet ihr immer alle Funktionen testen, sobald ihr etwas an den Server-Headern verändert habt. Wenn plötzlich das Opt-out vom Tracking nicht mehr möglich ist, dann habt ihr zwar vielleicht ein Sicherheitsproblem gelöst, dafür aber ein Datenschutzproblem erzeugt.

Die Bearbeitung von Inhalten durch mehrere Personen erlauben

WordPress hat verschiedene Rollen und in der Regel ist es keine gute Idee allen die „Administrator“ Rolle zuzuweisen. Die nächstkleinere Rolle wäre „Redakteur“. Hiermit können alle Inhalte bearbeitet werden, eigene und die von anderen. Aber ich manchen Fällen ist auch das zu weitreichend.

Die Bearbeitung eigener Inhalte erlauben

Möchte man nur die Bearbeitung von eigenen Seiten und Beiträgen erlauben, dann sollte am besten die Rolle „Autor“ zugewiesen werden. Mit dieser Rolle können zwar die Inhalte andere angesehen werden, eine Bearbeitung ist aber nicht möglich. Das ist perfekt, wenn man Externen Zugriff auf „die eigene Seite“ geben möchte, beispielsweise auf das Profil einer Firma. Die Firma kann dann ihr eigenes Profil erstellen oder man erstellt es für die Firma und weist dann deren Profil als Autor der Seite zu.

Aber früher oder später kommt dann die Anforderung, dass mehr als eine Person aus dem Unternehmen die Seite bearbeiten können soll. Da aber WordPress immer einen User als Autor pro Seite erlaubt, ist das nicht einfach möglich, denn man möchte dem Unternehmen ja auch nicht vorschlagen, das Passwort zu teilen. Es muss also eine bessere Lösung her.

Das „Co-Authors Plus“ Plugin zur Rettung

Durch einen Tweet, in dem einige häufig verwendete Plugin genannt wurden, bin ich auf das Plugin Co-Authors Plus aufmerksam geworden, das es schon ziemlich lange gibt. Es erlaubt es einem mehr als einen Autor einer Seite oder einem Beitrag zuzuweisen. Der erste Autor wird hierbei in der Einzelansicht ausgegeben. Das Plugin stellt aber auch Funktionen bereit (die man dann im Child-Theme verwendet), mit denen die anderen ausgegeben werden können.

Diese verschiedenen Autoren können aber auch andere Rollen haben. Jeder Zugang, egal ob primärer/erster oder weiterer Autor, kann die Seite bearbeiten, solange dessen Rolle es ohnehin erlauben würden.

Da WordPress den Autoren eines Beitrags oder einer Seite normalerweise in einer einzelnen Spalte in der wp_posts Tabelle speicher, hat es mich sehr interessiert, wie es im Plugin gelöst wurde. Tatsächlich wird hierfür ein Custom-Post-Type verwendet, der die Zuordnung übernimmt.

Fazit

Während die normalen Rollen von WordPress in den meisten Fällen ausreichen, ist der Wunsch nach einer Bearbeitung durch mehrere Personen so ein Fall, in dem ich mir eine Lösung durch den Core gewünscht hätte. Mit diesem zusätzlichen Plugin (welches noch immer Updates erhält und sich auch gut in den Block-Editor und die „QuickEdit“ Funktion integriert), kann auch dies recht einfach erreicht werden.

Den „ERROR 1153“ beim Import großer Datenbanken lösen

Migrationen von WordPress-Seiten ist etwas, das ich wöchentlich mehrfach tue. Viele Migrationen sind zwischen lokalen Umgebungen oder Production und Staging. Nicht alle Quell- und Ziel-Systeme haben dabei unbedingt die gleichen Einstellungen. Manchmal muss man eine Seite mit einer großen Datenbank migrieren und stößt dabei eventuell auf diesen Fehler:

ERROR 1153 (08S01) at line 56: Got a packet bigger than 'max_allowed_packet' bytes

Das kann passieren, wenn ein einzelnes INSERT Statement beim Import zu groß ist. In diesem Beitrag möchte ich euch Tipps geben, wie ihr eine solche Datenbank importieren könnt.

Erstellen eines neuen Backups mit kleineren Imports

Wenn man eine Datenbank exportiert, dann verwendet man hierzu vermutlich das mysqldump Kommand, den wp db export Befehl oder ein Datenbank-Management-Tool wie Adminer oder phpMyAdmin. In den Standardeinstellungen werden hierbei INSERT Statements erstellt, die nicht nur eine Zeile in die Tabelle importieren, sondern mehrere auf einmal. Das ist oft auch eine gute Idee, da es den Import beschleunigt. Aber eben in genau diesen Fällen kommt es dann zu dem beschriebenen Fehler.

Um dies zu lösen, könnt ihr versuchen, einen Datenbank-Export zu erstellen, der immer nur ein Zeile in jedem INSERT Statement macht. Damit dauert der Import zwar etwas länger, er sollte aber erfolgreich durchlaufen.

Um einen solchen Export zu erstellen, könnt ihr die WP-CLI verwenden und ein paar mysqldump Argumente anhängen:

wp db export --extended-insert=FALSE --complete-insert=TRUE

Dies sollte eine solche Export-Datei erstellen. Jetzt solltet ihr diese hoffentlich importieren können

Erhöhen des Werts von „max_allowed_packet“

Wenn ihr noch immer das gleiche Problem habt, dann solltet ihr versuchen den Wert von „max_allowed_packet“ zu erhöhen. Der Standardwert kann vermutlich nur mit Administrationsrechten auf dem Server angepasst werden. Ihr könnt den Wert aber oft temporär ändern. Hierzu vebindet ihr euch zum MySQL-Server, erhöht den Wert und importiert dann die Datei. Ich verwende hierfür in meisten den wp db cli Befehl. Damit bin ich dann mit der richtigen Datenbank zu meiner WordPress-Installation verbunden. Anschließend führe ich dann die folgenden Befehle aus:

SET GLOBAL max_allowed_packet=1*1024*1024*1024;
SOURCE db_dump_filename.sql;

Der erste Befehl erhöht die Variable global auf 1 GB. Im Gegensatz zur MySQL-Konfigurationsdatei könnt iher hier als Wert nicht „1G“ im Statement verwenden, ihr müsst stattdessen den Wert in Bytes angeben. Ihr könnt aber eine Berechnung verwenden, daher habe ich diese Notation verwendet, mit der man besser erkennen kann, auf welchen Byte-Wert man die Variable setzt.

Fazit

Das Importieren von großen Datenbanken kann ein echtes Problem darstellen. Hoffentlich könnt ihr das Problem mit diesen Tipps selbst lösen. Falls nicht, fragt am besten jemanden mit Administrationsrechten, denn sie haben vermutlich entsprechenden Tools, um euch beim Import zu helfen. Und falls ihr selbst Daten in die Datenbank schreibt, dann achtet darauf, dass Zeilen nicht zu lang werden.

Entfernen des „Update Lock“ nach einer fehlgeschlagenen WordPress Aktualisierung

Das Aktualisieren von WordPress und seinen Plugins und Themes recht unkompliziert. Hierzu navigiert man zu „Dashboard | Aktualisierungen“ und aktualisiert hier die gewünschten Komponenten. Wenn während des Updates des Cores oder von Plugins/Themes ein Fehler passiert, dann kann WordPress dies meist abfangen und rückgängig machen, aber manchmal geht etwas schief.

Eine fehlgeschlagene Aktualisierung legt die Seite lahm

Wenn eine Aktualisierung abbricht, dann kann es sein, dass die Seite nicht mehr aufrufbar ist. In diesen Fällen erhält man die folgende Nachricht:

Wegen Wartungsarbeiten ist diese Website kurzzeitig nicht verfügbar. Schau in einer Minute nochmal vorbei.

Wenn WordPress den Core aktualisiert (oder mehrere Plugins), dann aktiviert es einen Wartungsmodus und schreibt einen Lock in die Datenbank.

Reparieren der Seite

Die zwei Sperren werden automatisch nach 15 Minuten entfernt. Da sie aber nicht nur das Backend, sondern auch das Frontend unerreichbar machen, möchte man sicher nicht 15 Minuten warten.

Deaktivieren des Wartungsmodus

Das Erste, was ihr tun solltet, ist nach einer Datei mit dem Namen .maintenance im Hauptverzeichnis eurer WordPress-Installation zu suchen. In dieser Datei befindet sich eine einzelne PHP-Zeile mit dem UNIX-Timestamp, der den Beginn des Installationsprozesses angibt:

<?php $upgrading = 1648994440; ?>

Wenn ihr diese Datei löscht, dann sollte die Nachricht verschwinden und ich solltet wieder das Frontend und Backend von WordPress sehen können.

Fortsetzen der vorherige Aktualisierung

Selbst nach dem Entfernen der .maintenance Datei kann es sein, dass ihr den WordPress-Core nicht direkt wieder updaten können. Wenn ihr ein erneutes Update versucht, könntet ihr auf diese Meldung stoßen:

Momentan wird eine andere Aktualisierung durchgeführt.

Dies wird durch die Option core_updater.lock hervorgerufen, die WordPress setzt, sobald der Update-Prozess startet:

$ wp option get core_updater.lock
1648994423

Wie ihr hier sehen könnt, ist der Zeitpunkt ein klein wenig früher (es ist der Zeitpunkt, bevor die ZIP-Datei heruntergeladen und entpackt wird). Wenn ihr euch also sicher seid, dass der vorherige Update-Prozess wirklich abgebrochen ist, dann könnt ihr die Option löschen, entweder über ein Datenbank-Tool oder über die WP-CLI:

$ wp option delete core_updater.lock
Success: Deleted 'core_updater.lock' option.

Jetzt solltet ihr die Aktualisierung erneut starten können, dieses Mal dann hoffentlich ohne weitere Fehler, die die Seite gleich wieder lahm legt.

Fazit

Obwohl WordPress-Updates normalerweise problemlos durchlaufen, kann es auch hier zu Fehlern kommen. In diesen Fällen ist es dann gut zu wissen, wie ihr die Seite direkt wieder zum Laufen bekommt und nicht 15 Minuten warten müsst, bis sich die Sperren von alleine lösen.

Ein defektes Git Repository Dateisystem reparieren

Vor ein paar Wochen hatte ich ein sehr ungewöhnliches Problem mit Git. In einem Repository, mit dem ich schon länger nicht mehr gearbeitet hatte, sollte ich mir mit git status ansehen, was ich zuletzt gemacht hatte, und bekam folgendes Ergebnis:

$ git status
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
fatal: Loses Objekt 6eeab7d4770c705a0491cafbc95830af69d5c6a2 (gespeichert in .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2) ist beschädigt.

Das hatte ich bisher noch nie bekommen. Zum Glück gibt es von Git einen Befehl, mit dem man den Zustand des Dateisystems überprüfen kann.

$ git fsck --full
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
error: Konnte mmap nicht auf .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ausführen.: Datei oder Verzeichnis nicht gefunden
error: 6eeab7d4770c705a0491cafbc95830af69d5c6a2: Objekt fehlerhaft oder nicht vorhanden: .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2
Prüfe Objekt-Verzeichnisse: 100% (256/256), fertig.
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
fatal: Loses Objekt 6eeab7d4770c705a0491cafbc95830af69d5c6a2 (gespeichert in .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2) ist beschädigt.

Das hat mir ein wenig mehr Informationen zum Fehler geben, aber leider noch immer keine Lösung dazu, wie es Git oft macht, wenn man ein Kommando verwendet.

Die Lösung

Mit diesen neuen Informationen konnte ich mich dann aber auf die Suche machen und eine Lösung bei Stack Overflow finden. Ich musste hierzu lediglich die beschädigte/leere Datei löschen. In meinem Fall war es wirklich nur diese eine Datei, wenn man aber in einem Git Repository mehrere solche Dateien hat, dann kann man mit dem folgenden Befehl recht schnell alle „leeren“ Dateien im Git-Ordner löschen:

$ find .git/objects/ -type f -empty | xargs rm

Nach der Ausführung dieses Befehls fehlen dann natürlich all diese Dateien im Repository. Diese bekommt man schnell wieder zurück, indem man sie von einem Remote lädt:

After this command, all corrupt files are missing from the repository. We can get them back by fetching the data from the remote:

$ git fetch -p
remote: Enumerating objects: 228, done.
remote: Counting objects: 100% (228/228), done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 210 (delta 121), reused 188 (delta 99), pack-reused 0
Empfange Objekte: 100% (210/210), 90.23 KiB | 1.43 MiB/s, fertig.
Löse Unterschiede auf: 100% (121/121), abgeschlossen mit 11 lokalen Objekten.

Zuletzt können wir noch einmal eine Dateisystem-Prüfung machen und kontrollieren, ob nun alle Fehler behoben wurden:

$ git fsck --full
Prüfe Objekt-Verzeichnisse: 100% (256/256), fertig.
Prüfe Objekte: 100% (221/221), fertig.
blob c5446110414804bbba2a5316a3e996ff37666bb9 unreferenziert
blob 45dd1301284105bcfc7e183bc805b65bf1465f47 unreferenziert
blob 70376fcbe5060d0db11490249bed5b553c0d04cc unreferenziert

Fazit

Normalerweise gibt uns Git immer sehr hilfreiche Fehlermeldungen, wenn wir etwas falsch machen. In diesem Fall musste ich aber ein wenig recherchieren, um eine Lösung zu finden. Zum Glück hatten schon andere vor mir das gleiche Problem und konnten es lösen.

Unsere Lösung hat aber nur deshalb ohne Verluste funktioniert, weil wir die beschädigten/leeren Objekte von einem Remote neu laden konnten. Daher empfehle ich Leuten immer, dass sie ihren Code auch in einem Remote Repository haben sollten und häufigen Committen und Pushen.

Als Volunteer auf einem WordCamp

Heute möchte ich einen persönlichen Beitrag schreiben und einen Aufruf an alle Menschen in der Community machen. Ich möchte über meine Erfahrungen als Volunteer (freiwilliger Helfer) auf einem WordCamp sprechen.

Meine erste Erfahrung als Volunteer kam sehr spät. Ich habe mein erstes WordCamp 2010 besucht, schon 2012 eines organisiert und seither auf mehreren einen Vortrag gehalten. Diese Arten der Mithilfe sind auch sehr wichtig, aber sie sind ganz anders als die Mithilfe als Volunteer.

WordCamp Europe 2016 in Wien

Ich weiß nicht genau, wann ich zum ersten Mal daran gedacht habe, das WordCamp Europe nach Deutschland zu holen, aber 2015 habe ich mit einigen anderen Menschen aus der Community, mit dem damaligen Organisationsteam darüber gesprochen, wie es möglich werden könnte. Wenn man ein Event von dieser Größe organisieren möchte, dann ist es gut, ein wenig Erfahrung in der Organisation zu sammeln. Daher machte es für mich sehr viel Sinn, beim nächsten Event als Volunteer dabei zu sein.

Meine erste Schicht war als „Foyer Guard“ für den Raum der Vortragenden und der Kinderbetreuung, was sehr interessant war. Ich hatte nur auf dem WordCamp London zuvor gesehen, dass eine Kinderbetreuung angeboten wurde, aber ich habe erkannt, wie wichtig es für diejenigen war, die mit Kindern nach Wien gereist waren.

Meine zweite Schicht am ersten Tag war an der Registrierung. Dort konnte ich neue Teilnehmende begrüßen. Hier habe ich auch nicht alleine meinen Dienst verrichtet, sondern mit anderen zusammen. Diese Schicht hat also wirklich sehr viel Spaß gemacht, zum einen wegen der Arbeit mit den anderen Volunteers und zum anderen, weil ich so viele Menschen getroffen habe, einige davon kannte ich schon seit Jahren.

Am zweiten Tag war ich für die „Lunch Attendee Orientation“ eingeplant. Ich habe also den Teilnehmenden gezeigt, wo es Mittagessen gab, sollten sie es am ersten Tag nicht schon gefunden habe. Meine letzte Schicht war als „Door Guard“ für den großen Saal. Ich musste also dafür sorgen, dass alle, die zu spät kommen, beim betreten des Saals leise sind.

WordCamp London 2017, 2018 und 2019

Meine nächste Volunteering-Chance kam 2017 beim WordCamp London. Nur ca. einen Monat vor dem Event bat das Organisationsteam um Hilfe, weil einige Volunteers abgesagt hatten. Ich hatte zwar schon ein Ticket gekauft, aber dennoch gerne geholfen. Ich wurde auch zu einem tollen „WarmUp“ für Vortragende, Organisatoren und Volunteers eingeladen. In einer „Tischtennis-Bar“! Das hat super viel Spaß gemacht!

Nur ein Jahr später war ich wieder als Volunteer dabei, denn das WordCamp London ist eines meiner Lieblings-WordCamps. Dieses Mal gab es einen „Kids-Workshop“, das vom WordPress Mitbegründer Mike Little geleitet wurde. Ich war schwer beeindruckt, was mache Schulkinder in den wenigen Stunden erreichen konnten.

Ich habe auch beim WordCamp London 2019 ein drittes Mal mitgeholfen. Dort hatte ich meine erste Schicht im Lagerraum und der Garderobe. Dort habe ich den Sponsors geholfen ihre Boxen zu verstauen, nachdem sie ihre Stände aufgebaut hatten, und ich habe ein paar Swag-Beutel gepackt. Danach konnte ich ein wenig das WordCamp genießen und mir Sessions ansehen. Etwas später hatte mich dann die Haupt-Organisatorin abgefangen und sich bei mir entschuldigt. Ihr war nicht bewusst, dass sie den aktuellen Local-Lead-Organizer für das WordCamp Europe in den Lagerraum gesteckt hatte, als sie die Schichten für die Volunteers geplant hatte. Ich konnte sie aber beruhigen, dass es keinen Grund gäbe, sich zu entschuldigen. Ich was an diesem Tag einfach nur Volunteer und meine Hilfe wurde eben genau hier im Lageraum gebraucht und daher habe ich daher meine Schicht geleistet.

Fazit

Alle, die bei einem WordCamp als Volunteer helfen sind wichtig und das Organistationsteam ist ihnen für die Hilfe sehr dankbar, auch wenn die Aufgabe vielleicht klein und unbedeutend scheint. Die Mithilfe als Volunteer ist auch der erste Schritt zukünftig im Organisationsteam mitzuhelfen. Es gibt zwar keine Regel, dass man vorher Volunteer sein musste, aber es hilft auch jeden Fall, schon einmal einen ersten Einblick in die Organisation bekommen zu haben. Und auch als späteres Mitglied ist es gut zu wissen, wie sich die Rolle als Volunteer anfühlt, auch wenn man vielleicht noch nicht viel über WordPress und die Community weiß. Wenn ihr also ein WordCamp in eurer Nähe seht, das einen sogenannten „Call for Volunteers“ hat, dann überlegt doch mal, ob ihr nicht mithelfen wollt. Es gibt euch auf jeden Fall eine neue Perspektive auf das Event.

Und weil wir gerade von WordCamps sprechen, die Volunteers suchen: das WordCamp Europe findet im Juni statt und ihr könnt euch noch bis zum 31. März 2022 als Volunteer bewerben. Falls euch genau dieser Beitrag dazu bewegt hat, euch zu bewerben, dann würde ich mich freuen, wenn ihr mich auf dem „Social“ (das ist der Name für das „Warm-Up“ Event auf dem WordCamp Europe) ansprecht und eure Geschichte erzählt.

Scripts und Styles effektiv einbinden

Wenn man JavaScript und CSS Dateien einbinden möchte, dann sollte man immer die Funktionen wp_enqueue_script() und wp_enqueue_style() verwenden. Falls ihr das noch nicht tut, dann fangt bitte ab sofort damit an. Die Verwendung der beiden Funktionen ist wirklich sehr einfach, aber um diese auch effektiv zu nutzen, sollte man ein paar Dinge beachten.

Einfache Verwendung

Die einfachste Art, die Funktionen zu verwenden, ist die Definition eines „handle“ sowie einer URL der Datei, die ihr einbinden wollt:

wp_enqueue_script(
	'chart-js',
	'https://cdnjs.cloudflare.com/ajax/libs/Chart.js/3.7.0/chart.min.js'
);

Dieses Beispiel würde eine JavaScript-Datei einbinden, sie sich auf einem externen Server befindet. Das ist so weit auch OK, aber es gibt viele Gründe, wieso man Dateien lieber lokal einbinden möchte, um beispielsweise Probleme beim Ausfall des CDN zu vermeiden oder aber, um den Datenschutz zu verbessern.

Verwendung einer lokalen Datei – schlechtes Beispiel

Um eine Datei aus einem Plugin oder Theme zu laden, würde es ausreichen, den Pfad wie folgt relative anzugeben:

wp_enqueue_script(
	'chart-js',
	'/wp-content/plugins/plugin-name/assets/chart.min.js'
);

Die Datei würde dann wie folgt in den Quellcode eingebunden werden:

<script type='text/javascript' src='https://theme-tests.docker.test/wp-content/plugins/plugin-name/assets/chart.min.js?ver=5.9'></script>

Das würde zwar funktionieren, es gibt mit dieser einfachen Methode aber ein paar Probleme.

1. Immer dynamische Pfade verwenden

Im Beispiel oben wurde ein relativer Pfad auf das Verzeichnis wp-content/plugins verwendet. Das mag für viele von euch richtig aussehen, aber der Ordner wp-content kann einen anderen Namen haben (und manche Sicherheits-Plugins tun das auch – obwohl es eine schlechte Idee ist). Ihr solltet daher immer eine Hilfsfunktion verwenden, um den relativen Pfad zu diesem Ordner zu erhalten. Wenn ihr eine Datei in einem Plugin oder Theme einbindet, dann könnt ihr hierzu verschiedene Funktionen verwenden. Diese hier werdet ihr dafür vermutlich in der Regel verwenden:

2. Immer eine Version der Datei angeben

Wie ihr in dem Beispiel oben sehen könnt, fügt WordPress immer eine Versionsnummer an. Wenn ihr selbst keine festlegt, dann wird WordPress immer seine aktuelle Version ans Ende der URL anhängen. Heute würde also 5.9 am Ende stehen. Diese Versionsnummer hat den Zweck, euch beim Caching zu helfen. Da sich eure Dateien aber sicher nicht (nur) dann ändern, wenn eine neue WordPress Version erscheint, solltet ihr hier einen anderen Versions-String verwenden. Das könnte einer der folgenden sein:

  • Eine statische Versionsnummer, die der Version des Plugins entspricht
  • Ein statisches Änderungsdatum des Plugins
  • Ein statisches Änderungsdatum der Datei, die eingebunden werden soll
  • Ein dynamisches Änderungsdatum der Datei, die eingebunden werden soll

In der Vergangenheit habe ich oft die erste oder dritte Option verwendet. Aber dabei musste jeder dieser Versions-String (für alle Dateien) immer manuell aktualisiert werden. Dabei vergisst man dann schnell mal einen und der Browser liefert eine alte Datei aus seinem Cache aus. Heutzutage verwende ich daher normalerweise den letzten Ansatz. Das hat auch den Vorteil, dass während der Entwicklung, bei jedem Speichern der Datei immer sichergestellt wird, dass der Browser stets die aktuellste Datei lädt. Ein Beispiel für diesen Ansatz – kombiniert mit dynamischen Pfaden – könnte wie folgt aussehen:

wp_enqueue_script(
	'chart-js',
	plugins_url( 'assets/chart.min.js', __FILE__ ),
	array(),
	filemtime( plugin_dir_path( __FILE__ ) . 'assets/chart.min.js' )
);

Das Resultat der Einbindung der Datei würde dann so aussehen:

<script type='text/javascript' src='https://theme-tests.docker.test/wp-content/plugins/plugin-name/assets/chart.min.js?ver=1644792351' id='chart-js-js'></script>

Wie ihr hier sehen könnt, wurde an das Ende der URL der aktuelle UNIX-Timestamp angehängt. Da sich dieser mit jeder Änderung der Datei ändert, wird der Browser immer die aktuellste Datei laden.

Fazit

Dieser Blogbeitrag behandelt ein sehr einfaches Konzept, aber ich sehe immer wieder Plugins und Themes, die Dateien nicht effektiv einbinden. Mit diesen kleinen Tricks könnte ihr viel Stress beim Finden von Fehlern vermeiden, die nur deshalb auftreten, weil der Fehler eigentlich nur darin bestand, dass der Browser noch immer eine alte Version der Datei aus seinem Cache geladen hatte.

Dynamische Formular-Hooks für GravityForms

Ich nutze wirklich sehr gerne GravityForm, wenn ich sehr dynamische Formulare erstellen muss. Der Formular-Builder ist sehr umfangreich und bietet viele Möglichkeiten. Manchmal muss man dann aber doch ein wenig eigenen Code schreiben und sich per Hook in die Formular-Abarbeitung einhängen. In diesem Blogbeitrag möchte ich euch zeigen, wie das auch über mehrer Installation eines Formulars hinweg funktioniert.

Verwendung eines Hooks für alle Instanzen

Nehmen wir als Beispiel mal den Hook gform_pre_submission. Wenn ihr euch hier einhängen wollt, dann funktioniert das, wie bei jedem anderen Hook in WordPress auch:

function my_pre_submission( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission', 'my_pre_submission' );

Dieser Code-Schnippsel würde den Wert jedes Formular-Feldes mit der ID 1 in jedem Formular überschreiben. Das ist sicher nicht, was ihr normalerweise wollt.

Verwendung eines Hooks nur für ein Formular

Wenn ich den Wert eines Feldes ändern wollt, dann in der Regel nur für ein spezifisches Formular. Dies kann recht einfach erreicht werden, indem ihr die Formular-ID an das Ende des Hooks anhängt:

function my_pre_submission( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission_1', 'my_pre_submission' );

Nun wird nur noch das Feld für das Formular mit der ID 1 überschrieben, sobald es übermittelt wurde. Das ist eine gute Lösung, bis zu dem Zeitpunkt, an dem ihr die Export/Import Funktion verwendet.

Umgang mit Formularen mit verschiedenen IDs

Sagen wir einmal, ihr habt ein Formular in einem Projekt erstellt und möchtet dieses nun in einem anderen verwenden. Hierzu könnt ihr dann einfach die Funktion für den Export und Import verwenden, was das Formular mit allen Einstellungen (aber ohne die Einträge) kopiert. Aber wenn das neue Projekt bereits Formulare hat, dann kann es passieren, dass das Formular hier eine andere ID bekommt. Das gleicht passiert auch recht schnell, wenn ihr in einer Entwicklungsumgebung ein Formular erstellt und es dann auf eine Live-Seite importiert oder aber wenn ihr nicht alleine neue Formulare erstellt.

In diesen Fällen müsst ihr dann die neue Formular-ID rausfinden und den Wert entsprechend in allen Hooks anpassen. Aber was ist, wenn ihr den Code in einer Versionsverwaltung habt und nicht einfach einen neuen statischen Wert verwenden könnt?

Verwendung einer Konstanten für die Formular-ID

In einem Projekt hatte ich genau dieses Problem und mich dazu entschieden, die ID des Formulars einfach in einer Konstanten zu speichern. Alle Hooks sehen dann in etwa wie folgt aus:

function my_pre_submission_contact( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission_' . PREFIX_CONTACT_FORM_ID, 'my_pre_submission_contact' );

function my_pre_submission_form_event( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission_' . PREFIX_EVENT_FORM_ID, 'my_pre_submission_form_event' );

Das ist natürlich nicht der echt Code, aber ich denke, ihr versteht den Ansatz damit. Ich habe also eine Konstante pro Formular (und hierbei den Formularnamen und nicht dessen ID verwendet). Damit kann dann die ID je nach System dynamisch gesetzt werden.

Setzen eines Standard-Werts für die Konstante im Plugin (oder Theme)

Ich speichere solchen Code normalerweise in einem Plugin. In der Hauptdatei dieses Plugins setze ich dann einen Standardwert, der dem System entspricht, auf dem ich das Formular zuerst verwendet/erstellt habe:

if ( ! defined( 'PREFIX_CONTACT_FORM_ID' ) ) {
	define( 'PREFIX_CONTACT_FORM_ID', 1 );
}
if ( ! defined( 'PREFIX_EVENT_FORM_ID' ) ) {
	define( 'PREFIX_EVENT_FORM_ID', 2 );
}

Mit der ! defined() Prüfung kann ich feststellen, ob die Konstante schon zuvor an andere Stelle gesetzt wurde und ansonsten den Standardwert setzen. Im zweiten Projekt kann ich daher dann in der wp-config.php Datei die anderen IDs setzen:

define( 'PREFIX_CONTACT_FORM_ID', 4 );
define( 'PREFIX_EVENT_FORM_ID', 5 );

Fazit

Obwohl GravityForms wirklich sehr viele Hooks anbietet und diese wirklich einfach genutzt werden können, kann es aufgrund der statischen IDs in den Namen schnell zu Problemen führen. Die Verwendung von dynaischem ID-Werten in Konstanten ermöglicht es euch, den selben Code in mehreren Projekten zu verwenden.

Das Gleiche gilt selbstverständlich auch für alle anderen Hooks von GravityForms, bei denen eine ID ans Ende des Hooks gehängt werden können, um nur bestimmt Formulare, Felder, etc. anzupassen.

Kategorie-Seiten alphabetisch sortieren

In einer Facebook-Gruppe wurde gefragt, wie man alle Beiträge auf einer Kategorieseite alphabetisch sortieren kann. In diesem Beitrag möchte ich darauf eingehen, wie man die Sortierung von Beiträgen auf Archiv-Seiten von Kategorien (und anderen) anpassen kann.

Sortierung von Beiträge auf allen Kategorie-Seiten

Selbst wenn ich nicht genau weiß, wieso die Person die Beiträge auf allen Kategorie-Seiten (und nicht etwa auf einer Archivseite eines anderen Post-Types) sortieren wollte, wäre das hier der passende Code dafür:

function aa_sort_all_archives( $query ) {
	// Only sort main query.
	if ( ! $query->is_main_query() ) {
		return;
	}
	// Only sort category archives.
	if ( ! is_category() ) {
		return;
	}

	$query->set( 'order', 'ASC' );
	$query->set( 'orderby', 'post_title' );
}

add_action( 'pre_get_posts', 'aa_sort_all_archives' );

Wann immer man die Query verändern möchte, sollte man eine Callback-Funktion zum pre_get_posts Hook verwenden. In dieser Callback-Funktion prüfen wir zuerst einmal, ob wir uns in der Haupt-Query befinden. Dann prüfen wir mit einer weiteren Bedingung nach für unseren Anwendungsfall. Ist diese Bedingung nicht erfüllt, verlassen wir die Funktion ebenfalls. Wenn alle Bedingungen erfüllt sind, dann passen wir die Query an. In Zeile 7 prüfen wir also, ob wir auf einer Kategorie-Seite sind. Wenn das der Fall ist, dann setzen wir die Sortierreihenfolge auf aufsteigend („ascending“) in Zeile 11 und das Feld, nach dem sortiert werden soll in Zeile 12 auf das post_title Feld. Das war’s!

Nur Beiträge in einer bestimmen Kategorie ordnen

Für manche Post-Types ist es wohl eher unwahrscheinlich, dass man die Posts nach für alle Kategorien sortieren möchte. Daher können wir auch den „slug“ (oder den Namen bzw. die ID) einer Kategorie an die is_category() Funktion übergeben. In diesem Beispiel habe ich eine spezielle Kategorie „alphabetical“ verwendet, um nur auf dieser Kategorieseite die Beiträge zu sortieren:

function aa_sort_alphabetical_archives( $query ) {
	// Only sort main query.
	if ( ! $query->is_main_query() ) {
		return;
	}
	// Only sort category archives.
	if ( ! is_category( 'alphabetical' ) ) {
		return;
	}

	$query->set( 'order', 'ASC' );
	$query->set( 'orderby', 'post_title' );
}

add_action( 'pre_get_posts', 'aa_sort_alphabetical_archives' );

In der gleichen Art und Weise lassen sich auch viele andere Archiv-Seiten unter Verwendung der „Conditional Tags“ überprüfen. Im CODEX findet ihr außerdem eine Seite über „Alphabetizing Posts“, darin wird aber die Verwendung einer sekundären Query gezeigt. Macht so etwas bitte niemals! Und lasst auch nicht alle Beiträge ausgeben! Macht also nichts von dem, was die Seite euch hier erzählt 😉

Fazit

Das Sortierung von Beiträgen (oder anderen Beitragstypen) kann auf einer Archiv-Seite am besten mit dem pre_get_posts Hook gelöst werden. Wenn ihr das erste Mal mit diesem Hook arbeitet, dann kann es passieren, dass es nicht gleich so funktioniert, wie ihr es gerne hättet, aber es lohnt sich wirklich sich mit dem Hook zu beschäftigen.

Ihr findet den Code zu diesem Beitrage auch als funktionierendes Plugin in einem GIST, wo ihr es euch auch als ZIP-Datei herunterladen und dann auf eurer Seite installieren könnt.