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 finden. 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.

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

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.

Ein paar einfache Schritte, um die Navigation barrierefreier zu machen

Ein neues Jahr, ein neues Blog-Projekt. Torsten Landsiedel hat seine Idee von regelmäßigen Blogbeiträgen wiederbelebt. Dieses Mal muss aber nicht jede Woche ein neuer Beitrag geschrieben werden, sondern es reicht ein Beitrag alle zwei Wochen aus, sowie ein Kommentar, ebenfalls alle zwei Wochen aus. Da ich schon in den vorherigen Projekten immer mit dabei war, lasse ich es mir natürlich auch dieses Mal nicht nehmen. Aber wie auch zuletzt, werde ich wieder zweisprachig bloggen. In der einen Woche in Englisch und dann in der Folgewoche mit dem gleichen Thema in Deutsch. So kommen also hoffentlich in diesem Jahr je 26 englische und deutsche Beiträge dazu.

Themenmonat Barrierefreiheit

Simon Kraft startet das neue Jahr ebenfalls mit einem kleinen Blog-Projekt. Er hat den Januar zum Themenmonat für Barrierefreiheit erklärt und alle, die Blogbeiträge, Podcasts oder Videos produzieren dazu aufgerufen, sich mit dem Thema zu beschäftigen. Unter dem Hashtag #FokusBarrierefreiheit sollen diese dann gesammelt werden. Dies ist also mein erster von zwei Beiträgen zu diesem wichtigen Thema, das mir persönlich sehr am Herzen liegt. Es werden im Laufe der Jahre aber vermutlich noch ein paar folgen.

Barrierefreie Navigationen

In diesem ersten Blogbeitrag im Jahr 2020 möchte ich euch zeigen, die ihr mit ein paar einfachen Schritten euere Website-Navigation barrierefreier machen könnt, sollte sie es nicht bereits sein. Der Fokus liegt hier vor allem auf der Bedienbarkeit mit Tastatur.

Verbessert die visuelle Barrierefreiheit

Die Navigation ist vermutlich das wichtigste Element einer jeden Website. Sowohl Menschen mit voller, als auch solche mit eingeschränkter Sehkraft finden die meisten Inhalte eurer Seite über die Navigation. Daher sollte die Navigation für alle „visuell barrierefrei“ sein. Das betrifft nicht nur Menschen, sondern auch technische Hilfsmittel wie etwa sogenannte Screenreader.

Versteckt die Untermenüs nicht

Wird ein Screenreader verwendet, dann können nur solche Elemente vorgelesen werden, die auch „sichtbar“ sind. Wenn also ein Untermenü über eine CSS-Regel ausgeblendet wird, dann sind diese Menüpunkte für Menschen die Screenreader und anderen Hilfsmittel verwenden nicht sichtbar.

Versteckt sie anders

Für eine klassische horizontale Navigation wird oft eine CSS-Regel verwendet, die in etwa wie folgt aussieht (hier am Bespiel des Yoko Themes von Elmastudio):

#branding #mainnav ul ul {
	display: none;
	float: left;
	position: absolute;
	top: 2em;
	left: 0;
	z-index: 99999;
}
#branding #mainnav ul li:hover > ul {
	display: block;
}

Das Untermenü wird hier standardmäßig ausgeblendet. Bei einem „Hover“ wird die display Eigenschaft dann auch block geändert, wodurch das Untermenü sichtbar wird.

Stattdessen kann man aber die Elemente einfach aus dem Viewport, dem sichtbaren Bereich, heraus verschieben, so dass die Elemente auch nicht mehr von Menschen gesehen werden können, aber weiterhin von Screenreadern:

#branding #mainnav ul ul {
	display: block;
	opacity: 1;
}
#branding #mainnav ul li:not(.focus):not(:hover) > ul {
	position: absolute;
	left: -999em !important;
	opacity: 0 !important;
}

Mit diesem Code zeigen wir Untermenüs immer an. Wir verschieben sie aus dem sichtbaren Bereich heraus und machen sie transparent – also ebenfalls „unsichtbar“ – solange der Hauptpunkt nicht fokussiert ist und nicht die CSS Klasse focus hat.

Stelle einen Fokus-Style bereit

Damit eine Navigation wirklich mit der Tastatur bedient werden kann, ist es nicht nur wichtig, dass alle Menüpunkte erreicht werden können. Es muss auch visuell erkennbar sein, an welcher Stelle der Navigation man sich mit der Tastatur gerade befindet.

Leider deaktivieren sehr viele Themes global die outline Eigenschaft für alle Elemente. Man kann nun also zur Lösung entweder die outline wiederherstellen oder aber den focus Zustand genau so stylen wie den hover Zustand. Für das Yoko Theme würde das wie folgt aussehen:

#branding #mainnav ul li a:focus,
#branding #mainnav ul li a.focus {
	background:#F0F0F0;
	color: #999;
}

Wir setzen hier den Style sowohl für den focus Zustand, als auch für Elemente mit der Klasse focus, was uns im zweiten Schritt helfen wird.

Verbesserung der Barrierefreiheit bei Benutzung der Tastatur

In den meisten Navigationen wird der hover Zustand verwendet, um ein Untermenü einzublenden. Wenn man sich aber mit der Tastatur durch die Seite navigiert, dann wird dieser Zustand nicht aktiviert und CSS-Regel werden nicht aktiv. Um die Navigation also besser benutzbar zu machen, verwenden wir ein wenig JavaScript, um eine CSS-Klasse focus hinzuzufügen, wenn/solange ein Hauptmenüpunkt oder ein Untermenüpunkt fokussiert ist:

( function() {
	var container, menu, links, i, len;
	var navigationContainerId = 'mainnav';
	var menuItemFocusedClass  = 'focus';

	container = document.getElementById( navigationContainerId );
	if ( ! container ) {
		return;
	}

	menu = container.getElementsByTagName( 'ul' )[0];

	if ( -1 === menu.className.indexOf( 'nav-menu' ) ) {
		menu.className += ' nav-menu';
	}

	// Get all the link elements within the menu.
	links = menu.getElementsByTagName( 'a' );

	// Each time a menu link is focused or blurred, toggle focus.
	for ( i = 0, len = links.length; i < len; i++ ) {
		links[i].addEventListener( 'focus', toggleFocus, true );
		links[i].addEventListener( 'blur', toggleFocus, true );
	}

	/**
	 * Sets or removes .focus class on an element.
	 */
	function toggleFocus() {
		var self = this;

		// Move up through the ancestors of the current link until we hit .nav-menu.
		while ( -1 === self.className.indexOf( 'nav-menu' ) ) {

			// On li elements toggle the class .focus.
			if ( 'li' === self.tagName.toLowerCase() ) {
				if ( -1 !== self.className.indexOf( 'focus' ) ) {
					self.className = self.className.replace( ' focus', '' );
				} else {
					self.className += ' focus';
				}
			}

			self = self.parentElement;
		}
	}
} )();

Wenn ihr dieses Snippet einsetzt, könnt ihr einfach das id Attribut des Containers der Navigation und die CSS-Klasse, die ein fokussiertes Element bekommen soll, in den Zeilen 3 und 4 eintragen. Das Snippet kommt auch ganz ohne Bibliotheken wie jQuery aus und sollte in jedem Theme funktionieren, das die normale WordPress Navigation und keine zusätzlichen JavaScript-Optimierungen für die Navigation verwendet. Es handelt sich bei dem Snippet um eine geringfügig an Version des _s Themes.

Wenn ihr diesen Snippet zu eurer Seite hinzufügt, kann durch alle Haupt- und alle Untermenüpunkte unter Verwendung der Tab-Taste vorwärts und rückwärts navigiert werden.

Bonus: Verbesserung der Benutzerbarkeit auf Tablets

Ein weiteres typisches Problem beim Einsatz des hover Zustands in einer horizontalen Navigation ist der Umstand, dass es einen solchen auf mobilen Geräten wie etwa Tablets nicht gibt. Klickt man also auf einen Hautptmenüpunkt, wird kurzzeitig das Untermenü sichtbar, die Seite wird aber sofort auf den angeklickten Hauptmenüpunkt wechseln.

Wir möchten aber, dass beim ersten Klick auf den Menüpunkt das Untermenü sichtbar wird und erst beim zweiten Klick der Link unter dem Hauptmenüpunkt aufgerufen wird. Hat ein Hauptmenüpunkt keine Untermenüpunkte, dann soll bereits der erste Klick zu der entsprechenden Seite führen. Das kann mit folgendem zusätzlichen Snippet erreicht werden:

