Vielen Dank an die WordPress-Community!

Die letzte Woche war hart. Ich meine so richtig hart. Erst vor zwei Wochen habe ich an dieser Stelle allen Organisationsteam gedankt, die Konferenzen absagen mussten. Nun befinde ich mich in genau der gleichen Situation.

Die Absage des WordCamp Europe 2020

Am Donnestagabend vorletzte Woche hatte ich ein Telefonat mit Tess und Jonas, den anderen beiden Global-Leads des WCEU 2020 und mit Rocío, unserer Mentorin, sowie mit Andrea, die das globale WordPress-Community-Team leitet.

Wir haben über einen Zeitplan für die nächsten Wochen und Monate gesprochen und uns einen Plan gemacht, um das WordCamo Europe in Porto im Juni diesem Jahres durchführen zu können. Am 5. März sahen die Dinge noch ganz gut aus. Es gab nur wenige Fälle in Portugal und nur Italien hatte in Europe mit sehr vielen Fällen zu kämpfen. Wir beschlossen also, mit der Planung des Events im Juni weiterzufahren und waren optimistisch, dass es noch stattfinden könne. Wir haben uns bis Anfang April für eine Entscheidung Zeit lassen wollen.

Die letzten Tage

Nach diesem Meeting wurden die Dinge mit jedem Tag schlechter. Konferenzen in Europa wurden abgesagt. Am 9. Märze traf es eine große Joomla Konferenz in Lissabon, die nur eine Woche vor dem WordCamp Europe 2020 in Porto stattfinden sollte.

Am 11. März hat das globale Community-Team Empfehlungen herausgegeben, dass alle Veranstaltungen bis einschließlich 1. Juni abgesagt oder verschoben werden sollten. Da das WCEU 2020 vom 4. – 6. Juni geplant war, also nur bis ein paar Tage zuvor.

Schließlich hatten wir letzten Donnerstag, nur eine Woche nach unsere “Krisensitzung” eine Videokonferenz mit allen Organisatoren, in der wir beschlossen haben, dass wir das WordCamp Europe 2020 absagen und auf das Jahr 2021, ebenfalls in Porto, verschieben werden.

Danke an unserer Communtiy

Die Reaktionen, die auf unserer Ankündigung folgten, waren überwältigend. Wir haben viele empathische Nachichten auf Twitter und anderen Kanälen erhalten. Viele liebe Menschen aus der WordPress-Community haben mich direkt angeschrieben und gefragt, wie es mir geht und Hilfe angeboten.

Darum liebe ich diese Communtiy. In guten und in harten Zeiten unterstützen und helfen wird uns gegenseitig. Das ist auch der Grund, wieso das Organisationsteam positiv in die Zukunft schaut und noch intersiver am WordCamp Europe 2021 in Porto arbeiten wird.

Vielen Dank WordPress-Community ❤

Vielen Dank die Organisationsteams!

Ich hatte für diese Woche einen anderes Thema für den #projekt26 Beitrag geplant, aber die Ereignisse der letzten Wochen haben mich dazu veranlasst über etwas anderes zu schreiben.

WordCamp Asia 2020

Der Februar ist vorüber und es war ein sehr ereignisreicher Monat für mich. Oder sollte ich eher sagen, er war es nicht? Ich habe mich sehr auf keine erst Asienreise gefreut, meine Teilnahme am WordCamp Asia in Bangkok in Thailand. Es war vom 21. – 23. Feburar geplant und ich hatte Flug und Hotel schon vor Wochen geplant sowie Urlaub eingereicht (da Teilnahmen an WordCamps nicht Teil meines Jobs sind). Ich habe mich auch auf ein paar schöne warme Tage mit vielen alten und neuen Freunden gefreut. Aber am 12. Februar bekam ich dann überraschend die traurige Nachricht, dass das WordCamp Asia abgesagt werden musste.

Ich hatte großes Glück und konnte mein Hotel und meinem Flug kostenfrei stornieren. Daher habe ich meine gesamte erste Asienreise für dieses Jahr abgesagt.

CloudFest 2020 Hackathon

Diesen Monat vom 14. – 16. März werde ich meinen ersten echten Hackathon besuchen. Dieser wird nicht nur für Mitglieder der WordPress-Community, sondern für viele andere tolle Menschen aus anderen OpenSource-Communities veranstaltet, sowie Firmen, die sich auf das Thema Hosting spezialisiert haben. Aber auch an dieser Konferenz werde ich nicht teilnehmen, dann das CloudFest musste ebenfalls abgesagt werden.

