Archiv des Autors: Heiko Mamerow

Über Heiko Mamerow

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

Datenkompression – Ein praktischer Leitfaden für den Einstieg

Am Donnerstag war mal wieder WP Meetup in Berlin und ich habe einen Vortrag über Datenkompression gehalten. Da ich kein Freund von Vortragspräsentationen im Internet bin, habe ich mich also nachträglich hingesetzt und alles als Blogbeitrag runter geschrieben.
Bitte sehr…. :-)

Datenkompression ist gut für Web Performance

Datenkompression ist eine Methode für Web Performance. Im Grund geht es bei der Datenkompression darum, die Dateigröße mithilfe von ziemlich cleveren Regeln (Algorithmen) zu verkleinern. Dabei werden z.B. wiederkehrende Zeichen (Muster) im Code zusammengefasst.

Das klingt schon mal ziemlich kompliziert. Ist es auch. Ohne intensives Informatik- bzw. Mathematikstudium geht da gar nichts. Aber die gute Nachricht: Datenkompression müssen wir nicht studieren, um sie erfolgreich benutzen zu können. Es reicht zu wissen, wie Datenkompression angewendet wird. ^^

Kleine Dateien

Mit der Datenkompression auf dem Webserver lassen sich Dateien um ca. 30 – 70% verkleinern. Dadurch können sie im Internet schneller übertragen werden. Das wiederum sorgt für schnellere Ladezeiten.

Ein kleines theoretisches Rechenbeispiel:

UnkomprimiertKomprimiert
Dateigröße:100 MB30 MB
Übertragungsrate:10 Mbit/s (DSL)
Dauer:80s24s

In diesem Beispiel benötigt eine unkomprimierte Datei, die 100 MB groß ist bei einer normalen DSL-Verbindung 80 Sekunden. Die gleiche Datei wäre komprimiert nur noch 30 MB groß und wäre dann schon in 24 Sekunden. Diese Datei wäre also ca. dreimal schneller am Ziel!

(Natürlich ist das obige Beispiel nur eine theoretische Berechnung. In der Praxis spielen noch viele andere Einflussfaktoren eine Rolle bei der Übertragungsgeschwindigkeit.)

Wie kommt Datenkompression zum Einsatz?

Jede Internetseite besteht aus mehreren Dateien. Das ist mindestens ein Dokument (z.B. index.html) und eine oder mehrere CSS-, Javascript- und Bild-Dateien und ein paar Web-font-Dateien und vielleicht noch vieles andere

Immer wenn jemand im Browser eine Internetseite anschauen möchte, werden diese Dateien von einem Webserver zum Browser übertragen. Als Faustregel lässt sich sagen: Je größer die Datei, desto länger dauert die Übertragung. Und je länger die Übertragung dauert. Desto länger müssen die Leute am Browser warten. Aber warten mag niemand. Um die Warterei auf die Internetseite zu verkürzen, können die Dateien komprimiert werden und werden dadurch schneller Übertragen. Aber wie?

Kompression beim Server und Dekompression beim Browser läuft automatisch.

Auf dem Webserver wird ein Kompressionsprogramm installiert. Das sorgt dann automatisch dafür, dass die Dateien bevor sie den Webserver verlassen, komprimiert werden. Wenn die komprimierten Dateien dann beim Browser ankommen, sorgt der – wiederum automatisch – dafür, dass die Dateien ausgepackt (dekomprimiert) werden und dann ganz normal für die Internetseite weiter verarbeitet werden.

Von all dem bekommen wir als normale Anwenderinnen und Anwender nichts mit. Wir laden wir gehabt unsere Daten auf den Server bzw. in ein Content-Management-System und der Server kümmert sich selbstständig. Prima, so einfach kann Web Performance sein! ;-)

Datenkompression mit gzip

Das Kompressionsprogramm der Wahl ist immer noch gzip. Das sorgt für die automatische Komprimierung auf dem Server. Es eignet sich für die Kompression aller Dateien, die Text enthalten. Das wären z.B. Dateien mit den Endungen; .html, .php, .css, .js, . svg, .woff2

gzip ist für alle gängigen Webserver erhältlich. Bei den beiden meist verwendeten Servern Apache und nginx ist gzip normalerweise bereits als Modul in der normalen Installation mit dabei. Es muss allerdings aktiviert werden, weil es in der Normaleinstellung deaktiviert ist.

Um die Installation müsst Ihr Euch also nicht kümmern – lediglich um die Aktivierung, falls gzip noch nicht läuft.

Woher weiß ich, ob meine Internetseite Daten komprimiert?

Erfahrene Entwicklerinnen und Entwickler wissen natürlich wie sie die Kompression mit Hilfe des Developer Tools im Browser auslesen können. Für alle anderen ist es aber auch nicht schwierig. Es gibt jede Menge Websites, wo sich ein „gzip Check“ durchführen lässt. z.B. bei www.gziptest.com

