Archiv des Autors: Heiko Mamerow

Über Heiko Mamerow

Buddhist, Vater, Freund, Internetseitenbauer, Sportler, Musikliebhaber & Verkehrsteilnehmer ;-)

Tutorial: WordPress Blog Seite im Masonry Layout erstellen

In diesem Tutorial zeige ich, wie die Blog Seite von WordPress im Masonry Layout erstellt werden kann.

Masonry Layout

Das Masonry Layout wurde im Webdesign maßgeblich durch Pinterest populär. Das charakteristische „mauerwerkartige“ Layout wird allgemein für das Stapeln von Content-Boxen verwendet. z.B. bei Bilder-Galerien wie hier bei Pinterest:

pinterest-masonry

Pinterest im typischen Masonry Layout

Masonry

Masonry ist der Name einer Grid-Layout Bibliothek in JavaScript. Sie sorgt dafür, dass Elemente der Website in einer bestimmten Ausrichtung zueinander positioniert werden. Damit lassen sich mauerwerkartige Grid-Layouts erzeugen, die mit purem CSS nicht bzw. nur annähernd erreicht werden können.

Anleitung

Die Anleitung erkläre ich am Beispiel von Twenty Sixteen. Bei Twenty Sixteen solltet Ihr die Umbauten natürlich nicht direkt im Theme erledigen, sondern ein Child-Theme anlegen.

masonry-1

Normale Twenty Sixteen Blog Seite ohne Masonry

Für die Umsetzung dieses Tutorial sind grundlegende Kenntnisse in HTML, CSS und last not least WordPress Themes nötig, weil die Anpassungen direkt im Theme vorgenommen werden.

Darüber hinaus ist es essentiell, sich mit der Masonry Bibliothek vertraut zu machen. Ich werde hier nur ein ganz einfaches Layout-Beispiel zeigen. Mit Masonry lassen sich viel kniffeligere Grid-Layouts umsetzen. Dazu ist aber das Wissen um die Optionen, Methoden usw. nötg.

Ich hatte zum Umbau eine normale WordPress-Installation benutzt. Die Einstellungen im WordPress waren im „Werkszustand“. Den Dummy-Content hatte ich mit FakerPress erzeugt. Weitere Plugins waren nicht im Einsatz.

Masonry einbinden

WordPress hat bereits Masonry im Gepäck. Es muss lediglich in der twentysixteen-child/functions.php eingebunden werden:

// Masonry Skript unter "home" aus dem Core laden.
if (is_home()) {
	wp_enqueue_script('masonry');
}

Damit wird zur Zeit die Version 3.2.2 von Masonry geladen. Diese Version ist allerdings veraltet. Für unsere Zecke macht das nichts aus. Es gilt lediglich einen kleinen Unterschied bei der Initialisierung der Bibliothek zwischen der alten Version 3 und der aktuellen Version 4 zu beachten: Ich benutze hier in der Anleitung den Code für die 3er Version. Die Version 4 ist mit der alten „3er-Schreibweise“ kompatibel.

Masonry Initialisieren

In der Masonry-Dokumentation sind drei Möglichkeiten beschrieben, wie sich die Bibliothek initialisieren lässt. Ich habe hier die HTML-Variante bevorzugt.

Nun wird im Theme Masonry initialisiert und der Container festgelegt, in dem das Masonry wirken soll. Damit das Theme sauber bleibt, hatte ich die bestehende twentysixteen/index.php als twentysixteen-child/home.php kopiert. Laut Theme-Konvention wird dann dieses Template benutzt, wenn die Blog-Seite angezeigt wird.

In der neuen home.php findet sich ein main-Element, welches sich gut als Masonry Container verwenden lässt. Der Container wird durch die CSS-Klasse .js-masonry initialisiert:

// Vorher:
<main id="main" class="site-main" role="main">

// Nachher:
<main id="main" class="site-main js-masonry" role="main">

Kind-Elemente des Containers festlegen

Innerhalb von .js-masonry können nun die Kind-Elemente festgelegt werden, welche im „Mauerwerk“ verwendet werden sollen. Dazu bekommt das Kind-Element die CSS-Klasse .grid-item zugewiesen.

Um das im Twenty Sixteen zu erreichen, bieten sich die <article> Tags an.

Vorher müssen wir die Datei twentysixteen/template-parts/content.php als twentysixteen-child/template-parts/content-home.php kopieren. In content-home.php wird dann folgendes eingetragen:

// Vorher:
<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>