( function() {
	var container;
	var navigationContainerId = 'mainnav';
	var menuItemFocusedClass  = 'focus';


	container = document.getElementById( navigationContainerId );
	if ( ! container ) {
		return;
	}

	( function( container ) {
		var touchStartFn, i,
			parentLink = container.querySelectorAll( '.menu-item-has-children > a, .page_item_has_children > a' );

		if ( 'ontouchstart' in window ) {
			touchStartFn = function( e ) {
				var menuItem = this.parentNode, i;

				if ( ! menuItem.classList.contains( menuItemFocusedClass ) ) {
					e.preventDefault();
					var menuItemLength = menuItem.parentNode.children.length;
					for ( i = 0; i < menuItemLength; ++i ) {
						if ( menuItem === menuItem.parentNode.children[i] ) {
							continue;
						}
						menuItem.parentNode.children[i].classList.remove( menuItemFocusedClass );
					}
					menuItem.classList.add( menuItemFocusedClass );
				} else {
					menuItem.classList.remove( menuItemFocusedClass );
				}
			};

			var parentLinkLength = parentLink.length;
			for ( i = 0; i < parentLinkLength; ++i ) {
				parentLink[i].addEventListener( 'touchstart', touchStartFn, false );
			}
		}
	}( container ) );
} )();

Das Snippet reagiert auf das ontouchstart Event und stellt die notwendigen Anpassungen für eine Drop-Down-Navigation auf mobilen Endgeräten bereit.

Fazit

Es ist nicht wirklich schwer eine Navigation barrierefrei zu machen. Man muss lediglich ein wenig das CSS anpassen und etwas JavaScript verwenden. Am besten setzt man das Ganze in einem Child-Theme um. Man kann die Anpassungen aber auch als Verbesserung am Originaltheme melden, damit alle, die das Theme einsetzen, davon profitieren. Für das Yoko Theme habe ich die Lösung mal als Plugin zusammengefasst, das alle Verbesserungen enthält. Versucht es doch mal selbst! Installiert euch das Yoko Theme und versucht auf der Seite nur mit dem Keyboard zu navigieren. Installiert und aktiviert dann das Plugin und versucht es erneut. Testet ebenfalls mal die Navigation mit einem Tablet, indem ihr die Geräte-Emulation eures Browsers verwendet.

Im Anschluss solltet ihr mal euer eigenes Theme testen. Ist es bereits barrierefrei? Falls nicht, könnt ihr es mit den hier vorgestellten Techniken einfach barrierefreier machen? Sollte euer Theme ein sogenanntes „Hamburg-Menü“ verwenden, dann schaut euch mal den gesamten Code des _s Themes an, das ein solches Menü mit Untermenüs sehr gut bedienbar und barrierefrei umsetzt.

Direktanruf von Website ermöglichen

In meinem letzten Blogbeitrag habe ich darüber geschrieben, wie man Icon-Web-Fonts anpassen und optimieren kann, um Social-Media-Icons zur Website hinzuzufügen. In dem beschriebenen Projekt ging es darum, ein Icon hinzuzufügen, mit dem direkt ein Anruf gestarten werden konnte.

Protokoll für den Anruf von einer Website

Um es jemandem zu ermöglichen, eine Nummer direkt anzurufen, muss man diese einfach in einen normalen Link setzen und hierbei dann das tel Protokoll verwenden. Ein solcher Link sieht dann wie folgt aus:

<a href="tel:+49-12-3456789">012 / 3456789</a>

In diesem Beispiel habe ich einen Ländercode für Deutschland verwenden. Das ist technisch nicht unbedingt notwendig, es ermöglicht es aber, den Anruf auch dann zu tätigen, wenn sich die Person, die den Link klickt, nicht im Inland aufhält. Zur besseren Lesbarkeit können Bindestriche verwendet werden, man kann den Link aber auch als +49123456789 schreiben. Im Linktext kann ein beliebiges Format verwendet werden oder alternative auch ein beliebiger Text wie etwa Rufen Sie uns an, genau wie auch bei jedem anderen Link.

Was passiert, wenn der Lin angeklickt wird?

Auf einem mobilen Endgerät wird in der Regel automatisch die Nummer angerufen oder aber nach der Auswahl einer App gefragt, sollten mehrere Apps installiert sein, mit denen man einen Anruf tätigen kann (wenn etwa die Standard Telefon-App und Skype installiert sind).

Und wie verhält sich ein Desktop-Browser?

Selbst auf einem Desktop-Browser kann ein solcher Link verwendet werden. Klick man ihn mit einem Linksklick an, würde es im Chrome Browser wie folgt aussehen:

Wenn man also ein Smartphone mit dem eigenen Profil verbunden hat, kann man die Telefonnummer an sein Smartphone schicken lassen. Alternativ kann man eine andere App auswählen.

Bei einem Rechtsklick auf den Link ist es ebenfalls möglich, die Nummer an das Smartphone zu schicken. Die Auswahl einer anderen App ist hier leider nicht möglich:

Alternative Protokolle