WordCamp Retreat Soltau 2020

Vor zwei Jahren habe ich eines der besten WordCamps besucht, auf denen ich je als Teilnehmer dabei sein konnte. Es war keine normale Veranstaltung, auf der man sich für einen “Arbeitstag” zu Vorträgen und Workshop traf. Stattdessen verbrachte man 24 Stunden für über mehrere Tage mit allen anderen Teilnehmenden im selben Hotel und konnte neben Vorträgen auch an anderen Aktivitäten teilnehmen. Dieses Jahr war es vom 30. April bis zum 3. Mai geplant. Es war geplant, da auch diese Veranstaltung vor einer Woche abgesagt und auf das nächste Jahr verschoben wurde.

Danke Organisationsteams!

Falls ihr euch nun wundert, wieso ich mich dafür bedankte, dass diese Veranstaltungen abgesagt wurden, dann ist der Grund ganz einfach. Selbstverständlich bin ich sehr traurig darüber, dass ich an an diesen Events nicht teilnehmen kann … zumindest nicht dieses Jahr. Alle Organisationsteams haben aber angekündigt im nächsten Jahr die Veranstaltung erneut zu organisieren. Viele davon am gleichen Ort und ungefähr zur gleichen Zeit.

Ich habe bereits vier WordPress Konferenzen in Berlin organisiert und stecke gerade zum vierten Mal mitten in der Organisation des WordCamp Europe. Ich weiß, wie viel Zeit, Energie und Leidenschaft in die Organisation eines solchen Community-Events fließt. Ich kann mir nur vorstellen, wie schwer es für alle Beteiligten gewesen sein muss, diese Veranstaltungen abzusagen (es gab auch noch weitere).

Mit der Absage einer Veranstaltung ist die Arbeit aber nicht getan und man kann nicht einfach aufhören zu arbeiten. Man muss sich mit den ganzen Nachwehen einer solchen Absage beschäftigen, sämtliche Verträge kündigen und so vielen Menschen wie möglich eine Rückerstattung ermöglichen. Man wird außerdem mit vielen negativen Rückmeldungen zu kämpfen haben, denn nicht alle werden verstehen, wieso die Absage unausweichlich war (wie z.B. “es gab doch gar keine Corona-Infektionen in dem Gebiet”). Allen Personen, die an der Organisation und harten Entscheidung zur Absage beteiligten waren, gilt unsere Unterstützung.

Wenn es euch also wie mir geht und eine Veranstaltung, an der ihr teilnehmen wolltet, wurde abgesagt, dann nehmt euch bitte einen Moment und sendet ein Vielen Dank an das Organisationsteam, denn sie haben es sich mit ihrer Entscheidung sicher nicht einfach gemacht und diese schwierige Entscheidung im besten Interesse der Gesundheit der Community, sowohl der pysischen, als auch der psychischen, gemacht. Und bitte unterstützt sie dadurch, dass ihr auch im nächsten Jahr wieder teilnehmen werdet. Vielleicht ja sogar durch freiwillige Mithilfe auf der Veranstaltung als Volunteer. Damit erhalten ihr den besten Einblick darin, mit wie viel Leidenschaft alle daran arbeiten für uns allen ein tolles Event zu veranstalten!

Danke Ogranisationsteams ❤

Bildkonvertierung mit ImageMagick reparieren

Seit Version 4.7 erstellt WordPress von einer hochgeladenen PDF-Datei einen Screenshot der ersten Seite. Hierzu muss ImageMagick sowie die zugehörige PHP-Extension installiert sein.

Auf einem Server mit Ubuntu 18 funktionierte es aber trotzdem noch nicht, obwohl beide Komponenten installiert waren. Daher habe ich zum Test versucht, eine Konvertierung direkt auf der Kommandozeile durchzuführen:

convert test-pdf.pdf test-pdf.png

Dabei bekam ich dann folgende Fehlermeldung angezeigt:

convert: not authorized `test-pdf.pdf' @ error/constitute.c/ReadImage/412.
convert: no images defined `test-pdf.png' @ error/convert.c/ConvertImageCommand/3210.

