ServiceWorker

Eine verlässliche Internetverbindung, und damit den ständigen Zugriff auf Webseiten oder Server, gibt es zwar theoretisch, der Alltag sieht jedoch anders aus. An manchen Orten ist nur eine Verbindung in Edge-Geschwindigkeit möglich, an anderen Tagen scheint LTE in vollem Umfang verfügbar, die Verbindung klappt trotzdem nicht. In anderen Situationen hat eine scheinbar schnelle DSL-Anbindung Schluckauf was eine verlässliche Datenübertragung unmöglich macht.

Um Webseiten auch in den eben beschriebenen Szenarien benutzbar zu machen, steht in einigen aktuellen Browsern ServiceWorker zur Verfügung. Chrome und Firefox unterstützen die Technologie bereits, in den kommenden Versionen von Edge und Safari wird sie erwartet.

Artikel, Vorträge und Tweets zu ServiceWorker verfolge ich seit einiger Zeit interessiert. Am vergangenen Wochenende führte dieses Interesse zur Implementierung eines ServiceWorker für diese Webseite. Der Artikel Progressing the web von Jeremy Keith gab mir den entscheidenden Schubs mich tatsächlich dran zu wagen.

Um meinen eigenen ServiceWorker zu erstellen orientierte ich mich an dem von Jeremy Keith und kombinierte diesen mit den Hinweisen von Michael Scharnagl, der in seinem Blog darüber schreibt wie er für seine WordPress-Seite einen eingerichtet hat. Das daraus resultierende ServiceWorker-Skript für diese Webseite findest Du hier.

Auf welche Punkte lohnt es sich zu achten

Der ServiceWorker muss im Root Verzeichnis liegen. Um ihn dennoch über das Theme verwalten zu können, folge ich dem Beispiel von Michael Scharnagl und erstelle einen Symbolic Link im Root Verzeichnis, der auf das Skript im Assets-Verzeichnis des Themes verweist.

$ ln -s /var/www/virtual/user/wp-content/themes/netz/assets/js/serviceworker.min.js /var/www/virtual/user/serviceworker.min.js

Den ServiceWorker registriere ich in der footer.php durch folgenden Aufruf:

if (navigator.serviceWorker) {
    navigator.serviceWorker.register('/serviceworker.min.js', {
        scope: './'
    });
    window.addEventListener('load', function() {
        if (navigator.serviceWorker.controller) {
            navigator.serviceWorker.controller.postMessage({'command': 'trimCaches'});
        }
    });
}

Der zweite Teil dieses Skripts ruft die trimCaches-Funktion auf, die dafür sorgt, dass der Speicherhunger des ServiceWorkers nicht unersättlich ist, und ab einer gewissen Anzahl von gespeicherten Inhalten, die ältesten Einträge löscht.

Den ServiceWorker habe ich so geschrieben, dass er Stylesheet, Javascript, die Hauptseiten und besuchte Seiten speichert. Diese stehen fortan sowohl dann zur Verfügung wenn die Besucherin offline ist als auch dann wenn der Server nicht erreichbar ist. Für den Fall, dass die angeforderten Inhalte nicht im Zwischenspeicher sind, habe ich eine Seite mit meinen Kontaktdaten und einer kurzen Info erstellt. Die Besucherinnen dieser Webseite bekommen also entweder die gewünschten Inhalte oder eine kurze Info und Kontaktdaten angezeigt, und nicht wie bisher die Offline-Meldung des Browsers.

Bis zur Implementierung des ServiceWorkers gab ich meinem Stylesheet und dem Javascript eine Versionsnummer mit, dieses führte jedoch zu Fehlern beim Aufruf der Webseite aus dem Speicher. Daher hänge ich momentan keine Versionsnummer an meine eigenen Dateien an. Dies möchte ich demnächst aber wieder ändern, wollte es hier jedoch nicht unerwähnt lassen, da ich einen Moment gebraucht habe, um die Quelle der Fehler zu finden.

Um die Implementierung des ServiceWorkers abzurunden, fügte ich dieser Webseite noch ein manifest.json hinzu, so dass Chrome sie zukünftig als Webapp erkennt. Auf diese Weise lässt sie sich als Progressive Web App installieren, und dadurch ganz einfach starten.

Ausblick

Für die neuen Versionen von Safari und Edge ist die volle Unterstützung von ServiceWorker angekündigt. Und die kommende iOS-Version soll Progressive Web Apps unterstützen, wodurch schließlich eine Installation einer Webapp auf den Homescreen von iPhone und iPad nichts mehr im Wege steht.

