ServiceWorker von Apple unterstützt

Webseiten werden ab jetzt auch auf Apple-Geräten zwischengespeichert, und stehen dann zur Verfügung wenn keine Verbindung zum Server hergestellt werden kann. Apple unterstützt ab iOS 11.3 und macOS 10.13.4 ServiceWorker!

Ab jetzt ist es auch im Apple-Umfeld möglich Progressive Web Apps (PWA) einzusetzen. Der Einsatz von PWA wird dadurch ermöglicht, dass zusätzlich zu ServiceWorker das Web App Manifest ab dieser Version von Safari (11.1) unterstützt wird.

Als Nutzer unterschiedlicher Apple-Geräte, und Angesichts deren Verbreitung, freue ich mich sehr darüber.

Beispiel eines ServiceWorker unter iOS 11.3

Wie ich auf meiner Seite ServiceWorker einsetze, habe ich in diesem ServiceWorker-Artikel vom 5. März beschrieben. Falls Du auf Deiner Seite ebenfalls von den Vorteilen – schnelleren Ladezeiten und offline-Verfügbarkeit – eines ServiceWorker profitieren möchtest, melde Dich gerne über das Kontaktformular oder per Mail bei mir.

Wenn ich es richtig sehe, fehlt nun noch die Implementierung in Edge, dann können wir, bezogen auf aktuelle Betriebssysteme und Browser, von einer guten Abdeckung ausgehen und plattformübergreifend PWA weitaus prominenter einsetzen.

Auf der Seite Is service worker ready? von Jake Archibald findest Du eine gute Übersicht zum aktuellen Stand der Implementierung von ServiceWorker in den unterschiedlichen Browsern.

Webseiten benutzbar machen

Laura Kalbag legt mit Accessibility for Everyone ein wunderbares Buch zu Barrierefreiheit vor, in dem sie sowohl grundlegende Überlegungen ausführt als auch konkrete Beispiele zur Verbesserung von Webseiten gibt.

In den sieben Kapiteln des kurzen Buches beleuchtet sie die Frage was Barrierefreiheit bedeutet. Welche konkreten Auswirkungen einige Beeinträchtigungen auf die Nutzung von Webseiten haben. Wie sich Barrierefreiheit im gesamten Entwicklungsprozess planen lässt. Darüber hinaus thematisiert sie den Zusammenhang von Inhalt und Design und die Verbindung von Barrierefreiheit und HTML. In den letzten beiden Kapiteln spricht sie über Tests und deren Auswertung und gibt einen kurzen Einblick in Gesetze und Richtlinien zur Barrierefreiheit.

In ihrem Buch folgt sie dem Konzept des Universal Design und spricht davon wie wichtig es ist davon auszugehen, dass Menschen auf unterschiedlichste Weise im Netz unterwegs sind. Der Zweite Schwerpunkt des Buches ist die Betonung auf den Beitrag aller Beteiligten am Entstehungsprozess einer Webseite zur Barrierefreiheit derselben.

»Making our sites accessible starts with the understanding that people access the web differently, and continues with every member of the team ensuring their output is inclusive«

Universal Design

Der Wikipedia-Artikel zu Universal Design beginnt mit dem Hinweis, dass es sich bei Universal Design um ein internationales Design-Konzept handelt, nach dem »Produkte, Geräte, Umgebungen und Systeme derart gestaltet« sind, »dass sie für so viele Menschen wie möglich ohne weitere Anpassung oder Spezialisierung nutzbar sind.«

Kalbach folgt in Ihrem Buch Ronald L. Mace, der Universal Design in der Architektur etabliert hat. Sie überträgt das Konzept auf Webseiten und formuliert es folgendermaßen:

»Web accessibility is the degree to which a website is usable by as many people as possible.«

Daraus folgt die Notwendigkeit Barrierefreiheit von Anfang zu bedenken, und nicht zu einem späteren Zeitpunkt im Entwicklungsprozess einer Webseite darauf zurück zu kommen. Wie bereits erwähnt ist es daher auch die Aufgabe von allen Beteiligten die Webseite auf eine Art zu designen, die von so vielen Menschen wie möglich ohne weitere Anpassung oder Spezialisierung nutzbar ist.