Das tel Protokoll funktioniert mit normalen Anrufen auf mobilen Endgeräten und dem Desktop. Auf mobilen Endgeräten kann man auch oft eine alternative VoIP App wie etwas Skype verwenden. Aus dem Desktop wird Skype leider nicht angeboten. Möchte man aber über Skype angerufen werden, muss man stattdessen das callto Protokoll verwenden.

Weiterhin gibt es noch das sms und fax Protokoll, die aber nur von sehr wenigen Browsern unterstützt werden.

Fazit

Möchte man es jemandem ermöglichen sehr einfach eine Telefon zu starten, dann sollte man einen solchen Link auf der eigenen Website anbieten. Einen sehr guten Überblick darüber, wie sich verschiedene Browser verhalten liefert CSS-Tricks (Englisch). Warum versuchst du es nicht einfach mal auf deiner eigenen Website aus, falls du bisher noch keinen solchen Link hast?

Icon-Web-Fonts für deine Bedürfnisse optimieren

Auf so gut wie jeder modernen Website findet man Icons. Sie werden sehr oft genutzt, um auf Social-Media-Profile zu verlinken. Oft werden diese Icon-Fonts bereits mit den WordPress-Themes mitgeliefert. Ich verwende mittlerweile für selbst geschriebene Themes in der Regel SVG-Symbole anstalle von Icon-Web-Fonts. Aber wenn man ein Themes nur ein wenig anpassen möchte, dann sind Web-Fonts eventuell doch die bessere Wahl.

Web-Fonts lokal laden

Viele laden Web-Fonts mittlerweile aufgrund der DSGVO lokal. Zu diesem Zweck werden sie meistens runtergeladen und ins Child-Theme integriert. Dies ist die perfekte Gelegenheit, sich darüber Gedanken zu machen, welche Icons man wirklich braucht. Icon-Fonts für Social-Media-Profile sind ein sehr gutes Beispiel dafür, wieso man die Schrift vielleicht anpassen möchte.

Eine Icon-Web-Font anpassen

Nehmen wir die beliebte Schriftart Font Awesome als ein Beispiel. Sie enthält 1544 Icons, 433 dafür für Markenlogos und Social-Media-Icons. Aber braucht man wirklich alle davon? Falls nicht, würde es sich anbieten, nur die Icons zu laden, die man wirklich benötigt. In einem SVG Sprite könnte man überflüssige Symbole einfach löschen, in einer Web-Font ist das etwas schwieriger.

Online-Service für die Anpassung von Schriften

Für ein Projekt stand ich vor der Aufgabe ein Social-Media-Profil zu verlinken, zu dem die im Theme enthaltene Schriftart kein passendes Icon zur Verfügung stellte. Ich habe mich also dafür entschieden, hier Font Awesome einzusetzen. Auf der Suche nach einer Möglichkeit nur einige Icons zu nutzen, bin ich auf die Seite Fontello gestoßen. Hier kann man aus einer Vielzahl an Icon-Web-Fonts auswählen und eine davon ist Font Awesome.

Auf der Website kann man sehr einfach über zwei Suchfelder nach dem Namen einer Schriftart oder dem Namen der Icons suchen. Durch Mehrfachauswahl kann man die benötigten Icon markieren. Hier sollte man eventuell auch gleich Icons auswählen, die man in Zukunft auch noch brauchen könnte.

Auf einem weiteren Tab kann man die Namen der Icons oder den Unicode für die resultierenden Dateien festlegen. Dann lädt man die Datei mit der Auswahl herunter, die die Schrift in verschiedenen Formaten sowie das notwendige CSS enthält.

Viel Bandbreite einsparen

Aber lohnt sich das alles? Font Awesome verwendet 3 Dateien für verschiedene Icon-Typen in jeweils 5 Formaten. Die woff2 Dateien haben insgesamt 165kB. Hinzu kommen noch 57kB für das minifizierte CSS.

Für das beschriebene Projekt benötigte ich aber nur 9 Icons und die woff2 Datei hatte lediglich 4kB. Hinzu kamen noch 2kB CSS (unminifiziert), welche auf 1kB (minifiziert) reduziert werden kann.

Insgesamt können also 2 Dateien/Requests und fast 98% Bandbreite (217kB) eingespart werden.

Optimiere deine Schriften!

Wie du als sehen kann, bietet die Optimierung von Icon-Fonts ein großes Potential Bandbreite einzusparen und deine Seite schneller laden zu lassen. Der einzige Nachteil ist, dass man die Schrift manuell erweitern muss, wenn man neue Icons benötigt.