Um Service Worker besser zu verstehen habe ich mir vorgenommen den Vortrag The Pragmatist’s Guide to Service Workers, den Lyza D Gardner auf der SmashingConf Freiburg 2016 gehalten hat, nochmals anzusehen.

Gelingende Teamarbeit

Auf Zeit Online las ich gestern ein Interview mit Ingrid Gerstbach, Expertin für Design Thinking und Innovationsmanagement, über introvertierte Menschen und deren Chancen im Job. In einer von Extrovertierten dominierten Arbeitswelt wirken introvertierte Menschen oft schwach und es scheint als hätten oder wollten sie nichts beitragen.

Gerstbach plädiert in dem Interview dafür, nicht die Introvertierten ändern zu wollen, sondern an der (Meeting-)Kultur zu arbeiten.

»Introvertierte Menschen beobachten viel und nehmen neben dem, was gesagt wird, auch noch die Stimmung in einem Raum wahr. Das überfordert und kann dazu führen, dass sie sich nicht mehr auf ihre eigenen Ideen fokussieren können und verstummen.«

Es kann als Schwäche ausgelegt werden, wenn eine Person sich nur unter großer Kraftanstrengung zu Wort melden kann, gleichzeitig sollte jedoch die Reflektiertheit und Achtsamkeit – auch auf Stimmungen – als Stärke betrachtet werden.

Gerstbach spricht auch davon, dass es eher kontraproduktiv ist eine stillere Person direkt in der Situation zu Wort zu bitten, sondern regt dazu an über alternative Zugänge nachzudenken. Zweiergespräche bieten sich eher zu konkreter Nachfrage an, als die Gruppensituation, und auch für diese schlägt sie eine gute Methode vor:

»Gerade in Gruppensituationen sollen Ideen entstehen und die Kreativität fließen. Das ist natürlich schwierig, wenn die einen die anderen dominieren. Um das Ungleichgewicht rauszunehmen, lasse ich viel schreiben. Eine Methode ist das Brainwriting, eine Form des Brainstorming: Jeder schreibt seine Ideen zu einem Thema für sich auf und gibt sie dann an den Nachbarn weiter. Der Nachbar ergänzt die Karte des anderen, fügt seine Gedanken hinzu. Das führt dazu, dass sich jeder mit einer Idee intensiver auseinandersetzt und nicht eine laute Person von Anfang an das Brainstorming an sich reißt. Die Methode zwingt alle ein bisschen zur Stille. Gerade den Introvertierten fällt es leichter, zu schreiben. Aber es hilft allen, denn wenn der Kopf erst mal leer ist, kann man besser zuhören. So werden alle Ideen gleichwertig behandelt und es gewinnt nicht der, der seine Idee als Erstes oder am lautesten vorträgt.«

Methodische Reflexion im Kontext von Besprechungen scheint mir nach wie vor als wichtigen Schritt hin zu einem gleichwertigen Austausch aller Beteiligten.

An dem Interview gefällt mir, dass sowohl die Kultur angesprochen wird, die in vielen Zusammenhängen gelebt wird, als auch konkrete Anregungen gegeben werden, wie erfolgreiche Teamarbeit aussehen kann.

Quelle: ZEIT ONLINE: Introvertierte, Bloß nicht anpassen.

Blockchain als Perspektive

Steven B. Johnson stellt in seinem aktuellen Artikel Beyond the Bitcoin Bubble im Magazin der New York Times Blockchain als Zukunftshoffnung für offene Protokolle dar.

Er beschreibt das Internet in zwei Phasen, die erste ist geprägt von offenen Protokollen und Peer-to-Peer-Verbindungen, die zweite charakterisiert er als Phase von Monopolisten, die alle Daten in ihre eigene Plattform einschließen und sie als Waren verstehen.

Blockchain bietet laut Johnson die Möglichkeit eine neue Phase einzuläuten, in der offene Standards und die Möglichkeit direkter Vernetzung wieder die Hoffnung auf gleichwertigeren Austausch beflügeln. Er lädt dazu ein Blockchain über Bitcoin hinaus zu beachten, und somit das inhärente Potential wahrzunehmen und zu nutzen:

Like the original internet itself, the blockchain is an idea with radical — almost communitarian — possibilities that at the same time has attracted some of the most frivolous and regressive appetites of capitalism. We spent our first years online in a world defined by open protocols and intellectual commons; we spent the second phase in a world increasingly dominated by closed architectures and proprietary databases. We have learned enough from this history to support the hypothesis that open works better than closed, at least where base-layer issues are concerned. But we don’t have an easy route back to the open-protocol era. Some messianic next-generation internet protocol is not likely to emerge out of Department of Defense research, the way the first-generation internet did nearly 50 years ago.