Aufmerksamkeit auf vier Aspekte helfen nach Kalbag dabei eine Webseite gemäß Universal Design zugänglich zu designen:

  • visuell: achte auf gute Sichtbarkeit.
  • auditiv: achte auf gute Hörbarkeit.
  • motorisch: achte auf die Bedienbarkeit der Interaktionen.
  • kognitiv: achte auf Verständlichkeit.

Bei der Ausführung dieser vier Aspekte wird deutlich wie eng Barrierefreiheit mit guter Bedienbarkeit zusammenhängen: »Good accessibility is good usability.« Eine Webseite, die dem Universal Design Konzept folgt, ist demnach für alle besser zu bedienen, und somit insgesamt ein besseres Produkt.

Konkrete Beispiele

Browser verwenden die vorhandene Struktur des HTML um die Inhalte entsprechend darzustellen und zugänglich zu machen. Webseiten deren HTML semantisch und gut strukturiert ist, sind demnach automatisch barrierearm und auf unterschiedliche Weise auslesbar. Kalbag empfiehlt daher die HTML-Spezifikation gut zu kennen, und die Elemente in ihrer vorgesehenen Funktion zu verwenden. Ein guter Seitenaufbau lässt sich einfach verbessern, während es beinahe unmöglich ist eine schlechte Struktur barrierefrei zu bekommen.

Im folgenden fasse ich ein paar ihrer konkreten Beispiele zusammen, die dazu beitragen im Entstehungsprozess einer Webseite darauf zu achten, dass am Ende ein barrierefreies Produkt steht.

Die Navigation bietet den User_innen Orientierung und hilft bei der Einschätzung welche Inhalte auf der Webseite angeboten werden. Daher sollte sie eine knappe Zusammenfassung der Inhalte darstellen um ihre Funktion gut zu erfüllen.

Links mit Texten wie ›weiter‹ und ›hier klicken‹ sind unbedingt zu vermeiden, da diese bei der Sprachausgabe keinen Zusammenhang zum Ziel des Links bieten. Das Ziel sind sprechende Links, die eine Verbindung zum verlinkten Inhalt herstellen, und bei der Erstellung dabei helfen den eigenen Schreibstil zu verbessern.

Alternative Attribute von Bildern, und Beschreibungen für Infografiken und Diagramme sind wichtig und sollen eine verständliche Erklärung des Dargestellten enthalten. Ihre Anregung beim Schreiben der alternativen Texte daran zu denken den Inhalt am Telefon oder in einer E-Mail zu erklären finde ich hilfreich:

»It might help to think about how you would explain the contents of the media to someone over the phone, or via email.«

Bezüglich der Strukturierung des Inhalts gab es mit dem Aufkommen von HTML5 eine Diskussion über die mehrfache Verwendung von Überschriften erster Ordnung (h1) in einem Dokument. Auch wenn das laut Spezifikation möglich ist, rät Kalbag diese nur für den Titel der Seite zu verwenden und damit die Hauptfunktion der Seite zu bezeichnen.

Für Formulare ist die Verknüpfung von label und input und erforderliche Felder mit einem entsprechenden Texthinweis im label zu versehen – und eben nicht mit dem zur Gewohnheit gewordenen Sternchen*. Dadurch bleibt die Benutzbarkeit offensichtlich und erfordert keine Vorerfahrung.

Um eine Webseite auch gut mit der Tastatur bedienen zu können helfen die tabindex Attribute. tabindex="0" weist die Tastatur-Navigation darauf hin das Element in der standardisierten Reihenfolge zu beachten. tabindex="-1" entfernt das Element aus der standardiesierten Reihenfolge. Daher ist die Verwendung von tabindex="-1" in Elementen die per Sprungmarken angesteuert werden hilfreich. Springt ein_e User_in zu einem Bereich mit tabindex="-1" wird diesem Bereich der programmatische Fokus zugewiesen, ein weiterer Tab findet dann zum entsprechend nächsten Element statt. Der Fokus bleibt nicht – wie ohne tabindex – an der ursprünglichen Stelle.