Wenn man Google Fonts verwendet, kann man über den text Parameter sehr einfach definieren, welche Zeichen man benötigt. Leider findet man bei Google Fonts keine Icon-Web-Fonts und ich konnte auch keine andere Seite finden, die eine ähnliche Funktion anbietet. Solltet ihr eine solche Seite kennen, hinterlasst bitte einen Kommentar mit dem Tipp.

Ein Jahrzehnt in der WordPress Community

Wenn dieser Artikel online geht, stehe ich gerade auf der Bühne und eröffne das WordCamp Europe 2019 in Berlin. Hinter mir liegen 10 Monate Organisationarbeit für ein Event mit mehr als 3000 Teilnehmenden und 10 Jahre in der WordPress Community. Vor mir liegen noch zwei Tage WordCamp, viel Arbeit und zum Abschluss eine hoffentlich unvergessliche After-Party. Aber gehen wir zurück an den Anfang.

Meine Anfänge mit WordPress

Heute vor 10 Jahren ging mein erster Blogbeitrag online. Der Anlass für mich, mit dem Bloggen zu beginnen, war ein Plugin, dass ich zwei Wochen zuvor geschrieben und ins Plugin-Verzeichnis hochgeladen hatte. Um es der Öffentlichkeit zu präsentieren, habe ich dann selbst das System dahinter verwendet und 10 Jahre später bin ich noch immer dabei.

Meine ersten Berührungspunkte mit der Community

Auch wenn ich durch meine ersten Plugins und meine Blogbeiträge schon „Teil der Community“ war, so hatte ich bisher immer nur online Kontakt zu anderen Menschen aus der Community. Das änderte sich schon 2010 mit dem Besuch meines ersten WordCamps. Das fand in dem Jahr in Berlin statt, wo ich seit 2008 wohne und da es auf einem Samstag stattfand konnte ich teilnehmen und zum ersten Mal die ganzen schlauen Köpfe hinter den Blogbeiträgen kennenlernen, die mir in meinem ersten Jahr so viel beigebracht haben.

Die ersten deutschen Meetups

Ein Jahr später hatte ich schon fünf Plugins veröffentlicht und weiter auf meinem Blog fleißig über meine Arbeit mit WordPress und darüber hinaus gebloggt. Mein nächstes Community-Event war dann das WordCamp 2011 in Köln, der Heimatstadt meines Vaters und somit auch ein perfekter Ort für mich, um erneut teilzunehmen. Auf diesem WordCamp kam dann die Idee auf, sich mehr als einmal im Jahr an einem einzigen Ort in Deutschland zu treffen und die Idee der WordPress Meetups war gebohren.

Eine der ersten Städte mit einem Meetup war Potsdam. Das erste fand im November 2011 um 18:30 Uhr abends statt, was für mich aber durch den recht langen Anfahrtsweg aus Berlin etwas ungünstig lag. Aber im Dezember habe ich dann meine Arbeitszeit entsprechend geplant und konnte dabei sein. Seitdem bezeichne ich mich als „echtes“ Mitglied der (deutschen) WordPress Community.

Die Rettung der deutschen WordCamps

Bis einschließlich 2011 wurden alle WordCamps in Deutschland von der Agentur Inpsyde organisiert. Im Frühjahr 2012 saßen wir beim Meetup in Potsdam und fragten uns, wann und wo wohl das WordCamp 2012 stattfinden würde. Leider mussten wir feststellen, dass Inpsyde in diesem Jahr kein WordCamp ausrichten würde. Also beschlossen ein paar mutige Mitglieder des Meetups, es doch einfach selbst in die Hand zu nehmen, ohne jemals etwas derartiges organisiert zu haben. Aufgrund von neuen Strukturen in der Ausrichtung von WordCamps weltweit, war es uns aber nicht möglich/gestattet, unser Event WordCamp zu nennen und so war das WP Camp gebohren. Es wurde ein voller Erfolg und im Anschluss gab es in vielen weiteren Städten neue WordPress Meetups, so auch in Berlin, dass aber nicht von mir, sondern einem anderen Mitglied der Berliner Community gegründet wurde.

Eigentlich wollten wir nur ein einziges WP Camp in Berlin ausrichten, aber da sich noch keine andere WordPress Community aus den anderen Städten bereit erklärte, das Ruder zu übernehmen, gab es auch 2013 noch einmal ein WP Camp in Berlin. Im gleichen Jahr übernahm ich auch die Leitung des WordPress Meetup Berlin, da sich Gründer aus der WordPress Community zurückzog.

Mein erstes internationales WordCamp