Yes, the blockchain may seem like the very worst of speculative capitalism right now, and yes, it is demonically challenging to understand. But the beautiful thing about open protocols is that they can be steered in surprising new directions by the people who discover and champion them in their infancy. Right now, the only real hope for a revival of the open-protocol ethos lies in the blockchain. Whether it eventually lives up to its egalitarian promise will in large part depend on the people who embrace the platform, who take up the baton, as Juan Benet puts it, from those early online pioneers. If you think the internet is not working in its current incarnation, you can’t change the system through think-pieces and F.C.C. regulations alone. You need new code.

Steven B. Johnson, Beyond the Bitcoin Bubble. New York Times, 16.01.2018.

WordPress Toolbar und vollflächiger Hintergrund

Die WordPress Toolbar ist Segen und Fluch zugleich. Einerseits stellt sie wichtige Funktionen im Frontend zur Verfügung, andererseits bringt sie einigen Ballast mit sich. Zu eben erwähntem Ballast zähle ich die Inline-Styles über die sie sich ihren Raum auf der Seite freihält. Dieser Raum wird über einen margin-top freigehalten, der mir jedoch dann in die Quere kommt, wenn ich einen vollflächigen Hintergrund einsetzen möchte.

Um sowohl die WordPress Toolbar nutzen zu können und mein Layout konsistent zu halten, gehe ich folgendermaßen vor:

Zunächst füge ich in der header.php meines Themes eine ifelse-Kontrollstruktur hinzu. Dafür setze ich zuerst eine Variable mit der ich später dem html-Element eine entsprechende Klasse zuweise. Daraufhin kontrolliere ich ob die WordPress Toolbar angezeigt wird, und weise der Variable einen entsprechenden Wert zu.

<?php
  $wpadminbarClass = '';

  if ( is_admin_bar_showing() ) {
    $wpadminbarClass .= 'wpadminbar';
  } else {
    $wpadminbarClass .= '';
  }
?>

<html dir="ltr" <?php language_attributes(); ?> class="no-js <?php echo $wpadminbarClass; ?>">

Mit dieser Klasse am html-Element habe ich ein Hilfsmittel zur Hand, um die Inline-Styles zu überschreiben. Dazu füge ich dem Stylesheet meines Themes die entsprechenden Zeilen der Inline-Styles hinzu und ersetze die vorgesehenen margin-top durch padding-top.

html.wpadminbar {
  margin-top: 0 !important;
  padding-top: 32px !important;
}

* html.wpadminbar body {
  margin-top: 32px !important;
  padding-top: 0 !important;
}

@media screen and ( max-width: 782px ) {
	html.wpadminbar {
    margin-top: 0 !important;
    padding-top: 46px !important;
  }

	* html.wpadminbar body {
    margin-top: 0 !important;
    padding-top: 46px !important;
  }
}

Welche Möglichkeiten nutzt ihr um sowohl die WordPress Toolbar zu nutzen und Eure Layouts konsistent zu halten?

Spricht Eurer Meinung nach etwas dagegen in den Inline-Styles direkt padding-top statt margin-top zu verwenden?

Ist Dein Mac sicher?

Gestern Abend sah ich einen Tweet von @lemiorhan indem er eine Sicherheitslücke darstellte, über die jede Person sich Zugang zu einem Mac mit High Sierra verschaffen kann. Unter High Sierra ist der root-Benutzer standardmäßig ohne Passwort aktiviert. Da der root-Benutzer systemweit über alle Rechte verfügt, handelt es sich hierbei um eine äußerst kritische Sicherheitslücke.

Mit diesen sieben Schritten kannst Du dem root-Benutzer Deines Macs ein sicheres Passwort zuweisen:

Passwort für den root-Benutzer setzen

  1. Wählen das Menü „Apple“ () > „Systemeinstellungen“, und klicke anschließend auf „Benutzer & Gruppen“ (oder „Accounts“).
  2. Klicke auf das Schlosssymbol, und gib anschließend den Benutzernamen und das Passwort für einen Administratoraccount ein.
  3. Klicke auf „Anmeldeoptionen“.
  4. Klicke im unteren Bereich der Karte neben ›Netzwerkaccount-Server‹ auf „Verbinden“ (oder „Bearbeiten“).
  5. Klicke auf „Verzeichnisdienste öffnen“.
  6. Klicke im Fenster „Verzeichnisdienste“ auf das Schlosssymbol, und gib den Benutzernamen und das Passwort für einen Administratoraccount ein.
  7. Wähle in der Menüleiste der Verzeichnisdienste: „Bearbeiten“ > „root-Benutzer aktivieren“, und gib anschließend das Passwort ein, das Du für den root-Benutzer verwenden möchtest.