// Nachher:
<article id="post-<?php the_ID(); ?>" <?php post_class( 'grid-item' ); ?>>

Nicht vergessen, damit das richtige Template-Teil geladen wird, muss in der home.php natürlich noch der Include angepasst werden:

// Vorher:
get_template_part( 'template-parts/content', get_post_format() );

// Nachher:
get_template_part( 'template-parts/content', 'home' );

Optionen

Auch für die Optionen stehen wieder drei Möglichkeiten zur Wahl. Ich bleibe beim HTML:

// Vorher:
<main id="main" class="site-main js-masonry" role="main">

// Nachher:
<main id="main" class="site-main js-masonry" role="main"
    data-masonry-options='{ "percentPosition": true }'>

Die einzige Option, die in diesem Beispiel zum Einsatz kommt, ist percentPosition. Wenn auf true gestellt, ermöglicht die Option, eine prozentuale Festlegung der Spaltenbreite. Damit lässt sich das Masonry-Layout für Responsive Layouts verwenden.

Sonstige Anpassungen im Theme

Die Breite der Spalten (bzw. der Kind-Elemente) wird durch CSS festgelegt. Dazu schreiben wir in die twentysixteen-child/style.css:

.grid-item {
    width: 33%; <!-- Dreispaltig -->
}

Jetzt ist die Blog Seite im dreispaltigen Masonry-Layout. Allerdings sieht sie noch nicht wirklich gut aus:

Masonry mit drei Spalten. Aber schön ist anders.

Masonry mit drei Spalten. Aber schön geht anders…

Das Layout lässt sich natürlich nach belieben anpassen und aufhübschen. Dann sieht es z.B. so aus:

Schon besser! :-)

Ein paar Handgriffe im CSS. Schon besser! :-)

Alles schön und gut, aber geht das nicht einfacher mit einem Plugin?

Selbstverständlich finden sich im Plugin-Repository etliche Masonry-Plugins. Ich habe im Rahmen der Recherche ein Plugin beispielhaft rausgepickt und ausprobiert. Mit dem Plugin ließ sich für mich in der Tat im Handumdrehen irgendein(!!!) Masonry-Layout erstellen.

Dennoch finde ich, sind Masonry-Layout Plugins keine wirkliche Alternative. Weil:

  1. Ohne mein genaues Hintergrundwissen über die Masonry-Bibliothek, die dem Layout ja zu Grunde liegt, ist die Konfiguration des Masonry-Layouts eine schwierige Herausforderung.
  2. Zudem ließen sich viele Features des Plugins (bzw. der Bbliothek) nicht nutzen, weil die Aktivierung der Pro-Version des Plugins vorbehalten war. Und selbst mit dem Pro-Version hätte ich nicht genau das Layout erhalten, was ich gewollt hätte. Dazu hätte ich in jedem Fall von Hand das Theme bearbeiten müssen.
  3. Frontend Design – in diesem Fall Masonry Layout – ist zu komplex, als dass es sich mit einem Plugin „erschlagen“ ließe. Es ist also nur eine gewisse Vereinheitlichung des Layouts und damit der Gestaltungsoptionen möglich.

WordCamp Berlin 2016?

Gestern traf ich mich mit Maja, Bernhard und Hans-Helge, um über ein mögliches WordCamp Berlin 2016 zu „brainstormen“.

wcber2016-orga
image-581907

Es wäre immerhin das vierte(!) WordCamp in Deutschland dieses Jahr. Wir wollen daher etwas besonders bieten und haben was ausgedacht… Bald gibt es mehr Infos. Ihr dürft gespannt sein. ;-)

Automattics AMP Plugin anpassen

Update (09.03.16 – 15:08 Uhr): Bei meiner Messung (siehe unten) hatte sich ein Server-Hiccup eingeschlichen. Ich habe die Messung wiederholt und dadurch hat sich die Auswertung etwas – aber nicht wesentlich – geändert. Danke an Bego für den Hinweis! :-))

Das ist ein kleines „How-To“ darüber, wie sich das Standardtemplate von Automattics AMP Plugin dem Design der eigenen Website anpassen lässt. Doch zunächst ein paar eigene Gedanken zu AMP im Allgemeinen. Wer sich nur für die reine Umsetzung in WordPress interessiert, überspringt den folgenden Abschnitt.

AMP – Sinn und Zweck

Accelerated Mobile Pages Project (AMP) ist ein Projekt von Google für schnellere Websites. Seit dem 24. Februar werden „geAMPte“ Websites in den Suchergebnissen von Google berücksichtigt.