Einfach die URL eingeben und schon wird einem gezeigt, ob die Internetseite gzip unterstützt. Bei meiner Seite sah der Check so aus:

…alles richtig gemacht. :-)

Was tun, wenn gzip noch nicht aktiviert ist?

Falls der obige Test negativ verlaufen sein sollte, keine Panik. Das lässt sich richten. Zunächst lohnt sich erstmal ein Blick in die Accountverwaltung bei Eurem Provider oder eine Suche im Support oder der FAQ. Wenn dort nichts zu finden, am besten Anschreiben und Fragen, wie Ihr gzip auf dem Server aktivieren könnt.

Falls Eure WordPress-Seite auf einem Apache Server läuft, könnt Ihr gzip über ein Plugin aktivieren. z.B. mit dem Plugin Check and Enable GZIP compression

Falls Eure Website auf einem nginx Server läuft, müsst Ihr den Provider/Administrator bitten. Ein Plugin kann da nicht helfen.

Brotli – Ein neuer Stern am Himmel

Zum Abschluss möchte ich noch eine Alternative zu gzip ins Spiel bringen: Brotli

Brotli ist ebenfalls ein Kompressionsprogramm. Und zwar ein relativ neues. Es wurde von Google entwickelt und bietet neben einer noch stärkeren Kompression auch noch weitere Vorteile. Unter anderem, komprimiert Brotli viel schneller. Was positive Auswirkungen auf die Performance hat. Wer sich für Vergleichsmessungen von Brotli vs. gzip interessiert, kann sich das mal anschauen: https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html

Allerdings ist Brotli noch nicht wirklich relevant, denn es wird bisher noch nicht von allen Browsern (Dekompression) unterstützt und leider bieten die Provider meines Wissens nach bisher noch keinen Support dafür.

image-582026

Brotli Browser-Unterstützung. Stand 27.01.2017

Nichtsdesto wird Brotli in absehbarer Zeit gzip verdrängen und zum Standard werden. Dafür ist seine Performance einfach zu gut. Übrigens wird diese Website mit Brotli gepowert. ;-)

Unkomprimiert vs. gzip vs. Brotli

Last not least habe ich alle Möglichkeiten verglichen. Ich habe meine Startseite unkomprimiert, mit gzip und mit Brotli gemessen. Hier der Vergleich:

image-582027

Meine Startseite => unkomprimiert

image-582028

Meine Startseite => gzip

image-582029

Meine Startseite => Brotli

…Noch Fragen? ;-)

HTTP/2 Server Push – Die ersten Versuche

Soeben habe ich bei einem Kunden erfolgreich das HTTP/2 Server Push Feature aktiviert. Das Ergebnis kann sich schon mal sehen lassen:

image-582015

Die Zeiten sprechen für sich…

Die Aktivierung ist relativ simpel, WENN ein Server zur Hand ist, der Server Push unterstützt. Das ist leider mit nginx noch immer nicht der Fall. Und es steht in den Sternen, wann das je noch geschehen wird. Apache dagegen bietet Server Push schon standardmäßig mit dem HTTP/2 Modul an. Ergo denke ich immer lauter über einen Serverwechsel bei mir nach. Aber Apache ist nicht so meine Wahl… ;-)

 

RTL Schreibrichtung bei WordPress Themes mit PostCSS automatisch erstellen

Wer die Internationalisierung seines WordPress Themes ermöglichen möchte, wird sich auch über die Schreibrichtungen Gedanken machen. Insbesondere werden zwei CSS-Varianten benötigt. Einmal für LTR (links nach rechts) und einmal für RTL (rechts nach links). Zwei CSS-Varianten können den Aufwand für die Thementwicklung deutlich erhöhen. Im Beitrag möchte ich darauf eingehen, wie sich dieser Aufwand stark reduzieren lässt.

image-581993

Die selbe Website einmal LTR und einmal RTL.

RTL Methoden bei WordPress

Grundsätzlich gibt es zwei Schreibrichtungen in horizontaler Richtung:

  1. LTR (von links nach rechts)
    z.B. Deutsch, Englisch, Französisch, Spanisch
  2. RTL (von rechts nach links)
    z.B. Arabisch, Hebräisch and Persisch

Über LTR müssen wir uns keine Gedanken machen. Das ist von hause aus gegeben. Für die Unterstützung von RTL werden im Codex zwei Möglichkeiten vorgestellt:

a) Ersetzungsmethode

Bei dieser Methode wird der Link im Dokument auf die originale Stylesheet Datei entfernt und durch ein RTL-Pendant (style-rtl.css) ersetzt.