Im weiteren Verlauf des fünften Kapitels bespricht sie WAI-ARIA, was Web Accessibility Initiative—Accessible Rich Internet Applications bedeutet und als zusätzliche Ebene auf dem gut strukturierten HTML die Sprachausgabe der Inhalte unterstützt. Damit lassen sich Rollen, Bereiche, Status, Attribute und Live Regions definieren, die dann jeweils entsprechend besser zugänglich sind. Es bietet sich meiner Ansicht nach an über WAI-ARIA zu einem späteren Zeitpunkt nochmals zu schreiben.

Testen

Die aufmerksame Integration des Universal Design Konzepts in die Entwicklung einer Webseite sollte von regelmäßigen Tests begleitet werden.

»Regular testing will reassure you that you’re heading in the right direction, or give you new targets if the accessibility falls short.«

Neben den Tests durch eine breite Gruppe von User_innen empfiehlt sie das WebAIM’s WAVE web accessibility evaluation tool. Dabei handelt es sich um ein Webtool, mit dem die Barrierefreiheit einer Webseite überprüft werden kann. WAVE stellt die Webseite im Browser dar, und versieht sie an den entsprechenden Stellen mit Hinweisen auf Aspekte der Barrierefreiheit. Features, Warnungen und Fehler werden hervorgehoben, wodurch der testenden Person direkt weitere Einsichten bezüglich der Barrierefreiheit vermittelt werden.

Richtlinien

Im siebten Kapitel schriebt Kalbag über Gesetze und Richtlinien. Dabei erwähnt sie den Europäischer Rechtsakt zur Barrierefreiheit und die Web Content Accessibility Guidelines (WCAG) 2.0.

Die Web Content Accessibility Guidelines (WCAG) 2.0 enthalten drei Konformitätsstufen (A, AA und AAA), die darüber Aufschluss geben wie gründlich die Richtlinien umgesetzt werden. Die Richtlinien selbst sind durch vier Prinzipien strukturiert, welche mit den oben erwähnten Aspekten von Kalbag verwandt sind:

  • Prinzip 1: Wahrnehmbar – Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzern so präsentiert werden, dass diese sie wahrnehmen können.
  • Prinzip 2: Bedienbar – Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.
  • Prinzip 3: Verständlich – Informationen und Bedienung der Benutzerschnittstelle müssen verständlich sein.
  • Prinzip 4: Robust – Inhalte müssen robust genug sein, damit sie zuverlässig von einer großen Auswahl an Benutzeragenten einschließlich assistierender Techniken interpretiert werden können.

Zusammenfassung

Am Ende des siebten Kapitels fasst sie ihr Anliegen der Integration von Barrierefreiheit in den gesamten Entstehungsprozess einer Website in drei Haltungen zusammen:

  • Aufmerksam sein.
  • Flexibel bleiben.
  • Auf die Bedürfnisse der User_innen achten.

Wenn alle Beteiligten auf Barrierefreiheit achten und ihre Aufgaben aufmerksam erledigen, sind wir auf einem guten Weg. In Anbetracht der stetigen Veränderung und der jeweiligen Anforderungen ist es wichtig flexibel zu bleiben und unterschiedliche Schwerpunkte zu setzten und schließlich empfiehlt sie Richtlinien als solche zu verstehen, und die Bedürfnisse der User_innen zu beachten.

Bevor sie eine Fülle von Ressourcen und weiterführende Links anführt, schließt sie ihre Ausführungen mit dieser ansteckenden Vision:

»We need to work together to make and keep the web open, affordable, and available to all. Accessibility is our way to ensure that nobody gets shut out.«

Wie bereits deutlich wurde halte ich Accessibility for Everyone von Laura Kalbag für ein sehr gelungenes Buch und empfehle es gerne weiter. Kalbag gelingt es sehr gut die Auswirkungen von Universal Design deutlich zu machen, darüber hinaus kombiniert sie gekonnt grundsätzliche Überlegungen mit konkreten Beispielen.

Optimieren der Webfonts