amp-google

Quelle: Googleblog (https://googleblog.blogspot.de/2016/02/amping-up-in-mobile-search.html)

Im Grunde wird mit AMP nichts weiter getan, als die Seite auf das Wesentliche – den Content – zu entschlacken – vor allem überflüssiger Ballast aus Header, Footer und Sidebar wird weggelassen. Das ist keine Hexerei. Wer schon eine auf Performance optimierte Website hat, braucht AMP eigentlich nicht. Wer keine performante Website hat, sollte seine Energie besser erstmal auf eine grundlegende Optimierung verwerten.

AMP vs. native

Im Selbstversuch habe ich eine von meinen Seiten aus diesem Blog gemessen: einmal als normale Seite (native) wie gewohnt und einmal mit AMP:

AMPnative
Requests:938
Datenmenge:239KB284KB
Finish:5,92s646ms
DOM geladen:328ms641ms
Ladezeit:832ms693ms

Wie zu erwarten, ist die AMP-Version im DOM Aufbau deutlich schneller. Es wird dort schließlich viel weniger Content dargestellt.

Im Vergleich steht die AMP-Version auch bei der Anzahl der Requests viel besser da. Dabei gilt allerdings zu beachten, dass meine Seite über HTTP2 läuft und dafür optimiert ist. Das bedeutet, die Anzahl der Requests ist hier (relativ) egal. Ein Performancegewinn kann bei HTTP2 durch die Verringerung der Requests nicht erzielt werden. Das erkennt man gut daran, dass die Ladezeit (load) bei der native-Version trotzdem geringer ist. Die wenigen Requests bringen also überhaupt keinen Vorteil. Nur bei HTTP1.1 wäre das anders.

Besonders auffällig ist, dass die Datenmenge bei AMP – Obwohl weniger Content dargestellt wird! – deutlich höher ist als auf der native Version. Dort gibt es z.B. noch eine Sidebar. Es würde sich lohnen, den Code genauer zu inspizieren. (Das war nur ein Messfehler beim ersten Versuch.)

amp-vs-native
image-581846

Oben: Die Daten von der AMP-Version dieser Seite.
Unten: Die Daten von der normalen Version dieser Seite.
(Zum Vergrößern auf das Bild klicken oder tippen.)

Mit AMP wird die Seite also nicht unbedingt performanter, sondern unter Umständen sogar langsamer. Am Ende kann auch AMP nichts weiter machen, als sich an allgemein gültige Regeln für die Optimierung halten.

Bei mir läuft AMP bei den Beiträgen nur deshalb, damit ich es testen kann. Für mehr taugt es hier nicht.

Aber Moment, so einfach ist es nicht! Google führt mit AMP was ganz anderes im Schilde, als einfach nur Performanceoptimierung:

We also want to promote enhanced distribution so that publishers can take advantage of the open web’s potential for their content to appear everywhere quickly – across all platforms and apps – which can lead to more revenue via ads and subscriptions.
(Quelle: https://www.ampproject.org/….)

…Holzauge, sei wachsam! ;-)

AMP für WordPress

Wer die WordPress Website mit AMP aufwerten möchte, nimmt zum Beispiel das Plugin AMP von Automattic. Einmal installiert, sorgt es dafür, dass alle Beiträge (keine Seiten!) als AMP-Version vorliegen. Konfigurationsmöglichkeiten bietet das Plugin keine. Die AMP-Seite wird in einem Standard-Layout ausgeliefert. Das ist soweit ok. Doch wenigstens die Farben im Header und Links möchten sicher viele Ihrem eigenen Layout anpassen.

Auf der Github-Seite des Projektes ist sehr gut Dokumentiert, wie sich das Template anpassen lässt. Das lässt sich durch einige Zeilen Code in der functions.php erledigen. Wer nicht coden kann bzw. sich seine Konfiguration lieber zusammen klicken möchte, kann zum Beispiel mit diesem zusätzlichen Plugin grundlegende Anpassungen erledigen.

Ich bevorzuge die handgemachte Lösung in der functions.php. Damit sind viel individuellere Anpassungen möglich als mit einem Plugin.

AMP Template tweaken

Hier mal ein einfaches Beispiel, wie sich das Standard-Template anpassen lässt. ich habe bei mir die Farben für den Header und die Links an meinen Styleguide angepasst.

amp-css-change

Der Vorher-Nachher-Effekt: Links in Blau das Standard-Layout vom Plugin. und rechts eine kleine Anpassung der Farben.

Die Anpassungen lassen sich alle ganz praktisch im eigenen Theme erledigen. Öffne dazu die functions.php, trage folgenden Code ein und passe das CSS an Deine Werte an:

// AMP tweaking
function hm_amp_css_tweaks($amp_template) {
  ?>
  /* Headerfarbe ändern. */
  nav.amp-wp-title-bar {
    background: #b25e80;
  }
  /* Linkfarbe ändern. */
  a,
  a:visited {
    color: #b25e80;
  }
  a:hover,
  a:active,
  a:focus,
  .amp-wp-meta,
  .amp-wp-meta a {
    color: #73374f;
  }
  <?php
}
add_action('amp_post_template_css', 'hm_amp_css_tweaks');

Update: (10.03.2016 – 13:04 Uhr) Im obigen Code habe ich die Syntax der CSS-Kommtare berichtigt.

Mit diesem kleinen Snippet lässt sich schon das Wesentlichste im Layout anpassen. Wer will, kann natürlich noch viel mehr ändern. Bis hin zum Austausch des gesamten Templates ist alles möglich. Dank der sehr guten Doku von Automattic, erledigen sich die Anpassungen komfortabel.

Themes oder Plugins von einer externen Festplatte einbinden

Irgendwann ist selbst die größte Festplatte einmal voll. Glücklich darf sich schätzen, wer einen Computer besitzt, wo sich noch eine oder sogar mehrere weitere Platten einbauen lassen. Selbst wenn nicht, findet sich wenigstens noch ein USB-Anschluss für eine externe Festplatte.

Also einfach neue Festplatte rein und weiter geht es!
– Ja, schön wäre das…. ^^

Problem

Die Themes-Projekte, die ich nun auf meiner zweiten Festplatte ausgelagert hatte, wurden vom Multisite-WordPress – welches auf der ersten Festplatte installiert ist – nicht erkannt.

Mir ist bisher nicht klar, warum WordPress die Themes nicht erkennt. Wer mich da aufklären mag – nur zu! :-)