Rene Ritchie weist auf imore.com darauf hin, dass der root-Benutzer nicht deaktiviert werden sollte, da dadurch die Sicherheitslücke wieder geöffnet wird.

Wer keine Berührungsängste mit dem Terminal hat, kann das Passwort für den root-Benutzer auch darüber setzen, das geht wesentlich schneller und einfacher:

  1. Terminal öffnen
  2. sudo passwd root eingeben
  3. Die erste Passwort-Abfrage bezieht sich auf den Account mit dem Du angemeldet bist, und dann gibst Du zwei Mal das neu zu setzende Passwort für den root-Benutzer ein

Danke an Sven für den Terminal-Hinweis.

Update 30.11.2017:
Apple hat in der Nacht ein Sicherheitsupdate zur Verfügung gestellt. Falls noch nicht geschehen, aktualisiere am Besten direkt Deinen Mac.

Deployment eines Themes für WordPress

Dieses Wochenende steht unter dem Motto der Vereinfachung von Prozessen. Während ich meine Arbeit schon lange mit Git versioniere, hatte ich für das Deployment bisher noch den umständlichen Weg über den direkten Upload der aktualisierten Dateien gewählt. Dieser Umstand störte mich schon eine Weile, und so war heute Abend die Zeit gekommen auch diesen Prozess zu vereinfachen. Gestern habe ich darüber geschrieben wie ich WordPress mit einer Eingabe im Terminal für die Installation vorbereite, heute soll es nun darum gehen, wie sich Änderungen am Theme ganz einfach mit einem git push in der Produktion anwenden lassen.

Voraussetzungen

  • Etwas Vertrautheit im Umgang mit git
  • Ein Hosting das SSH und git unterstützt

Was haben wir vor?

Für das Deployment des Codes legen wir ein zusätzliches Verzeichnis (Repository) auf dem Server an, auf dem die Seite betrieben wird für die die Änderungen bestimmt sind. Diesem Repository ordnen wir eine Funktion zu, die ausgeführt wird, sobald das Verzeichnis aktualisiert wurde. Nachdem wir diese Schritte durchgeführt haben, kann das Deployment durch ein einfaches git push live master ausgeführt werden.

In diesem Artikel gehe ich davon aus, dass du dein Projekt bereits mit git versionierst, und beschriebe daher nur die Aspekte, die für den Deploy notwendig sind.

Repository vorbereiten

Das Verzeichnis für die Repositories (kurz repos) legen wir im Home-Verzeichnis an. Das Home-Verzeichnis ist nicht das öffentliche Verzeichnis in dem sich die Seite befindet und die über den Browser erreicht wird. Diese Seite ist bei Uberspace gehostet, ich verwende für die Beispiele Pfade wie sie dort üblich sind, das musst du für deinen Hoster anpassen.

Als erstes Legen wir ein Verzeichnis mit dem Namen repos an und wechseln in dieses Verzeichnis:

mkdir repos && cd repos

In unserem eben angelegten Verzeichnis sollen die Repositories angelegt werden. Da Themes und Plugins am Besten in unterschiedlichen Repositories verwaltet werden, gibt uns dieses Vorgehen die Möglichkeit unterschiedliche Projekte direkt mit unserer Seite zu verbinden. Wir bereiten nun das Repository für unser Theme vor und wechseln direkt in das neue Verzeichnis. Da es sich hierbei um ein Bare-Repository handelt, bekommt es gemäß der Konvention die Endung *.git.

mkdir mein-theme.git && cd mein-theme.git

Nachdem die Verzeichnisstruktur korrekt angelegt ist, bereiten wir das Repository dafür vor Inhalte unserer lokalen Entwicklungsumgebung zu empfangen:

git --bare init

Das Repository auf dem Server ist nun vorbereitet und wartet darauf mit Inhalten gefüllt zu werden. Bevor wir die Funktion anlegen über die wir die Änderungen direkt nach Eintreffen auf dem Server in unsere WordPress-Installation übertragen, weise ich noch auf die RAM-Nutzung hin. Bei Uberspace kam es bei der Verwendung von git auf den Servern schon zu Problemen mit der RAM-Auslastung. Im Uberspace-Wiki werden ein paar einfache Einstellungen erwähnt, die ein gutes Zusammenspiel von Server und git gewährleisten.

Deployment Funktion anlegen