Webfonts sind, wie alle anderen Schriften auch, für den Einsatz in unterschiedlichen Sprachen ausgelegt. Daher enthalten sie eine Fülle von Schriftzeichen. Wird ein Font in einer Webseite verwendet, die vor Allem einen Sprachraum bedient, werden viele dieser Schriftzeichen nie aufgerufen. Mit der Fülle der Schriftzeichen wächst die Dateigröße der Schrift, weshalb es sich lohnt zu überprüfen welche Schriftzeichen tatsächlich verwendet werden, und dementsprechend den Webfont anzupassen.

Dienste wie Typekit oder Google-Fonts bieten die Möglichkeit eine Teilmenge von verwendeten Schriftzeichen festzulegen, und auf diese Weise die Dateigröße des ausgelieferten Webfonts anzupassen. Sollen die Webfonts selbst gehostet werden, ist dies zwar über Font Squirrel möglich, allerdings muss dazu der Webfont hochgeladen werden.

Für mich erschien das bisher als eine nicht zufriedenstellende Lösung, weshalb ich in der letzten Woche die Artikel Three Techniques for Performant Custom Font Usage von Ollie Williams und It’s Dangerous to Go Stallone. Take Glyphhanger von Zach Leatherman mit großem Interesse gelesen habe. Am Wochenende installierte ich dann fonttools und glyphhanger um Webfonts gut über das Terminal optimieren zu können.

Das Tool glyphhanger der Filament Group verwendet die fonttools und bietet darüber hinaus noch die Möglichkeit Dateien oder URLs zu Parsen um dadurch herauszufinden welche Teilmenge an Schriftzeichen darin verwendet werden. Entsprechend dessen kann schließlich ein Webfont optimiert werden, und in unterschiedlichen Formaten abgespeichert werden.

glyphhanger https://depone.net/ --formats=woff2,woff --subset=SourceSansPro-Regular.ttf --css

Wird eben erwähnter Befehl ausgeführt wird der Webfont entsprechend der verwendeten Schriftzeichen in meiner Webseite optimiert. Die Dateigröße minimiert sich dadurch signifikant:

Subsetting SourceSansPro-Regular.ttf to SourceSansPro-Regular-subset.woff (was 287.07 KB, now 27.27 KB)
Subsetting SourceSansPro-Regular.ttf to SourceSansPro-Regular-subset.woff2 (was 287.07 KB, now 21.04 KB)

Mit Hilfe der Option --css gibt glyphhanger die Anweisung aus mit deren Hilfe der Webfont im Stylesheet verwendet werden kann. Um TOFU – hässlichen Kästchen die das fehlende Schriftzeichen ersetzen – in der Typographie zu verhindern wird die unterstützte unicode-range direkt mit angegebenen. Befinden sich im Text nicht unterstützte Schriftzeichen, greifen die Browser auf Systemschriften zurück.

@font-face {
 src: url(SourceSansPro-Regular-subset.woff2) format("woff2"), url(SourceSansPro-Regular-subset.woff) format("woff");
 unicode-range: U+A,U+20-5B,U+5D,U+5F,U+61-7E,U+A0,U+A9,U+AB,U+AD,U+B7,U+BB,U+C4,U+C7,U+D6,U+D7,U+DC,U+DF,U+E4,U+E9,U+F6,U+FC,U+2013,U+2014,U+2019,U+201C-201E,U+2026,U+2033,U+2039,U+203A,U+2192,U+21E7,U+2318,U+F8FF;
}

Der eben erwähnte Rückgriff auf Systemschriften verhindert zwar TOFU und stellt die Lesbarkeit des Textes sicher, die Typographie wird jedoch empfindlich gestört. Daher muss die Optimierung der Webfonts mit Bedacht vorgenommen werden. Die Übersicht der Unicode-Schriftzeichen in der Wikipedia hilft bei der Einschätzung der notwendigen Teilmenge.

Abschließend ist es auch noch wichtig zu erwähnen, dass die Ersparnis in der Dateigröße nicht 90%, wie oben zitierter Ausschnitt andeutet, da es sich beim Ausgangsfont um ein TrueType Format handelt, der entsprechende Webfont (woff) war dennoch dreimal so groß wie die optimierte Teilmenge.

Der Vollständigkeit halber ist noch zu erwähnen, dass für die Komprimierung der Webfonts als woff und woff2 die Installation von Brotli und Zopfli notwendig ist.

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