Grundsätzliches

Normalerweise entwickle ich ein Theme in einem speziellen Entwicklungsverzeichnis. Von dort binde ich es über einen Symlink in mein lokales WordPress ein. Das ist sehr praktisch, weil ich so eine saubere Trennung von Entwicklungs- und Testumgebung(en) habe. Und natürlich auch von der Liveumgebung beim Kunden.

Weiterer Vorteil: Wenn ich etwas in der Entwicklungsumgebung am Theme ändere, ist die Änderung sofort im „Test-WordPress“ verfügbar.

Übrigens meine Erklärung bezieht sich auf (Ubuntu-)Linux. Unter Mac-OS ist es ähnlich. Zu Windows kann ich nichts beitragen.

Einbinden mit Symlink

In der Entwicklungsumgebung bearbeite ich alle Dateien unter src. Die bearbeiteten Dateien landen dann im Verzeichnis build. Das build Verzeichnis beinhaltet das fertige Theme. Vom Theme-Verzeichnis meines lokalen „Entwicklungs-WordPress“ erzeuge ich eine symbolische Verknüpfung (Symlink) zu diesem build Verzeichnis.

mount-symlink1
image-581773

Im Terminal erzeugt man den Link nach folgendem Schema:

ln -s /Pfad-zum-Entwicklungsverzeichnis /Pfad-zu-WP-themes/theme-name

Einbinden mit mount

Auf die zweite Festplatte meines Rechners habe ich u.a. die Entwicklungsumgebung der Themes ausgelagert. Wenn ich versuche ein Theme wie gehabt mit Symlinks in WordPress auf der ersten Platte einzubinden, wird das Theme von WordPress nicht erkannt.

Statt der Symlinks habe ich – nach einigen Irrungen und Wirrungen – folgende Lösung gefunden:

mount-symlink2
image-581774

Die Themes von der zweiten Platte werden gemountet. Beim Mounten werden normalerweise ganze Datenträger und auch Netzwerke in das System eingebunden. Aber man kann damit auch einzelne Ordner von externen Datenträgern einbeziehen.

Anders als bei den Symlinks muss beim Mounten der Zielordner (theme-name) vorher angelegt werden. Das eigentliche Mounten erfolgt mit dem Befehl:

sudo mount --bind /Pfad-zum-Entwicklungsverzeichnis /Pfad-zu-WP-Themes/theme-name

In dem gemounteten (Theme-)Ordner liegen nun alle Ordner und Dateien bereit und werden auch anstandslos von WordPress erkannt.