In der Shell befinden wir uns noch im eben angelegten Repository mein-thema.git, und in diesem Repository legen wir auch die Deployment-Funktion an. Um die Änderungen anzuwenden verwenden wir den servierseitigen Hook post-receive, der beginnt wenn der erste Prozess abgeschlossen ist und mit den erhaltenen Informationen einen anderen Dienst aktualisieren kann.

vi hooks/post-receive

Die Datei post-receive öffnet sich nun im visuellen Editor der Shell. Den Bearbeitungsmodus aktivierst du mit i, worauf sich die eigentliche Funktion einfügen lässt. Bitte achte darauf, dass du den Pfad zum Theme auf das du die Änderungen anwenden möchtest für deine Gegebenheiten anpasst:

#!/bin/sh
GIT_WORK_TREE=/var/www/virtual/user/wp-content/themes/mein-theme git checkout -f

Den Bearbeitungsmodus des visuellen Editors verlässt du mit esc, danach gibst du :wq ein um die Änderungen zu speichern und den Editor zu verlassen.

Die eben angelegte Funktion muss ausführbar sein, weshalb wir ihre Rechte entsprechend setzen:

chmod +x hooks/post-receive

Wir haben nun unser Repository auf dem Server angelegt und vorbereitet, die Funktion um die eingecheckten Änderungen auf die Produktion anzuwenden haben wir ebenfalls erstellt. Dem Deploy steht nichts mehr im Wege.

Remote hinzufügen

Im Terminal öffnen wir ein neues Tab und wechseln in das Verzeichnis unseres Themes. Dort sehen wir zunächst nach mit welchem entfernten Repository wir bereits verbunden sind:

git remote -v

Hier wird dir sehr wahrscheinlich dein Repository bei GitHub oder BitBucket ausgegeben. Unsere Entwicklungsumgebung verbinden wir nun noch mit dem Repository das wir eben auf unserem Server angelegt haben:

git remote add live ssh://user@server.net/home/user/repos/mein-theme.git/

Mit git remote -v kannst du nun noch schnell überprüfen ob deine Eingabe geklappt hat und dein live-Repository ebenfalls verbunden ist.

Deployment, oder Änderungen anwenden

Nun haben wir alles vorbereitet um Änderungen an unserem Theme in der Entwicklungsumgebung ganz einfach auf das Theme in der Produktion anzuwenden. Diesen Vorgang nennt man Deployment, und dieser besteht nun nicht mehr in der händischen Auswahl und Übertragung der geänderten Dateien, sondern wird durch einen einfachen git push angestossen:

git push live master

Fazit

Ich habe mich dazu entschieden das Deployment nicht über einen Dienst zu machen, da ich keine Lust hatte meine Zugangsdaten irgendwo einzutragen. Mit dieser Methode melde ich mich mit einem SSH-Schlüssel auf dem Server an. Die Verknüpfung meines Rechners und dem Server über den erwähnten SSH-Schlüssel war bereits angelegt, und ist – soweit ich das beurteilen kann – ziemlich sicher.

Die Möglichkeiten Änderungen an einem Theme genauso einfach in der Produktion anzuwenden und nicht mehr nach den geänderten Dateien suchen zu müssen und diese in das korrekte Verzeichnis auf dem Server zu kopieren gefiel mir so gut, dass ich direkt zwei Änderungen durchführte.

Verwendete Quellen:

WordPress herunterladen und installieren

Als ich kürzlich wieder einmal WordPress installieren musste, wollte ich nicht den gewohnten Weg – aktuelle Version über die Webseite herunterladen, entpacken, in den entsprechenden Ordner kopieren und schließlich installieren – gehen, sondern machte mich auf die Suche nach einer direkteren Möglichkeit.

WordPress herunterladen

Bevor ich die aktuelle Version von WordPress herunterlade, wechsle ich mit dem Terminal in den Ordner, in dem ich WordPress installieren möchte. Das funktioniert sowohl per SSH auf einem Server, als auch direkt auf dem Rechner. Im korrekten Ordner angekommen nutze ich curl um das Paket herunterzuladen:

curl -O https://de.wordpress.org/latest-de_DE.tar.gz

Nachdem der Ladevorgang abgeschlossen ist befindet sich das komprimierte Paket in meinem Ordner, und muss entpackt werden. Zum entpacken verwenden wir den Tape Archiver (kurz tar), dem wir die Optionen -xzf übergeben. -x legt fest, dass die Dateien aus einem Archiv extrahiert werden. Mit -f werden die Daten der ausgegebenen Datei gelesen, und -z dekomprimiert das gzip-Archiv. Da ich WordPress direkt im Zielordner, und nicht in einem Unterordner, installieren möchte, gebe ich noch die Option --strip-components=1 mit, was dazu führt, dass die erste Verzeichnisebene weggelassen wird:

tar -xzf latest-de_DE.tar.gz --strip-components=1

Nun befindet sich WordPress an der gewünschten Stelle und ist bereit installiert zu werden. Bevor ich dies jedoch mache, lösche ich noch das komprimierte Paket:

rm -f latest-de_DE.tar.gz

Der Zielordner enthält nun alle notwendigen Dateien um darüber WordPress zu installieren.

In einem Schritt

Im einleitenden Satz schrieb ich davon, dass ich nach einer direkten Möglichkeit suchte. Während ich die gefundene Möglichkeit hier aufschrieb führte ich selbstverständlich die einzelnen Schritte nochmals aus, und stieß dabei auf weitere Verbesserungen. Da es möglich ist einzelne Befehle im Terminal direkt nacheinander ausführen zu lassen (Piping), kann das oben beschriebene durch eine Eingabe erzielt werden:

curl https://de.wordpress.org/latest-de_DE.tar.gz | tar -xzf - --strip-components=1

WordPress installieren

Die Installation lässt sich ganz einfach im Browser abschließen. Dazu gebe ich die Adresse der zu installierenden Webseite ein, daraufhin fragt WordPress nach den Angaben zur Datenbank, nachdem diese übermittelt sind, kann ich einen Benutzer anlegen und die Installation abschließen.

Fazit

Meiner Ansicht nach liegt der Vorteil dieser Methode darin, dass alle erforderlichen Dateien per Terminal geladen werden und die Installation schließlich im Browser abgeschlossen wird, dadurch geht sie schneller und ich kann mich früher an das machen, was ich mit der Installation vor habe.

Verwendete Quellen

Prototyping mit CSS Grid Layout

CSS Grid Layout, Pug, auto-fill, dense, minmax()

Die Möglichkeiten Layouts im Browser darzustellen kommen mit CSS Grid Layout in eine neue Phase. CSS Grid Layout ermöglicht die schnelle Umsetzung von Layouts, und eignet sich auf Grund seiner Flexibilität besonders gut für die Erstellung von Prototypen. Schnelligkeit und Flexibilität sind vor Allem darin begründet, dass die Layout-Entscheidung über das Elternelement erfolgt und sich die Kindelemente nach diesen Vorgaben richten. Auf diese Weise lassen sich unterschiedliche Szenarien unmittelbar testen.

Durch die Unterstützung in allen aktuellen Browsern lässt sich CSS Grid Layout, im Sinne des progressive Enhancement, auch in der Produktion einsetzen, an dieser Stelle soll es aber nur um die Entwicklung von Prototypen gehen.

Der Prototyp soll folgende Anforderung erfüllen: Ein Raster von Kacheln, deren genaue Anzahl unbekannt ist. Jede vierte Kachel soll zwei Spalten breit sein, während die übrigen nur eine Spalte einnehmen.

Um diese Anforderung zu erfüllen bekommt das Elternelement folgende Anweisung:

.grid-parent {
  display: grid;
  grid-auto-flow: dense;
  grid-gap: $spacing;
  grid-template-columns: repeat(auto-fill, minmax($mintrack, 1fr));
}

Zunächst wird die Darstellung als Raster festgelegt. Da die Anzahl der Kacheln nicht bekannt ist, definiere ich über die Eigenschaft grid-template-columns ein Raster, das durchgängige Spalten hat, wofür auto-fill sorgt, und lege eine minimale und maximale Spaltenbreite fest. Die minimale Spaltenbreite lege ich in der Variable $mintrack fest, was mir auch die Möglichkeit gibt diesen Wert zu einem späteren Zeitpunkt in einer Media-Query zu verwenden. Die Eigenschaft grid-auto-flow legt fest wie die Kindelemente im Raster positioniert werden. Der Wert dense sorgt dafür, dass Lücken die durch größere Elemente entstehen gefüllt werden, was dazu führen kann, dass die Reihenfolge verändert wird.

Die Anzahl der Spalten die jede vierte Kachel einnehmen soll, lege ich direkt auf dem Kindelement fest:

.grid-child:nth-of-type(4n) {
  grid-column: auto / span 2;
}

Um die Anzahl der Kacheln schnell modifizieren zu können, verwende ich die auf JavaScript basierende Template Engine Pug zur Erzeugung des Markups. Mit dem folgenden Code wird das Elternelement mit 17 Kindelementen erzeugt. Die Kindelemente haben einen Titel der die Position des Elements beinhaltet und einen kurzen Text.