Nach etwas Recherche bin ich dann auf die Lösung für das Problem gestoßen. ImageMagick hat seit einigen Versionen eine Security-Policy umgesetzt, in der man einschränken kann, welche Dateiformat umgewandelt werden dürfen. Leider gehört PDF zu den Erweiterungen, die nicht standardmäßig unter Ubuntu 18 konvertiert werden können. Die Policies kann man aber in der Datei /etc/ImageMagick-6/policy.xml anpassen:

<policymap>
  <!-- ... -->
  <policy domain="path" rights="none" pattern="@*" />
  <!-- disable ghostscript format types -->
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="EPS" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
</policymap>

Hier kann man entweder die Zeile für das PDF-Format mit einem XML-Kommentar auskommentieren oder aber die rights auf read einstellen:

<policymap>
  <!-- ... -->
  <policy domain="path" rights="none" pattern="@*" />
  <!-- disable ghostscript format types -->
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="EPS" />
  <policy domain="coder" rights="read" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
</policymap>

Nun kann man auf der Kommandozeile noch einmal testen, ob die Einstellung angenommen wurde (in diesem Fall gibt das convert Kommando keine Rückmeldung). Anschließend sollte die automatische Konvertierung beim Upload von PDF Dateien in die WordPress-Mediathek auch funktionieren.

Fehlende Bilder von Live-Server im Entwicklungs-System anzeigen

Wenn man an einem bestehenden Projekt arbeite, das bereits live gegangen ist, dann ist es manchmal notwendig, dass man sich den aktuellen Stand einer Datenbank vom Live-System holt, um lokal Dinge zu testen. Aber wie sieht es mit den Mediendateien aus, die in der Zwischenzeit dazu gekommen sind und die schnell mehrere Gigabyte an Größe umfassen? Nun, oft wird man auch diese benötigen, vor allem, wenn man am Design arbeitet. Aber wie hält man diese auf dem aktuellen Stand mit der Live-Seite? Die gute Nachricht: das ist gar nicht notwendig und in diesem Blogbeitrag möchte ich euch zeigen, wie man es anders lösen kann.

Nehmen wir also an, dass ich euch gerade eine aktuelle Kopie der Live-Datenbank in euer lokalen Entwicklungs-System gespielt habt. Dann werden wahrscheinliche einige Bilder nicht angezeigt, da ihr ja die URL in der Datenbank auf die lokale Domain geändert habt und diese Bilder lokal nicht gefunden werden können. Ihr könntet auch nun natürlich mit dem Live-System verbinden und alle Bilder synchronisieren, was aber schnell viele Megabyte oder Gigabyte benötigt. Wenn ihr gleichzeitig an mehreren Projekten arbeitet, habt ihr sehr schnell denn Platz auf eurer Festplatte verbraucht. Ihr könnt aber auch einfach den gesamten Uploads-Ordner inklusive aller Unterordner (oder zumindest alle mit den hochgeladenen Mediendateien) löschen und sie stattdessen von der Live-Seite laden lassen.

Fehlende Dateien vom Live-Server laden

Falls ihr in eurer lokalen Entwicklungsumgebungen einen Apache Webserver einsetzt, müsst ihr hierzu lediglich folgende Zeilen in eure .htaccess eintragen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^wp-content/uploads/(.*) https://xyz.com/wp-content/uploads/$1 [R=302,L]
</IfModule>

Diese Zeilen fügt man ganz oben in der .htaccess Datei vor allen anderen Angaben ein.

Wie es funktioniert

Der Apache Server prüft über die beiden RewriteCond, ob die Datei oder der Ordner, der angefragt wird, nicht existiert. Sollte dies der Fall sein greift die RewriteRule, die alle Aufrufe von Dateien im Ordner wp-content/uploads auf die Live-Seite umleitet.

Es werden also alle Bilder, die nicht lokal vorhanden sind, vom Live-Server abgerufen. Ist bei diesem das Caching richtig eingestellt, passiert dies in der Regel auch nur einmal pro individueller URL.

Somit kann man nun alle Bilder auch auf der lokalen Umgebung sehen, ohne diese vorher runterladen zu müssen. Man kann die Bilder sogar lokal über die Medienübersicht bearbeiten. Sobald man die Datei speichert, wird die Originaldatei sowie die anderen Bildgrößen im lokalen System abspeichert. Diese Änderungen werden aber natürlich nicht wieder ins Live-System zurückgespielt. Man kann hiermit aber schnell und gefahrlos lokale testen.

Einige Einschränkungen