b) Ergänzungsmethode

Bei der zweiten Methode bleibt die originale Stylesheet Datei (z.B. style.css) erhalten. Dafür wird zusätzlich die Datei rtl.css ergänzt. In rtl.css sind nur die für RTL relevanten Anpassungen enthalten. Weil rtl.css nach style.css geladen wird, überschreiben deren angepasste Regeln die original Regeln.

Wann eignet sich welche Methode?

Im Prinzip ist es egal, ob die originale Stylesheet Datei ersetzt oder ergänzt wird. Beides führt zum selben Ergebnis.

Ich präferiere die Ersetzungsmethode, weil sie die Webperformance nicht beeinflusst.

Die Ergänzungsmethode dagegen hat negativen Einfluss auf die Performance der Website, weil

  1. Durch die zusätzliche Datei wird ein zusätzlicher Request ausgelöst.
  2. Das Überschreiben der originalen Regeln erzeugt zusätzlichen Aufwand für den Browser.

RTLCSS

Egal, welche Methode gewählt wird, sie erfordern beide einen Aufwand in Umsetzung und Organisation für den Stylesheet. Glücklicherweise unterliegen die nötigen Anpassungsarbeiten relativ einfachen Regeln, die sich sehr gut automatisieren lassen. Und überglücklicherweise haben schon fleißige Leute Tools entwickelt, mit denn sich die entsprechenden Styles erstellen lassen.

Das von mir verwendete Tool ist RTLCSS. Es ist ein Konvertierungsscript für RTL. Es lässt sich sowohl in Verbindung mit einem Automatisierungstool oder auch als Online-Tool nutzen.

RTLCSS als Online Tool

Die RTLCSS Online ist sehr einfach zu bedienen. Damit lassen sich die schnellsten Ergebnisse erzielen. Der konvertierte Code kann für die Ersetzungsmethode ohne Nacharbeit genutzt werden. Wenn der Code für die Ergänzungsmethode verwendet werden soll, sollten nachträglich – von Hand – die unnötigen Styles rausgefiltert werden, um unnötige Überschreibungen zu vermeiden.

RTLCSS Online
image-581994

Screenshot RTLCSS Online: links der original Code; rechts die RTL-Version

RTLCSS Online sei allen empfohlen, die bereits ein fertiges Theme haben und es für RTL nachrüsten wollen.

RTLCSS mit npm

Die Verwendung von RTLCSS Online im Prozess der Thementwicklung ist allerdings umständlich. Weil nach jeder Änderung im Originalcode das Tool manuell bedient werden muss.

RTLCSS lässt sich aber prima in Verbindung mit einem Buildtool/Taskrunner verwenden. Ich zeige das hier am Beispiel von npm.

Ja, richtig gelesen. Denn npm lässt sich prima als Buildtool „missbrauchen“. Die gleichen Aufgaben lassen sich natürlich auch mit den anderen Buildtools erledigen…

Setup für die Ersetzungsmethode

Grundlage für das Setup sind: Node.js, npm (Npm ist in Node.js enthalten.) und PostCSS. Das sollte schon vorher installiert sein.

Schritt 1. Das Plugin RTLCSS installieren:

npm i -g rtlcss

Schritt 2. Im Rootverzeichnis des Projektes (Also dort, wo das Theme entwickelt wird.) npm initiieren. – z.B. im Terminal im Rootverzeichnis des Theme Projektes eingeben:

npm init

Schritt 3. In die frisch erzeugte Datei package.json den Task anlegen.

Nach dem Init wird die package.json erzeugt. Diese Datei im Editor öffnen und dann bei script das Folgende ergänzen:

{
  "name": "beispiel",
  "version": "1.0.0",
  "description": "Nur ein Beispiel",
  "main": "index.php",
  "author": "Heiko Mamerow",
  "license": "GPL-3.0",
  "scripts": {
    "rtl": "postcss -c ./npm-scripts/rtl.json",
  }
}

rtl => Der Name des Tasks
postcss => Es wird PostCSS ausgeführt.
-c => öffnet eine PostCSS Konfigurationsdatei für diesen Task
./npm-scripts/rtl.json => relativer Pfad zu Konfigurationsdatei

Schritt 4. Natürlich muss die angegebene Konfigurationsdatei noch erstellt werden. Also im gewünschten Pfad die Datei rtl.json anlegen. (Pfad und Dateiname kann natürlich angepasst werden.)

Schritt 5. rtl.json im Editor öffnen und eingeben:

{
  "use": [
   "rtlcss"
  ],
  "input": "./css-src/main-src.css",
  "output": "./schnell/assets/css/rtl.css",
  "map": "file"
}