section.grid-parent
  while n < 17
    .grid-child
      h1.title Tile #{n++}
      p.copy= copy

Zur Darstellung des Vorgehens habe ich in den Code hier nur in Auszügen wiedergegeben. Den vollständigen Code, die kompilierte Ansicht und die Möglichkeit den Code zu verändern, findest Du in diesem CodePen.

Im Bildschirmfoto ist das Raster zu sehen. Diese äußerst hilfreiche Funktion der Entwickler-Tools in Firefox nutze ich regelmäßig um das definierte Raster zu überprüfen.

Die Anregung zur Lösung der gestellten Anforderung stammt aus dem hervorragenden Buch The New CSS Layout von Rachel Andrew. Die, wie gestern bekannt gegeben wurde, die neue Chefredakteurin des Smashing Magazine ist.

Reaktionen sichtbar machen

Der Austausch über Blogartikel steht für mich schon immer im Mittelpunkt. In den Artikeln werden Ideen, Gedanken und Erfahrungen beschrieben, diese stehen jedoch nicht nur für sich selbst, sondern werden von den Reaktionen der Leserinnen und Leser ergänzt. Anfangs wurde engagiert kommentiert. Durch Twitter und Facebook fand schließlich der Austausch meist auf den entsprechenden Plattformen statt, und beschränkte sich in vielen Fällen auf den Ausdruck des Gefallens. Viele Kommentarspalten blieben leer, und die Artikel wirkten leblos. Die Reaktionen darauf war im Blog selbst nicht sichtbar. Social-Buttons mit ihren Tracking-Skripten stellten für mich keine Lösung dieses Problems dar. Den Austausch über die Inhalte verwandeln sie in Zahlen, die Qualität desselben bleibt jedoch weiterhin verborgen. Einen Mehrwert für das Blog und dessen Community stellen sie nicht dar, sondern dienen vor allem den Plattformen als Datenlieferanten.

Bereits vor einigen Jahren erfuhr ich von der IndieWeb-Bewegung, die vernetzte Inhalte sichtbar machen wollte, den Zugriff auf die eigenen Daten betonte und an vielen Stellen interessante Projekte hervorbrachte. In diesem Zusammenhang las ich bei Jeremy Keith über Webmentions.

Die Annahme über zu wenig Wissen und Zeit zu verfügen um mich selbst an die Implementation von Webmentions zu machen, führte dazu diesen Bereich ruhen zu lassen, und schließlich nichts dergleichen zu unternehmen. Erst als ich im Nachklang der Smashing Conference in Freiburg den Artikel »Implementing Webmentions« von Drew McLellan las, fasste ich den Entschluss die Reaktionen auf Inhalte in Blogs endlich wieder sichtbar zu machen.

Da ich gerade an ein paar Projekten arbeite die auf WordPress basieren und ich meine eigenen Blogs ebenfalls damit betreibe, widme ich mich an dieser Stelle der Implemantation von Webmention in mit WordPress betriebene und selbst gehostete Blogs.

Was ist zu tun?

Um Webmention mit WordPress zu benutzen sind vier Schritte nötig.

  1. Installation des Webmention-Plugins
  2. Installation des Plugins für Semantic-Linkbacks
  3. Social-Media-Profile via Bridgy mit dem Blog verbinden
  4. Das eigene Comment-Template anpassen

Das Webmention-Plugin

Das Webmention-Plugins von Matthias Pfefferle erweitert die Diskussion-Einstellung eines WordPress-Blogs, und legt die Grundlage dafür, dass ein Blog Webmentions senden und empfangen kann.

Nachdem das Plugin heruntergeladen, installiert und aktiviert ist stehen unter Einstellungen > Diskussion ein paar weitere Einstellungen zur Verfügung. Achte auch darauf, dass die allererste Einstellung »Versuche, jedes in Beiträgen verlinkte Weblog zu benachrichtigen« ausgewählt ist.

Unter Webmention Settings befinden sich vier Checkboxen und eine Auswahl mit deren Hilfe sich das Verhalten der Webmentions einstellen lassen.

Das Plugin für Semantic-Linkbacks

Das Plugin für Semantic-Linkbacks bietet die Möglichkeit die empfangenen Webmentions je nach Typ unterschiedlich zu behandeln. Es weist den empfangenen Erwähnungen einen entsprechenden Typ – beispielsweise Like, Repost oder Mention – zu, der als Filter und für die Styles zur Verfügung steht.