Diese Technik funktioniert in den allermeisten Fällen. Falls der Webserver nicht bei der Generierung des HTML-Codes allerdings prüft, ob die Datei auch wirklich lokal vorhanden ist, dann scheitert es, denn in der Regel passieren solche Prüfungen auf die Existenz von Dateien über eine PHP-Funktion, die dann die Datei nicht finden kann, da unser Trick über den Webserver umgesetzt wird.

Da aber oft eher nur Dateien auf Existenz geprüft werden, die nicht im Uploads-Ordner, sondern in den Ordnern der Themes und Plugins gespeichert sind, sollte das kein allzu großes Problem darstellen. Im Zweifel müsstet ihr dann solche Dateien doch runterladen. Diese zu finden könnte aber etwas knifflig sein.

Eine weitere Einschränkung ist die Notwendigkeit einer Verbindung zum Webserver. Wenn man lokal entwickelt hat man ja in der Regel den Vorteil, dass dies auch ohne Internetverbindung möglich ist. Ich schreibe auch oft meine Blogbeiträge, wenn ich etwas im Zug unterwegs bin, wo die Internetverbindung häufiger abbricht. Falls ihr also Dateien unbedingt für die lokale Entwicklung benötigt, müsste ihr sie wohl doch synchronisieren.

Funktioniert es auch mit anderen Entwicklungsumgebungen?

Das Gleiche ist auch bei der Verwendung des nginx-Servers in der lokalen Entwicklung möglich. Da man aber beim nginx nicht einfach eine Datei im Verzeichnis der WordPress-Installation verwenden kann, müsste ihr folgende Zeilen in die nginx-Konfiguration hinzufügen:

location ~ ^/wp-content/uploads/(.*)$ {
        try_files $uri @missing;
}
location @missing {
	return https://xyz.com$uri;
}

Fazit

Man sollte immer mit einer lokalen Kopie einer Website ändern, wenn man daran entwickelt. Diese auf dem aktuellen Stand zu halten ist allerdings sehr zeitintensiv. Durch den Wegfall der Synchronisation von Mediendateien kann aber sehr viel Zeit und vor allem Speicherplatz eingespart werden.

Bewegungen auf einer Webseite für eine bessere Barrierefreiheit reduzieren

Dies ist mein zweiter Beitrag zum #FokusBarrierefreiheit Themenmonat Januar. Heute möchte ich über ein eher wenig bekanntes Thema zur Barrierefreiheit berichten. Viele von euch wissen vermutlich, wie man eine Website für Menschen optimiert, die visuelle Beeinträchtigungen haben oder blind sind. Aber es gibt auch andere Beeinträchtigungen und heute möchte ich auf eine weniger bekannte aufmerksam machen.

Motion-triggered vestibular spectrum disorder

Die beste Übersetzung, die mir einfällt wäre “Schwindelgefühle bei bewegten Animationen”. Das Thema ist wir gesagt eher unbekannt, kann aber für betroffene erhebliche gesundheitliche Folgen haben. Sie können zu einem vestibulären Anfall (epileptischen Anfall) führen. Daher sollten Animationen, Effekte und Bewegungen vermieden werden.

Selbstverständlich können Animationen und Effekte einen Webseite bereichern und zu einem tollen Erlebnis beitragen. Aber möchten man Menschen wirklich durch diese Animationen gesundheitlich schädigen? Sicher nicht. Was kann man also tun, um mit diesem Problem umzugehen. Zuerst einmal sollte man sich darüber informieren. Ich habe leider keine deutschsprachigen Beiträge hierzu gefunden, kann aber die Artikel von Mozilla und A List Apart empfehlen. Es gibt noch einige andere Elemente einer Webseite, die einen solchen Anfall auslösen können, aber ich möchte mich heute darauf konzentrieren, wie ihr mit ein wenig CSS-Code die Animationen auf einer Webseite reduzieren könnt.

Die “prefers-reduced-motion” Media-Query

Glücklicherweise unterstützen euch viele moderne Browser und Betriebssysteme, eine Webseite weniger gefährlich zu gestalten. Ihr könnt einfach die prefers-reduced-motion Media-Query verwenden und eure Animationen mit dieser verschachteln. Sollte jemand, der eure Seite besucht eine entsprechende Einstellung gesetzt haben, werden Animationen nicht mehr abgespielt. Oder aber ihr verwendet die Media-Query, um damit zuvor gesetzte Animationen zu deaktivieren. Mehr zu der Media-Query findet ihr in einem englischsprachigen Artikel von CSS-Tricks.