Ebenfalls 2013 habe ich, eher aus einem glücklichen Zufall heraus, mein erstes internationales WordCamp besucht. Caspar Hübinger, einer der beiden Begründer des WordPress Meetups Potsdam und Co-Organisator der beiden WP Camps hatte ein Ticket für ein WordCamp mit dem vielversprechenden Namen WordCamp Europe übrig. Und so ergab es sich, dass ich mit noch zwei weiteren Community Mitgliedern in einem Partybus Richtung Leiden aufbrach, um die internationale Community kennenzulernen.

Das erste „offizielle“ WordCamp in Deutschland

Nach zwei Jahren „Rebellion“ war es dann 2014 soweit, und das WordCamp Hamburg wurde das erste WordCamp in Deutschland, das offiziell über die WordPress Foundation organisiert wurde. Zu diesem Anlass kamen auch einige internationale Gäste. Ich selbst war als Speaker vor Ort dabei.

Berufliche Neuorientierung

Bis zum Jahr 2015 war WordPress, Blogging und Plugin-Entwicklung nur ein großes Hobby für mich, das mir sehr viel Spaß gemacht hat. Ich hatte aber schon lange das Gefühl, dass ich mich auch beruflich damit beschäftigen möchte. Denn was gibt es besseres, als dafür bezahlt zu werden, das einem leidenschaftlich viel Spaß macht.

Das bekam auch Christian Fuchs, der zweite Begründer des WordPress Meetup Potsdam mit und er wusste, dass Nico Danneberg, der ebenfalls bei der Organisation des zweiten WP Camps dabei war, neue Mitarbeiter in dem Bereich sucht. Und so kam es dann, dass ich im Frühjahr 2015 bei der VCAT Consulting GmbH in Potsdam einen Job als PHP-Entwickler bekam.

Die Entscheidung zur Bewerbung für das WordCamp Europe in Berlin

Nachdem ich auch 2014 beim WordCamp Europe in Sofia dabei gewesen war, wuchs der Wunsch, sich für das WordCamp Europe mit Berlin zu bewerben. Damals versuchten wir unter Federführung von Heiko Mamerow für das Jahr 2016, aber unsere Bewerbung war nicht stark genug, um sich gegen Wien durchzusetzen. In Sevilla gab es aber auf dem WordCamp Europe einen runden Tisch, an dem alle Interessenten für die Organisation eines zukünftigen WordCamp Europe eingeladen waren, sich zu informieren. So beschloss ich dann, es noch einmal zu versuchen. Zuerst aber, richtete Berlin noch einmal ein lokales WordCamp in Berlin Ende 2015 aus. Es war auch das erste Jahr, in dem es mehr als nur ein WordCamp in Deutschland gab, denn bereits im Sommer fand wieder eines in Köln statt.

Erste Erfahrungen mit der Organisation eines WordCamp Europe

Die Vorbereitung auf die große Aufgabe habe ich mir nicht auf die leichte Schulter genommen. Daher habe ich mich für das WordCamp 2016 in Wien erst einmal als Volunteer gemeldet, um einen ersten Eindruck hinter die Kulissen zu bekommen. Der großen Teamgeist, den ich dort erlebt habe, hat mich einmal mehr bestärkt, dieses Projekt unbedingt angehen zu wollen. Auf dem Contributor Day gab es erneut einen runden Tisch und ich konnte mir noch einige neue Informationen haben. Aber obwohl wir gebeten wurden, uns doch schon für 2018 zu bewerben, habe ich uns noch nicht bereit dazu gesehen.

Das erste Mal Co-Organizer des WordCamp Europe

Im Jahr 2017 fand das WordCamp Europe in Paris statt. Ich hatte mich als Organizer beworben und wurde in das Design-Team aufgenommen, was mich im ersten Moment sehr verwundert hatte, da ich ja kein Designer bin. Aber ich konnte einen wichtigen Beitrag leisten und zusammen mit meinem Teammitgliedern ein neues Standardtheme für WordCamps programmieren, das seit 2017 für alle WordCamp Europe Websites (und auch von vielen anderen WordCamps) verwendet wird. Da ich aber unbedingt noch weitere Erfahrung als Organizer sammeln wollte, habe ich zusätzlich als Lead Organizer die Leitung über das WordCamp Berlin 2017 übernommen. Zurückblickend nicht unbedingt die beste Idee, aber es hat mich sehr darauf vorbereiten können, welchen Stressresistenz und welche Problemlösefähigkeit man als Lead Organizer haben muss.

Ein weiteres Jahr WordCamp Europe Organisation