use => Array; Dort nennen wir das PostCSS Plugin, was in diesem Task zur Anwendung kommen soll. Also: rtlcss
input => Pfad zum original Stylesheet
output => Pfad zum RTL Stylesheet (Wenn die Datei noch nicht vorhanden ist, wird sie später vom Task angelegt.)
map => Angabe, ob eine CSS-Map angelegt werden soll. (Ist nicht notwendig, aber macht sich besser, falls es mal später was zu debuggen gibt.)

Das war es schon, jetzt kann der Task ausgeführt werden – z.B. im Terminal im Rootverzeichnis des Theme Projektes eingeben:

npm run rtl

Im Editor sieht das ganze dann so aus:

RTLCSS mit PosctCSS
image-581995

RTLCSS mit PosctCSS im Editor

Wer mag, kann den obigen rtl Task noch mit einer watch Option automatisieren. So dass jedesmal, wenn die original CSS Datei editiert wird, gleich das RTL-Pendant aktualisiert wird.

Setup für die Ergänzungsmethode

Hier ist das Setup fast identisch wie bei der Ergänzungsmethode oben. Einziger Unterschied: für den Task nehmen wir ein anderes PostCSS Plugin: PostCSS-WPRTL

Dieses Plugin konvertiert im ersten Schritt die Regeln wie oben mit RTLCSS und filtert dann zusätzlich in einem zweiten Schritt alle unnötigen – weil ja im original Code vorhanden Styles – raus. Dieser zweite Schritt erspart uns unnötigen Code Ballast!.

Schritt 1. Das Plugin installieren – z.B. im Terminal im Rootverzeichnis des Theme Projektes eingeben:

npm i -g postcss-wprtl

Schritt 2 -4. sind wie oben.

Schritt 5. rtl.json im Editor öffnen und eingeben:

{
  "use": [
   "postcss-wprtl"
  ],
  "input": "./css-src/main-src.css",
  "output": "./schnell/assets/css/rtl.css",
  "map": "file"
}

Die Konfiguration ist ebenfalls wie oben – lediglich bei use ändert sich der Pluginname.

Der Task wird dann ebenfalls wie oben aufgerufen. Das Ergebnis ist allerdings ein wenig anderes als oben:

image-581996

Etwas ist jetzt anders als oben. Finde den Unterschied! ;-)

Nachtrag

Die RTLisierung des CSS ist dank RTLCSS und den Buildtools nicht mehr so aufwendig und sollte zum guten Standard jedes Themes werden. Zum Testen von RTL Themes empfielt sich übrigens das Plugin: RTL Tester. Damit lässt sich das bestehende Theme für eingeloggte Admins prima testen.

 

 

Themes oder Plugins mit Symlink in Vagrant einbinden

Frage: Was ist der Unterschied zwischen guten und schlechten WordPress-Entwicklern?
Antwort: Es gibt keinen. Erstere aber verwenden Vagrant. :-)

Wer Themes oder Plugins entwickelt, möchte sie sicherlich auch in einer Testumgebung ausprobieren. Dann ist eine virtuelle Umgebung mit Vagrant die erste Wahl. Je nach Projekt erstelle ich mir meine Umgebung mit PuPHPet oder VVV.

Um eine saubere Trennung von Vagrant (Testumgebung) und der Entwicklungsumgebung (IDE) zu haben, sollte das Theme (oder Plugin) aus der IDE mittels eines Symlinks in die Testumgebung eingebunden werden. Damit ist das Theme auf der Testseite immer synchron mit der Entwicklung. Jedesmal, wenn am Theme in der IDE editiert wird, ist die Änderung auch gleich in der Testumgebung aktiv.

Einbindung

Leider sind Symlinks in Vagrant nicht ganz trivial einzubeziehen. Dazu muss die Einstellung des Vagrantfiles wie folgt erweitert werden:

Wenn nicht schon vorhanden, erstelle erstmal im Vagrant-Root-Verzeichnis (Dort wo die Datei Vagrantfile liegt.) die Datei: Customfile

Öffne die Datei Customfile mit einem Editor und trage dort die Angaben zum Symlink ein:

# Symlink zu meinem Theme: superduper
config.vm.synced_folder "../Pfad/zur/Entwicklungsumgebung/von/superduper", 
"/srv/www/wordpress-default/wp-content/themes/superduper", 
owner: 'www-data', 
group: 'www-data', 
mount_options: ["dmode=775", "fmode=664"]

Im obigen Snippet ist beispielhaft die Einbindung eines Themes in VVV beschrieben.

Besonderheit: Der erste Pfad (zur IDE) kann relativ oder absolut sein. Der zweite Pfad (in Vagrant) muss immer absolut sein.

Quellen

https://wordpress.stackexchange.com/a/189849
https://www.vagrantup.com/docs/synced-folders/basic_usage.html

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 Zwecke 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)!