Als Beispiel für eine Animation könnt ihr euch mal die aktuelle Startseite des WordCamp Europe 2020 ansehen. Hier wird dsa Logo durch eine Animation aufgebaut. Selbst wen diese Animation keine schnellen und großen Bewegungen enthält, so könnte es dennoch sein, dass Menschen mit einer solchen Beeinträchtigung lieber ein statischen Logo bevorzugen würden.

Das Design-Team hat es geschafft, das Logo alleine mit reinem HTML und CSS zu erstellen. Die Animation war aber nicht in die angesprochene Media-Query gesetzt worden. Wenn man nun also einfach alle Animationen ausschaltet, würde das Logo dar nicht erst sichtbar werden. Wie können wir das Problem also stattdessen lösen?

Die Animation “vorspulen”

Eigentlich ist die Lösung super einfach. Wir suchen uns alle Elemente der Animation heraus und verringern die Verzögerungen und die Dauer auf null Sekunden, womit das Logo sofort sichtbar wird. Der Code sieht also wie folgt aus:

@media (prefers-reduced-motion: reduce) {
    .wceuicon *,
    .wceuicon:before,
    .wceuicon:after,
    .wceu-logo-text * {
        animation-delay: 0s !important;
        animation-duration: 0s !important;
    }
}

Mit diesen wenigen Zeilen Code haben wir effektiv die Animation “deaktiviert” und die Webseite damit barrierefreier gemacht.

Reduzieren der Animation

Eine andere Lösung wäre eine Reduzierung der Animation. Ein problematischer Teil des Logos ist vermutlich der “blinkende Cursor” und die “einfliegenden Punkte”. Wir könnten also eine Animation erstellen, bei der die Punkte und der Cursor einfach an der endgültigen Position einfach erscheinen und die Animation sehr langsam abspielen lassen. So haben wir noch immer eine Animation, aber eben mit einer starken Reduzierung der Bewegungen.

Testen der Media-Query

Ihr werdet euch nun vermutlich fragen, wie ich diese neue Media-Query testen könnt. Viele moderne Betriebssysteme haben eine entsprechende Einstellung. Mozilla hat eine gute Übersicht zu den unterstützten Browsern und Betriebssystemen und erklärt, wo man die Einstellung findet. Auch auf der Google Developer Platform findet ihr nützliche Tipps zu der Media-Query und wie man sie testet.

Windows 10

Falls ihr Windows 10 verwendet, dann findet ihr die Einstellung unter “Systemsteuerung | Erleichterte Bedienung | Center für erleichterte Bedienung | Erkennen von Bildschirmobjekten erleichtern”:

Hier aktiviert ihr einfach die Checkbox “Alle nicht erforderlichen Animationen deaktivieren (wenn möglich)”. Diese Einstellung reduziert nicht nur die Animationen, sondern auch in anderen Programmen, die diese Einstellung unterstützt. Nachdem ihr die Einstellung übernommen habt, müsst ihr die Seite mit der Animation neu laden. Ihr solltet nun die optimierte/reduzierte Version sehen.

Android 9

Ich habe eine solche Einstellung auch auf meinem Smartphone gefunden. Sucht hier einfach nach “Bedienungshilfen” in den Einstellungen. Dort solltet ihr dann einen Schalter “Animation entfernen” finden.

Ähnliche Einstellungen findet ihr auch unter macOS und auf dem iPhone. Leider konnte ich auf meinem Arbeitslaptop mit Manjaro-Linux keine solche Einstellung findet. Wenn ihr wisst, wo diese zu finden ist, lasst es mich bitte wissen!

Fazit

Eine Webseite komplett barrierefrei zu machen ist sehr schwierig, da es viele Aspkete zu beachten gibt und manche nicht so bekannt sind wie andere. Wenn es aber darum geht, hier Prioritäten zu setzen, dann solltet ihr immer damit anfangen, was Menschen potentiell schaden könnte. Danach könnt ich euch mit den anderen Aspekten beschäftigen. Ich kann hierzu auch den englischsprachigen Vortrag von Sarah Brodwall auf dem letzten Accessibility Club Summit Berlin empfehlen.

Ich hoffe, ihr habt einen neuen Aspekt zur Barrierefreiheit kennengelernt und ich konnte euch überzeugen, es auf eurer Webseite einzusetzen. Falls ihr es schon kannten und eine Animation angepasst hat, dann hinterlasst bitte einen Kommentar, damit andere davon lernen können.