Warning: Parameter 1 to [name of the plugin] Cache::[function name]()

After switching to PHP 7 you may find one or more warnings on your WordPress pages in this pattern:

Warning: Parameter 1 to [plugin name]::[function name]() expected to be a reference, value given in [absolute path to/wp-includes/functions.php on line [number]

Fixing is easy. Just go to your plugin and search/find the first [function name] – see above. This may lock like this:

function [function name](&$buffer) {

…now delete the „&“

function [function name]($buffer) {

Done :-)

PS: Of course this is only quick&dirty to make the website run. Don’t forget to inform the plugin author(s)!

 

HHVM vs. PHP7

Seit heute gibt es PHP7 und ich habe aus gegebenem Anlass einen Vergleich mit HHVM erstellt.

PHP 7

--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2015-12-03 23:57:40
Server : webwork@127.0.1.1
PHP version : 7.0.0RC8
Platform : Linux
--------------------------------------
test_ifelse : 0.260 sec.
test_loops : 0.301 sec.
test_stringmanipulation : 0.450 sec.
test_math : 0.285 sec.
--------------------------------------
Total time: : 1.296 sec.

PHP 5.5

--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2015-12-03 23:00:13
Server : vvv.dev@192.168.50.4
PHP version : 5.5.9-1ubuntu4.14
Platform : Linux
--------------------------------------
test_ifelse : 0.574 sec.
test_loops : 0.760 sec.
test_stringmanipulation : 1.258 sec.
test_math : 1.167 sec.
--------------------------------------
Total time: : 3.759 sec.

HHVM

--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2015-12-03 23:04:10
Server : heikomamerow.de@78.47.120.139
PHP version : 5.6.99-hhvm
Platform : Linux
--------------------------------------
test_ifelse : 0.033 sec.
test_loops : 0.067 sec.
test_stringmanipulation : 0.511 sec.
test_math : 0.297 sec.
--------------------------------------
Total time: : 0.908 sec.

Sieger ist hier eindeutig HHVM.

Natürlich ist dieser Test nicht ausschlaggebend. Man müsste unter realistischen Bedingungen z.B. im Einsatz mit WordPress testen. Mal sehen, ob/wann ich die Zeit und Muse dazu finde. ;-)

Zum Testen habe ich übrigens das PHP benchmark Script verwendet.

Vagrant up: The name of your virtual machine couldn’t be set

Bei der Installation von Varying Vagrant Vagrants (VVV) ist mir diesmal ein ungewöhnlicher Fehler passiert. Scheinbar so ungewöhnlich, dass ich diesmal bei der Recherche im Netz keine Lösung finden konnte. Aber immerhin habe ich es dann ausnahmsweise mal mit eigenem Nachdenken hinbekommen . ;-)

Vagrant Logo

By Fco.plj (Own work) [CC BY-SA 3.0], via Wikimedia Commons

Der Fehler

Die Installation (vagrant up) bricht irgendwann mit folgender Fehlermeldung ab:

The name of your virtual machine couldn't be set because VirtualBox
is reporting another VM with that name already exists. Most of the
time, this is because of an error with VirtualBox not cleaning up
properly. To fix this, verify that no VMs with that name do exist
(by opening the VirtualBox GUI). If they don't, then look at the
folder in the error message from VirtualBox below and remove it
if there isn't any information you need in there.

Das Problem

Ich hatte VVV als Unterverzeichnis vagrant-local in das VM-Verzeichnis von VirtualBox – /media/webwork/sec/VirtualBox VMs – geklont. Damit hatte „vagrant up“ Probleme, weil es genau in dieses Unterverzeichnis seine VM anlegen wollte, aber nicht konnte, weil das Verzeichnis schon vorhanden war. Darum brach VVV die Installation mit obiger Fehlermeldung ab.

Die Lösung

Die Lösung besteht darin, das „Clone-Verzeichnis“ außerhalb des VirtualBox-Verzeichnisses anzulegen. Bei mir z.B. /media/webwork/sec/vagrant-local Danach konnte ich die Installation wie gewohnt durchführen.

Nginx mit HTTP/2

Seit dem 22. September unterstützt nginx das neue Protokoll HTTP/2. Gleich am nächsten Tag habe ich zum Testen meinen Web-Server umgestellt. Hier ein kurzer Bericht:

Ich spare mir, die Vorzüge von HTTP/2 aufzuführen und zeige die wichtigsten Messergebnisse meiner Startseite im Vergleich:

http2-http1

HTTP/2 vs. HTTP/1 meiner Startseite im Vergleich