Eine Übersicht der Einstellungen bringt dieses Plugin nicht mit, es verrichtet seine Dienste sobald es aktiviert ist. Im IndieWeb-Wiki erfährst Du etwas über die Möglichkeiten die zugewiesenen Typen in Deinem Theme zu verwenden. Wie ich die Typen verwende beschreibe ich etwas später in diesem Artikel.

Update 15.10.2017:
Seit Version 3.5.0 unterstützt dieses Plugin die Darstellung von Likes, Mentions und Reposts in eigenen Listen. Dadurch wurde die Anpassung meines Comment-Template obsolet.

Brücken bauen

Der Dienst Bridgy baut die Brücken zwischen Deinen Social-Media-Profilen und Deinem Blog. Er überwacht die verbundenen Social-Media-Profile und sendet Erwähnungen ans Blog. Deine Social-Media-Profile müssen öffentlich sein und die URL Deines Blogs muss dort hinterlegt sein. Wichtig ist auch, dass die Post öffentlich sind, nur so können sie von Bridgy ausgelesen werden.

Auf brid.gy wählst Du also die Social-Media-Kanäle aus über die Du Erwähnungen empfangen möchtest. Sobald Du Bridgy den Zugriff auf Deine Profile gestattet hast, beginnt es damit alle 30 Minuten nachzusehen ob es dort eine Erwähnung Deines Blogs gibt. Wird es fündig sendet es die Erwähnung als Kommentar an Dein Blog.

Das Comments-Template

Um die Erwähnungen zu Bündeln habe ich mein Comments-Template und das Stylesheet etwas angepasst. Zur Anpassung meines Comment-Templates habe ich mich an diesem Code von Michael Bishop orientiert. Mein aktuelles Comments-Template kannst Du in diesem Gist ansehen.

Likes und Reposts sammle ich in einer Liste und verlinke lediglich die Profilbilder mit den jeweiligen Accounts. Danach gebe ich eine Liste der Kommentare aus – in dieser Liste erscheinen bei mir Antworten von Twitter, Kommentare von Facebook und die klassischen Kommentare. In einer Liste unter den Kommentare gebe ich Erwähnungen des Artikels in anderen Blogs aus.

Verbesserungen

Bei meinen ersten Schritten mit Webmention sehe ich Verbesserungspotential in den folgenden Punkten:

  • Links auf den Namen der Autor_inn_en korrigieren
  • Baumstruktur der Kommentare darstellen
  • Profilbilder optimieren und auf den eigenen Server speichern
  • Den Callback der manuellen Webmention-Eingabe optimieren

Ich freue mich von Euch zu hören wenn Ihr Ideen habt wie einer dieser Punkte gelöst werden kann, aber auch wenn Euch noch weitere Verbesserungen einfallen.

Benson Coffee

Den Kaffee von Benjamin Pozsgai wählte eine internationale Jury zum besten des Wettbewerbs und machte ihn zum Deutschen Röstmeister. Als solcher vertritt er Deutschland diesen Winter bei der Weltmeisterschaft in China.

Um auch bei der Weltmeisterschaft die Kaffees optimal zu rösten, bereitet er sich gerade gründlich vor. In den geplanten Trainingseinheiten wird er sorgfältig ausgewählte Kaffees rösten, und dabei auf die Besonderheiten der Bohnen achten um das Beste aus ihnen herauszuholen.

Benjamin Pozsgai hat ein Konzept erarbeitet, das vielen Kaffeeinteressierten die Möglichkeit gibt Teil der Vorbereitungen auf die Weltmeisterschaft zu werden: Das Benson Coffee Abo. Für das Abo wird nach jeder Trainingseinheit die beste Röstung ausgewählt und an die Abonnenten verschickt. Wer auf hochwertige Kaffees steht hat mit diesem Abo die Möglichkeit fünf ganz besondere Kaffees zu bekommen, und sollte sich diese Gelegenheit nicht entgehen lassen.

Bildschirmfoto der Webseite von Benson Coffee – Benjamin Pozsgai

Ich hatte die Möglichkeit für Benson Coffee meine Begeisterung für Kaffee und Webdesign zu verbinden. Auf diesem Weg entstand eine Webseite die über die Vorbereitungen zur Weltmeisterschaft informiert und über die das Kaffeabo bezogen werden kann.

Wer sich das Abo nochmals von Benjamin Pozsgai erklären lassen möchte kann das mit diesem Video tun:

Projektbeteiligung

Die Corporate Identity für Benson Coffee wurde von Marc Böttler entwickelt.

Meine Aufgabe bestand darin das Konzept der Webseite auszuarbeiten. Die Corporate Identity auf ein Interface Design zu übertragen und schließlich die Webseite mit integriertem Webshop und Blog umzusetzen.