Selbstverständlich war ich auch 2018 wieder im Organisationsteam dabei. Dieses Mal im sogenannten Content-Team, das sich um das Programm der Vorträge sowie die Betreuung der Vortragenden kümmert. Mein Team-Lead war wie schon im Jahr zuvor Sonja Leix, von der ich sehr viel über die Leitung eines Team lernen konnte. Im Januar 2018 startete der Call for #WCEU 2019 Host Cities, also die Bewerbungsphase für das WordCamp Europe 2019. Neben meiner Organisationsarbeit für 2018 musste ich also mit tatkräftiger Unterstützung aus der deutschen Community ein komplettes WordCamp planen und mich damit offiziell bewerben.

Das WordCamp Europe 2019 in Berlin

Zu unserer großen Freude bekam Berlin den Zuschlag und daher stehe ich nun heute hier auf der Bühne und eröffne zusammen mit dem Global-Lead-Organizer Milan Ivanovic, auf den Tag genau 10 Jahre nach dem Start dieses Blogs, das WordCamp Europe 2019. Hinter uns liegen 10 Monate arbeit mit einem großen Team aus über 60 Organizern aus der ganzen Welt. Meine Reise als Mitglied der WordPress Community und als Organisator von WordCamps war eine sehr aufregende. Ich freue mich aber schon auf das nächste Jahr, in dem ich wieder im Organisationsteam des WordCamp Europe dabei sein werde. In welcher Rolle und in welcher Stadt, das erfahrt ihr alle in den Closing Remarks morgen nach dem Ende des zweiten Konferenztages.

Und was ist mit dem Blog und den Statistiken?!

Diejenigen von euch, die schon seit Jahren meinen Blog lesen, werden jetzt vielleicht etwas enttäuscht sein, dass ich hier nicht wie sonst üblich Zahlen zu meinem Blog veröffentliche. Wie ihr vermutlich schnell feststellen werdet, habe ich in den vergangenen 12 Monaten nicht einen neuen Beitrag geschrieben. Ich habe mir ganz bewusst eine Auszeit genommen, um mich voll und ganz auf die Organisation konzentrieren zu können. Ich möchte auch keine Versprechen machen, die ich am Ende vielleicht nicht halten werden, aber in den nächsten 12 Monaten wird es sicher ein paar zusätzliche Beiträge geben. Im Juli und August machen alle Organisatoren offiziell eine Pause und ich hoffe mal, dass ich diese auch einhalten kann.

Ein weiteres Jahr geht zu Ende und das aufregendste steht bevor!

Wie jedes Jahr möchte ich es auch heute nicht versäumen, euch einen kleinen Überblick zu geben, was im letzten Jahr so alles passiert ist und was euch in den nächsten 12 Monaten erwarten wird.

Ein arbeitsreiches Jahr

Seit Jahresbeginn habe ich leider nicht viel Zeit gefunden einmal regelmäßig pro Woche zu bloggen. Der Grund dafür ist mein Engagement in der Organisation des WordCamp Europe. Auch aktuell stecke ich noch "ein wenig" darin fest. Und daher werde ich den Artikel heute leider nicht fertigstellen können, da ich meine Statistiken noch nicht zusammenstellen konnte. Ich werde den Artikel daher am Wochenende fertigstellen, bleibt also gespannt, welche Neuigkeiten euch erwarten werden 😉

Fortsetzung folgt…

Weiterlesen →

SASS automatisch mit File Watchers in PhpStorm kompilieren

Im ersten Beitrag dieser kleinen Beitragsreihe habe ich euch gezeigt, wie ihr SASS installieren und manuell mit dem Terminal kompilieren könnt. Aber dieser Weg ist nicht besonders nutzerfreundlich und man kann schnell mal vergessen den Compiler/Watcher zu starten, wenn man an einem Projekt arbeitet.

Einen File-Watcher erstellen

Der einfachste Weg, einen File-Watcher zu erstellen ist es, einfach eine SASS-Datei zu öffnen. PhpStorm erkennt diese und zweigt auch eine kleine Benachrichtigung oberhalb des Dateiinhalts an. Klickt hier einfach auf „Yes“ und ihr gelangt zu den Einstellungen:

Falls ihr die Benachrichtigung nicht sehr, könnt ihr über „File | Settings | Tools | File Watchers“ ebenfalls zur Einstellung navgieren. Hier klickt ihr auf der rechten Seite auf das grüne Plus-Symbol und fügt einen neuen File-Watcher für SCSS hinzu (nicht SASS, da dies der File-Watcher für Dateien im .sass Format mit der alternativen Syntax ist, die nur noch sehr selten eingesetzt wird):

Die Einstellungen des File-Watchers anpassen

Die Standardeinstellungen sind schon ganz gut. PhpStorm wird vermutlich selbst rausfinden, wo sich der sass Befehl befindet. In meinem Fall ist es ein Windows Dateipfad:

Eine Option, die ich in der Regel ändere sind die „Argument“ Einstellungen. Ich bevorzuge den „expanded output style“ und nicht den „nested style“, da er mehr wie normales CSS aussieht, so wie man es manuell schreiben würde. Meine „Arguments“ Einstellung sieht wie folgt aus:

--style expanded --no-cache --update $FileName$:$FileNameWithoutExtension$.css

Fazit

Das war es schon. Ab sofort werden alle Änderungen in SCSS Dateien automatisch in CSS Dateien kompiliert (ihr müsst die Dateien nicht mal explizit speichern). Der File-Watcher erkennt sogar Änderungen in solchen Dateien, die lediglich in andere importiert wurden. Wenn ihr gerade nicht wisst, was ich damit meine, wartet einfach auf meinen nächsten Beitrag, in dem ich auch die Grundlagen von SASS eingehen werde.

Hinweis: Falls ihr „Tools | Deployment“ verwendet, um Änderungen in PhpStorm automatisch an einen FTP-Server zu senden, dann müsst ihr „Upload external changes“ in den „Option“ aktivieren, da ansonsten die kompilierte CSS Datei nicht hochgeladen würde.

Ein intensives Jahr im Rückblick

Zuerst einmal ein frohes neues Jahr euch allen! Ich hoffe ihr seid alle gut ins Jahr 2018 gestartet. Da ihr vermutlich gemerkt habt, dass ich in den letzten Wochen nicht gebloggt habe, möchte ich euch einen kleinen Rückblick über das letzte Jahr geben, sowie meine Pläne für dieses Jahr.

#Projekt52 zweisprachig

Für 2017 hatte ich geplant, meinen wöchentlichen Veröffentlichungsrhytmus fortzusetzen. Aber anders als zuvor wollte ich immer zuerst auf englisch bloggen und den Beitrag dann in der folgenden Woche ins Deutsche übersetzen.

In den ersten 11 Monaten hat es auch super funktioniert. Ich habe mindestens einmal pro Woche gebloggt und dabei auch gleich noch ein paar kleine Plugins erstellt. Aber dann kam der Dezember und die Frage, ob ich erneut einen Adventskalender machen könnte, nur dieses mal in zwei Sprachen.

Der Adventskalender 2017

Vielleicht werdet ihr nun sagen, dass ich verrückt oder zu ambitioniert war, aber ich habe trotzdem im dritten Jahr in Folge einen Adventskalender gestartet, obwohl ich keinen einzigen Beitrag vorbereitet hatte. Die ersten 9 Tage lief auch alles richtig gut. Manchmal habe ich den Beitrag erst nach Mitternacht veröffentlicht, aber ich habe es dennoch geschafft einige interessante Themen zu finden. Aber dann ich meine Serie abgebrochen.

Prioritäten setzen

Das Bloggen ist für mich noch immer nur ein Hobby. Es macht mir zwar sehr viel Spaß mein Wissen zu teilen und Reaktionen darauf zu bekommen. Aber es gibt wichtigere Dinge im Leben und dieses Jahr haben mich Freunde und Familie mehr gebraucht als meine Leserinnen und Leser. Nachdem ich also etwa eine Woche keinen neuen Blogbeitrag veröffentlichen konnte, habe ich beschlossen, für den Rest des Jahres eine Pause einzulegen. Denn beim Versuch das alles nachzuholen wäre ich vermutlich ausgebrannt.

Pläne für 2018

Wie sehen also meine Pläne für dieses Jahr aus? Mit meinem letzten Beitrag vom 10. Dezember habe ich eine kleine Blogserie gestartet. Obwohl die Idee zu dieser Reihe nicht mehr so aktuell ist, hoffe ich dennoch, dass es interessant bleibt. Ich werde auch dieses Jahr wieder zweisprachig bloggen. Und ich werde auch wieder versuchen einen Adventskalender zu schreiben. Vielleicht schaffe ich es ja dieses Mal ein paar Beiträge vor dem 1. Dezember vorzubereiten 😉

Wenn ihr ein Thema habt, dass ihr gerne mal bearbeitet haben möchtet und zu dem ihr euch vorstellen könnt, dass ich dazu etwas erzählen kann, hinterlasst mir einfach einen Kommentar. Und falls ihr euch ebenfalls Vorsätze für das neue Jahr gemacht habt und mutig genug seid, diese zu teilen, schreibt auch hierzu gerne einen Kommentar 🙂

Ich wünsche euch allen nur das Beste für 2018 und ich hoffe natürlich einige von euch auf einem zukünftigen WordCamp zu sehen.