Wie erhofft, haben sich dank HTTP/2 die Ladezeiten verbessert. Sehr überrascht bin ich von der deutlichen Verminderung der CPU Busy Time. Darüber dürften sich auch die Hoster ganz besonders freuen.

Voraussetzungen für die Umstellung auf HTTP/2

1) Eigener Server

Ganz zuvorderst braucht man einen eigenen (v)Server mit Root-Rechten. Wer das nicht hat, muss so lange warten, bis sein Hoster endlich umgestellt hat.

Ich habe einen vServer mit Ubuntu 15.04 15.10.

2) SSL

SSL wird zwar nicht zwingend in der HTTP/2-Spezifikation vorgegeben, aber aktuelle Browser tun es.

3) OpenSSL

Nginx empfiehlt OpenSSL in der Version 1.0.2 für den vollen Funktionsumfang von HTTP/2. Auf dem aktuellen Ubuntu Server 15.04 ist leider nur OpenSSL 1.0.1f. Nginx schreibt aber, dass man vorübergehend mit der alten Version arbeiten kann. Bei mir läuft HTTP/2 auch mit OpenSSL 1.0.1f.

Die gute Nachricht: Im Upgrade 15.10 – welches am 22. Oktober 2015 raus kommt – ist OpenSSL 1.02d dabei. Am besten bis dahin „Füße still halten“. ;-)

4) Nginx 1.9.5 1.9.6 1.9.7

Erst die aktuelle Mainline-Version 1.9.5 1.9.6 1.9.7 unterstützt HTTP/2. Es ist also notwendig, den Server upzudaten, falls „nur“ die Stable-Version im Einsatz ist.

In meinem Fall war das aufwendig. Denn ich verwende das ngx_pagespeed Modul von Google. Darum musste ich meinen nginx selber kompilieren. Das habe ich nach der Anleitung von Google erledigt. Dazu musste allerdings einiges angepasst werden.

Hier meine angepasste Anleitung für nginx mit HTTP/2 und ngx_pagespeed:

sudo apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev unzip
cd
NPS_VERSION=1.9.32.10
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-${NPS_VERSION}-beta.zip
unzip release-${NPS_VERSION}-beta.zip
cd ngx_pagespeed-release-${NPS_VERSION}-beta/
wget https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz
tar -xzvf ${NPS_VERSION}.tar.gz

Update 27.10.15: Neueste NPS Version

cd
NGINX_VERSION=1.9.7
wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz
tar -xvzf nginx-${NGINX_VERSION}.tar.gz
cd nginx-${NGINX_VERSION}/
./configure --add-module=$HOME/ngx_pagespeed-release-${NPS_VERSION}-beta \
--prefix=/usr/local/share/nginx --conf-path=/etc/nginx/nginx.conf \
--with-http_ssl_module \
--with-http_v2_module \
--sbin-path=/usr/local/sbin --error-log-path=/var/log/nginx/error.log
make
sudo make install

Update 17.11.15: Neueste nginx Version

… in fünf Minuten erledigt. ;-D

HTTP/2 aktivieren

Wenn die Vorbereitungen erledigt sind, ist die eigentliche Aktivierung ein Kinderspiel:

  1. In config-Datei des virtuellen Hosts als Root in einem Editor öffnen.
  2. Die Direktive listen mit http2 erweitern:
    server {
        # https
        listen 443 ssl http2;
    ...usw...
  3. Nginx neu laden.

Testen

Zum Überprüfen, ob HTTP/2 läuft, kann man die folgende Erweiterung in seinem Chrome Browser aktivieren:

https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en

Wenn alles gut gegangen ist, sieht man in der Adressleiste von Chrome einen blauen Blitz.

http2-test

Blauer Blitz = Test bestanden

UPDATE – 29.09.15

Eben bin ich darauf aufmerksam gemacht worden, dass meine Seite bei diesem HTTP/2 Check nicht besteht: https://www.h2check.org/#heikomamerow.de

Jetzt wäre es gut zu wissen, wie der Test funktioniert und warum er nicht erfolgreich war… Ich bin gespannt und warte auf Antwort von h2check.

UPDATE – 05.11.15

Von h2check fehlt leider immer noch Rückmeldung. Aber dafür gibt es eine weitere HTTP/2 Check-Seite:  https://tools.keycdn.com/http2-test

Dort verläuft der Test meiner Seite positiv. 
(Danke an Bodo für den Tipp! :-))

 

Viel Spaß und Erfolg beim Umstellen!
:-)