ubuntuusers.de

15. August 2017

Das Netzwerkdiagnose Tool netstat gehört zum Standardrepertoire vieler Administratoren. Die Netzwerkstatistiken sind aus den 90er Jahren und ermöglichen unter Linux eine Auflistung offener Ports oder TCP/UDP Verbindungen.

Da das Tool nur auf der Kommandozeile existiert wird es jedem Windows Nutzer wohl nicht unbedingt bekannt sein (eher TCPView), aber auch hier ist es integriert und kann ähnlich wie unter Linux verwendet werden.

Folgender beispielhafte netstat Befehl zeigt unter Linux die relativ nützliche Funktion des Tools.

netstat -lnp

Zur Erklärung: Das -l listet die Verbindungen auf, wobei -p PID bzw. den Programmnamen auflistet und -n eine nummerische Ausgabe der Ports forciert

PS: Unter Windows lässt sich eine ähnliche Ausgabe mit netstat -an erreichen.

netstatWeiter möchte ich auf netstat aus dem net-tools Paket nicht eingehen. Erstens gilt es als veraltet (aber beliebt) und zweitens dürften die Funktionen den meisten bekannt sein. Darum ein kurzer Blick auf die Alternative.


ss - socket statistics

Wie bereits oben erwähnt, ist netstat schon etwas älter. Mit den socket statistics existiert ein weiteres und neueres Tool, welches ähnliche Funktionen bietet.

Die Funktionsweise ist den netstats angelehnt, was am folgenden Beispiel zu erkennen ist.

ss -ln

Hier steht das -l für alle bestehenden Verbindungen, das -n listet Portnummern statt Namen auf.

Die Verwendung von -n beschleunigt zusätzlich die Ausgabe, da keine Hostnamen aufgelöst werden müssen.

Weitere praktische Befehle sind ebenfalls möglich:

ss -lt

Dieser Befehl listet bestehende tcp Verbindungen auf.

ss -lu

Dieses Kommando listet bestehende udp Verbindungen auf, mit -lua lassen sich alle Verbindungen anzeigen.

ss -p

Wie bei netstat werden hier die Prozess IDs (PID) gelistet.

ss -s

Abschließend bietet -s einen Überblick über alle Verbindungen (siehe Screenshot)

ss

Neben diesen eher alltäglichen Befehlen bietet ss viele weitere Möglichkeiten das Netzwerk zu untersuchen.

So besteht die Möglichkeit der Filterung nach Zieladresse (ss -nt dst 192.168.11.232) oder bestimmten Ports (ss -nt '( dst :443)') bestehenden IPv4 Verbindungen (ss -t4 state established) oder nur IPv6 (ss -tl6).

ss Befehlsübersicht

Einen Überblick aller Befehle verschafft ihr euch unter man ss oder via help (siehe Screenshot). 

ss-befehl

Sollten die Socket Statistics nicht auf dem System verfügbar sein, sollte das Paket iproute2 nach installiert werden.

Fazit

Alleine schon wegen des Alters von netstat und der nicht mehr vorhandenen Paketaktualisierung rückt Socket Statistics in den Vordergrund. 
Durch die Mehrzahl an Funktionen, sollten sich auch Nostalgiker langsam aber sicher auf das moderne Tool einstellen.

Manche Funktionen kann aber auch die neue Alternative nicht ersetzen, so muss für netstat -r auf iproute umgestiegen werden, da ss dies nicht mehr unterstützt.
 

14. August 2017

Am Wochenende stöbere ich immer wieder gerne in den Trending Repos auf Github rum, manchmal entdeckt man echte Perlen oder interessante Projekte.

Zu letzterem würde ich definitiv gtop zählen, einer top-Alternative auf Basis von NodeJS.

gtop

Lauffähig unter Linux und in der Regel auch macOS und Windows. Installiert sollte mindestens NodeJS 4, wobei man anmerken sollte, dass zum jetzigen Zeitpuntk sowieso Version 6 LTS-Release ist.

Die Installation ist schnell gemacht:

$ npm install gtop -g

Am Wochenende stöbere ich immer wieder gerne in den Trending Repos auf Github rum, manchmal entdeckt man echte Perlen oder interessante Projekte.

Zu letzterem würde ich definitiv gtop zählen, einer top-Alternative auf Basis von NodeJS.

gtop

Lauffähig unter Linux und in der Regel auch macOS und Windows. Installiert sollte mindestens NodeJS 4, wobei man anmerken sollte, dass zum jetzigen Zeitpuntk sowieso Version 6 LTS-Release ist.

Die Installation ist schnell gemacht:

$ npm install gtop -g

Am Wochenende stöbere ich immer wieder gerne in den Trending Repos auf Github rum, manchmal entdeckt man echte Perlen oder interessante Projekte.

Zu letzterem würde ich definitiv gtop zählen, einer top-Alternative auf Basis von NodeJS.

gtop

Lauffähig unter Linux und in der Regel auch macOS und Windows. Installiert sollte mindestens NodeJS 4, wobei man anmerken sollte, dass zum jetzigen Zeitpuntk sowieso Version 6 LTS-Release ist.

Die Installation ist schnell gemacht:

$ npm install gtop -g

Am Wochenende stöbere ich immer wieder gerne in den Trending Repos auf Github rum, manchmal entdeckt man echte Perlen oder interessante Projekte.

Zu letzterem würde ich definitiv gtop zählen, einer top-Alternative auf Basis von NodeJS.

gtop

Lauffähig unter Linux und in der Regel auch macOS und Windows. Installiert sollte mindestens NodeJS 4, wobei man anmerken sollte, dass zum jetzigen Zeitpuntk sowieso Version 6 LTS-Release ist.

Die Installation ist schnell gemacht:

$ npm install gtop -g

Am Wochenende stöbere ich immer wieder gerne in den Trending Repos auf Github rum, manchmal entdeckt man echte Perlen oder interessante Projekte.

Zu letzterem würde ich definitiv gtop zählen, einer top-Alternative auf Basis von NodeJS.

gtop

Lauffähig unter Linux und in der Regel auch macOS und Windows. Installiert sollte mindestens NodeJS 4, wobei man anmerken sollte, dass zum jetzigen Zeitpuntk sowieso Version 6 LTS-Release ist.

Die Installation ist schnell gemacht:

$ npm install gtop -g

WebDesignerinnen und WebDesigner aufgepasst: Endlich kann CSS, was CSS schon immer hätte können sollen! Mit CSS Grid kannst Du Deine Layouts aufbauen, ohne Umwege wie Tabellen, Frames oder die div-Monster heutzutage. Es gibt in letzter Zeit wenig Techniken, die mich sofort begeistern. CSS Grid ist eine davon.

Eigentlich sollte eine Webseite so funktionieren:

  1. Ich habe Inhalte.
  2. Das HTML gibt den Inhalten die Struktur. Es markiert, was die Überschrift ist, was ein Absatz ist, was die Navigation ist, was der Haupt-Inhalt der Seite ist und was Zusatzinformationen sind.
  3. Das CSS definiert, wie die HTML-Elemente aussehen und wie und wo sie angezeigt werden sollen.

Tabellen, Frames, divs…

Bisher mussten wir aber immer noch Krücken nutzen, um dem Browser klar zu machen, wo Inhalte angezeigt werden. Ganz früher hatten wir Tabellen und wir haben die Inhalte in die verschiedenen Zellen der Tabellen gesetzt. Dann haben wir die Seite in Frames aufgeteilt. Heute setzen nutzen wir exzessiv div-Tags, um sicher zu gehen, dass die Elemente richtig gruppiert sind und nebeneinander erscheinen.

divs haben aber überhaupt nichts mit der Struktur des HTML-Dokuments zu tun. Wir benötigen sie nur für die Darstellung. Mir war das schon immer suspekt und ich habe versucht so gut wie möglich die semantischen Tags zu nutzen. Dank HTML5 gibt es davon inzwischen eine ganze Menge.

Wer sich aber nicht komplett selbst damit herumschlagen wollte, ob das Webdesign in allen Browsern gut aussieht und funktioniert, hat dann doch auf Frameworks wie Bootstrap zurückgegriffen. Spätestens dann musste man wieder mit lauter divs arbeiten.

Jetzt kommt CSS Grid

CSS enthält inzwischen eine Lösung, die von allen Browsern, außer denen von Microsoft unterstützt wird: CSS Grid. Mit CSS Grid kann man mit ein paar einfachen CSS Anweisungen ein beliebiges HTML-Objekt in Zeilen, Spalten und Zellen aufteilen. Im CSS – nicht im HTML, wie früher mit den Tabellen-Layouts. Den Zellen kann ich dann im CSS Namen geben und per CSS den HTML-Elementen sagen, in welchen Zellen sie erscheinen sollen. Das ist sooo viel einfacher als sich dieser Schwachsinn mit divs und floats.

CSS Grid in der Praxis

Ich hab mir mein neues Theme für kaffeeringe.de mit CSS Grid gebaut. Zugegeben: Es ist ohnehin ein schlichtes Design und ein Blog hat nur Blog-Artikel. Das ist noch nicht die Meisterklasse. Trotzdem habe ich einen Vorgeschmack bekommen, wie super CSS Grid funktioniert.

Der Vortrag von Morten Rand-Hendriksen auf dem WordCamp Paris hat mich dazu inspiriert und ich musste das einfach ausprobieren!

YouTube Video

Morten Rand-Hendriksen schlägt vor, mit einem kleinen, mobilen Layout zu starten und dann die verschiedenen größeren Layouts nach und nach hinzuzufügen. So habe ich das dann gemacht. Es gibt die kleine, mobile Version und eine für Bildschirme mit mehr als 980 Pixeln Breite. Für all das war viel weniger CSS nötig. Das fängt natürlich schon einmal damit an, dass ich kein Bootstrap einbinden musste. 60 Zeilen für ein Reset-CSS, das die Browser-Styles zurücksetzt, 250 Zeilen für das mobile Basis-Layout und 130 Zeilen CSS für das große Layout.

Ein kleiner Cheat

Okay. Ich habe dann doch noch ein kleines CSS-Framework eingebunden – für das Kommentar-Formular. Denn einen Vorteil haben Frameworks wie Bootstrap: Man muss sich auch über das Aussehen von ganz vielen Elementen keine Gedanken mehr machen. Und Formulare zu designen, macht mit keinen Spaß. Das Framework „Formanizr“ von André Firchow macht das ganz angenehm, wie ich finde.

Microsoft Edge und der Internet Explorer

Erfunden hat CSS Grid offenbar Microsoft, erzählt Morten Rand-Hendriksen. Microsoft nutzt das wohl in Windows für alles mögliche. Die anderen Browserhersteller haben sich dann aber auf einen anderen Standard geeinigt, so dass Microsoft jetzt mit seinen Browsern mal wieder hinterher hinkt. Morten Rand-Hendriksen empfiehlt, den Microsoft-Browser einfach die mobile Seite auszuliefern.

So habe ich das jetzt auch gemacht. Im CSS teste ich, ob der Browser kann, was alle Browser können – außer denen von Microsoft. Edge und Internat Explorer bekommen die mobile Seite in einer festen Breite angezeigt. Dadurch fehlt die rechte Spalte. Da stehen aber auch nur Zusatzinfos. Die Artikel funktionieren auch so.

Das coole an dieser Lösung: Sollte Microsoft seine Browser irgendwann nachrüsten, bekommen die dann automatisch das richtige Layout ausgeliefert. Dann muss niemand mehr diese CSS-Frameworks nutzen, nur um Layouts so umzusetzen, wie es schon immer hätte sein sollen: Mit einer konsequenten Trennung von Inhalt, Struktur und Layout.

Links

Endlich bekommt CSS vernünftige Layout-Möglichkeiten

13. August 2017

Dachzeilen machen es wesentlich einfacher, verständliche, kurze Überschriften zu formulieren. Ein kurzes Stichwort gibt den Rahmen für die eigentliche Überschrift. Obwohl das sehr einfach ist, sind Dachzeilen in den meisten mir bekannten Redaktionssystemen nicht vorgesehen. Für WordPress habe ich mir das jetzt nachgerüstet.

Bislang habe ich für die Dachzeilen hier auf kaffeeringe.de immer einfach die „Eigenen Felder“ genutzt. Ich habe eines „Subtitle“ genannt und das dann im Template aufgerufen. Dafür aber, dass ich inzwischen hunderte Artikel mit Dachzeilen versehen habe, war das aber immer ein Provisorium.

Das herbstliche Urlaubswetter im Urlaub hat mir die Zeit gegeben, dieses Provisorium mal permanent zu machen: Ich habe das Eingabefeld für die Dachzeile fest in das Formular für neue Beiträge eingebaut, an der richtige Stelle: Über der Überschrift. So kann ich jetzt gleich sehen, ob Dachzeile und Überschrift zusammen funktionieren.

Ich weiß, dass es dafür auch Plugins gibt. Ich bin bei meiner Lösung mit ein paar Zeilen Code ausgekommen. Dafür muss ich mir kein Plugin installieren.

1. function.php

In der function.php meines Themes habe ich zwei Funktionen eingefügt. Die erste Funktion zeigt das zusätzliche Formfeld über der Überschrift an. Die zweite Funktion speichert die Eingabe und aktualisiert das „Eigene Feld“. Der Inhalt wird also so gespeichert, dass es auch noch funktioniert, wenn ich mal das Theme wechsel. Ich könnte dann wieder einfach das Formular für die „Eigenen Felder“ nutzen.

1
2
3
4
5
6
7
8
9
10
11
12
// Subtitles
function kaffeeringe17_addSubtitleToForm($post_ID) {
$customfields = get_post_custom_values('subtitle', $post_id);
echo '<label class="screen-reader-text" id="subtitle-prompt-text" for="subtitle">Dachzeile</label>';
echo '<input type="text" placeholder="Dachzeile" name="subtitle" spellcheck="true" size="30" value="'. esc_attr( $customfields[0] ) .'" id="subtitle" autocomplete="off" />';
}
add_action( 'edit_form_top', 'kaffeeringe17_addSubtitleToForm', $post_ID);

function kaffeeringe17_updateSubtitle($post_ID){
update_post_meta($post_ID, 'subtitle', trim($_POST['subtitle']));
}
add_action('save_post', 'kaffeeringe17_updateSubtitle', $post_ID);

2. Templates

Im Header setze ich dann Dachzeile und Überschrift zusammen, damit der Seitentitel richtig ist:

1
2
$subtitle = get_post_meta($post-&gt;ID, 'subtitle', true);
<!--?php $title = wp_title('',false); if ($title &amp;&amp; is_single()) { $subtitle = get_post_meta($post-&gt;ID, 'subtitle', true);&lt;br ?--> if ($subtitle) { echo $subtitle. ": "; } echo($title); } else { echo($title); } ?&gt;

In den Templates für die index.php, die single.php und die page.php sieht es so aus, dass ich Dachzeile und Überschrift in das gleiche h2-Tag oder h3-Tag setze, die Dachzeile per span absetze und den Doppelpunkt dazwischen ausblende.

1
2
3
4
5
$subtitle = get_post_meta($post-&gt;ID, 'subtitle', true);
<h2><a title="Link auf &lt;?php the_title_attribute(); ?&gt;" href="&lt;?php the_permalink(); ?&gt;" rel="bookmark">
<!--?php if ($subtitle) {?--><span class="subtitle"> <!--?php echo $subtitle; ?--> <span class="hide">:</span></span> <!--?php } ?-->
<!--?php the_title(); ?-->
</a></h2>

3. CSS

Ohne Formatierung steht dann da: „Dachzeile: Überschrift“. Das CSS macht das dann schön:

1
2
3
4
5
6
7
.subtitle {
display: block;
font-size: .7em;
}
.hide {
display:none;
}

4. Yoast SEO

Ich benutzte Yoast SEO, um meine Seite ein wenig besser verdaubar für Suchmaschinen und Social Networks zu machen. Dort kann ich einstellen, was der Seitentitel sein soll. Es ist auch möglich, die Dachzeile auszugeben. Deswegen haben ich eingetragen als Titel bei Beiträgen:

1
%%cf_subtitle%%: %%title%%

Das Ergebnis siehst Du im Titel Deines Browser-Tabs gerade.

4. RSS-Feed

Schön wäre es natürlich, wenn der Titel jetzt auch samt Dachzeile im RSS-Feed angezeigt würde. Sonst sind die Überschriften dort schwierig zu verstehen. Eine einfache Funktion rüstet das in der functions.php nach:

1
2
3
4
5
6
7
8
9
10
11
function kaffeeringe17_addSubtitleToRSSTitle($content) {
global $wp_query;
$postid = $wp_query->post->ID;
$subtitle = get_post_meta($postid, 'subtitle', true);

if($subtitle !== '') {
$content = $subtitle.': '.$content;
}
return $content;
}
add_filter('the_title_rss', 'kaffeeringe17_addSubtitleToRSSTitle');

Ich hoffe, diese Lösung gefällt Dir. Wenn ja – sag es weiter:

So baust Du Dachzeilen in WordPress ein

12. August 2017

Wie vielleicht dem ein oder anderen hier aufgefallen ist, nutze ich hier als Blog-System kein Wordpress sondern Ghost. ​ Ghost verfolge ich seit ihrer Kickstarter-Kampagne, vor kurzem haben die Jungs und Mädels Ghost 1.0 veröffentlicht - mittlerweile sind sie bereits bei 1.5 - was ich als Anlass genommen habe, mal wieder einen neuen Blog zu starten. ​ Ghost läuft anders Wordpress allerdings nicht mit PHP sondern mit NodeJS. Dieses lauscht auf einem eigenen Port, welchen man mittels Webserver auf die Standard-Webserver-Ports mappen kann. Bei mir gab es allerdings das Phänomen, dass Ghost in eine Weiterleitungs-Schleife fiel, als ich SSL in der config aktivierte. ​ Problem war, dass meine nginx-Konfiguration nicht vollständig war. Ghost-CLI kann nginx zwar konfigurieren, ich habe allerdings als Grundlage noch eine veraltete Konfiguration genommen. Richtig sieht es so aus: ​

server {
   listen 443 ssl http2;
   
   [...]
​
location / {
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header   X-Real-IP $remote_addr;
   proxy_set_header   Host      $http_host;
   proxy_pass         http://127.0.0.1:2369;
   }
}

​ Je nachdem, ob man weitere Ghost-Blogs oder NodeJS-Projekte am laufen hat, kann sich der Port natürlich unterscheiden.

Wie vielleicht dem ein oder anderen hier aufgefallen ist, nutze ich hier als Blog-System kein Wordpress sondern Ghost.

Ghost verfolge ich seit ihrer Kickstarter-Kampagne, vor kurzem haben die Jungs und Mädels Ghost 1.0 veröffentlicht - mittlerweile sind sie bereits bei 1.5 - was ich als Anlass genommen habe, mal wieder einen neuen Blog zu starten.

Ghost läuft anders Wordpress allerdings nicht mit PHP sondern mit NodeJS. Dieses lauscht auf einem eigenen Port, welchen man mittels Webserver auf die Standard-Webserver-Ports mappen kann. Bei mir gab es allerdings das Phänomen, dass Ghost in eine Weiterleitungs-Schleife fiel, als ich SSL in der config aktivierte.

Problem war, dass meine nginx-Konfiguration nicht vollständig war. Ghost-CLI kann nginx zwar konfigurieren, ich habe allerdings als Grundlage noch eine veraltete Konfiguration genommen. Richtig sieht es so aus:

server {
   listen 443 ssl http2;
   
   [...]

location / {
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header   X-Real-IP $remote_addr;
   proxy_set_header   Host      $http_host;
   proxy_pass         http://127.0.0.1:2369;
   }
}

Je nachdem, ob man weitere Ghost-Blogs oder NodeJS-Projekte am laufen hat, kann sich der Port natürlich unterscheiden.

Wie vielleicht dem ein oder anderen hier aufgefallen ist, nutze ich hier als Blog-System kein Wordpress sondern Ghost.

Ghost verfolge ich seit ihrer Kickstarter-Kampagne, vor kurzem haben die Jungs und Mädels Ghost 1.0 veröffentlicht - mittlerweile sind sie bereits bei 1.5 - was ich als Anlass genommen habe, mal wieder einen neuen Blog zu starten.

Ghost läuft anders Wordpress allerdings nicht mit PHP sondern mit NodeJS. Dieses lauscht auf einem eigenen Port, welchen man mittels Webserver auf die Standard-Webserver-Ports mappen kann. Bei mir gab es allerdings das Phänomen, dass Ghost in eine Weiterleitungs-Schleife fiel, als ich SSL in der config aktivierte.

Problem war, dass meine nginx-Konfiguration nicht vollständig war. Ghost-CLI kann nginx zwar konfigurieren, ich habe allerdings als Grundlage noch eine veraltete Konfiguration genommen. Richtig sieht es so aus:

server {
   listen 443 ssl http2;
   
   [...]

location / {
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header   X-Real-IP $remote_addr;
   proxy_set_header   Host      $http_host;
   proxy_pass         http://127.0.0.1:2369;
   }
}

Je nachdem, ob man weitere Ghost-Blogs oder NodeJS-Projekte am laufen hat, kann sich der Port natürlich unterscheiden.

Wie vielleicht dem ein oder anderen hier aufgefallen ist, nutze ich hier als Blog-System kein Wordpress sondern Ghost.

Ghost verfolge ich seit ihrer Kickstarter-Kampagne, vor kurzem haben die Jungs und Mädels Ghost 1.0 veröffentlicht - mittlerweile sind sie bereits bei 1.5 - was ich als Anlass genommen habe, mal wieder einen neuen Blog zu starten.

Ghost läuft anders Wordpress allerdings nicht mit PHP sondern mit NodeJS. Dieses lauscht auf einem eigenen Port, welchen man mittels Webserver auf die Standard-Webserver-Ports mappen kann. Bei mir gab es allerdings das Phänomen, dass Ghost in eine Weiterleitungs-Schleife fiel, als ich SSL in der config aktivierte.

Problem war, dass meine nginx-Konfiguration nicht vollständig war. Ghost-CLI kann nginx zwar konfigurieren, ich habe allerdings als Grundlage noch eine veraltete Konfiguration genommen. Richtig sieht es so aus:

server {
   listen 443 ssl http2;
   
   [...]

location / {
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header   X-Real-IP $remote_addr;
   proxy_set_header   Host      $http_host;
   proxy_pass         http://127.0.0.1:2369;
   }
}

Je nachdem, ob man weitere Ghost-Blogs oder NodeJS-Projekte am laufen hat, kann sich der Port natürlich unterscheiden.

Wie vielleicht dem ein oder anderen hier aufgefallen ist, nutze ich hier als Blog-System kein Wordpress sondern Ghost.

Ghost verfolge ich seit ihrer Kickstarter-Kampagne, vor kurzem haben die Jungs und Mädels Ghost 1.0 veröffentlicht - mittlerweile sind sie bereits bei 1.5 - was ich als Anlass genommen habe, mal wieder einen neuen Blog zu starten.

Ghost läuft anders Wordpress allerdings nicht mit PHP sondern mit NodeJS. Dieses lauscht auf einem eigenen Port, welchen man mittels Webserver auf die Standard-Webserver-Ports mappen kann. Bei mir gab es allerdings das Phänomen, dass Ghost in eine Weiterleitungs-Schleife fiel, als ich SSL in der config aktivierte.

Problem war, dass meine nginx-Konfiguration nicht vollständig war. Ghost-CLI kann nginx zwar konfigurieren, ich habe allerdings als Grundlage noch eine veraltete Konfiguration genommen. Richtig sieht es so aus:

server {
   listen 443 ssl http2;
   
   [...]

location / {
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header   X-Real-IP $remote_addr;
   proxy_set_header   Host      $http_host;
   proxy_pass         http://127.0.0.1:2369;
   }
}

Je nachdem, ob man weitere Ghost-Blogs oder NodeJS-Projekte am laufen hat, kann sich der Port natürlich unterscheiden.

New Tab Override ist eine Erweiterung zum Ersetzen der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Die beliebte Erweiterung mit mehr als 100.000 Nutzern ist nun als mit Firefox 57 und höher kompatible WebExtension erschienen.

Was ist New Tab Override?

Seit Firefox 41 ist es nicht länger möglich, die Seite anzupassen, welche beim Öffnen eines neuen Tabs erscheint, indem die Einstellung browser.newtab.url über about:config verändert wird. Da diese Einstellung – wie leider viele gute Dinge – in der Vergangenheit von Hijackern missbraucht worden ist, hatte sich Mozilla dazu entschieden, diese Einstellung aus dem Firefox-Core zu entfernen. Glücklicherweise hat Mozilla nicht einfach nur die Einstellung entfernt, sondern gleichzeitig auch eine neue API bereitgestellt, welche es Entwicklern von Add-ons erlaubt, diese Funktionalität in Form eines Add-ons zurück in Firefox zu bringen.

New Tab Override war das erste Add-on, welches diese Möglichkeit zurückgebracht hat, und ist damit das Original. Mittlerweile hat New Tab Override mehr als 100.000 Nutzer und wurde im Dezember 2016 sogar auf dem offiziellen Mozilla-Blog vorgestellt.

Download New Tab Override (WebExtension) für Firefox

New Tab Override 7.0 (WebExtension)

Kompatiblität mit Firefox 57 und höher

New Tab Override wurde von Grund auf neu als sogenannte WebExtension entwickelt. Damit ist New Tab Override auch mit Firefox 57 und neuer kompatibel. Nicht alle Optionen der Vorgänger-Version sind derzeit als WebExtension umsetzbar. Sobald Mozilla die Unterstützung für fehlende Funktionen in Firefox ergänzt, werden diese als Update von New Tab Override nachgereicht.

User Experience für bestehende Nutzer

Nutzer bisheriger Versionen von New Tab Override müssen die Erweiterung neu konfigurieren. Nach dem Update wird die Seite mit den Einstellungen automatisch geöffnet.

Für Nutzer bisheriger Versionen erscheint ein Hinweis, der auf die Notwendigkeit der Neu-Konfiguration sowie auf das Fehlen mancher Funktionen hinweist. Dieser Hinweis ist bei Neu-Installationen nicht sichtbar.

New Tab Override (WebExtension)

Verbessertes Design und neues Logo

Wie man bereits am vorherigen Screenshot sieht, wurde das Design überarbeitet, ohne aber an der grundsätzlichen Struktur viel zu verändern, so dass sich bisherige Nutzer schnell zurechtfinden werden. Die Änderungen schließen ein neues Farbschema und auch ein neues Logo ein. Der Dank dafür geht, wie schon bei meiner Erweiterung Boookmarks Organizer, nach Albanien an die Open Source-Freunde von Ura Design.

Das neue Logo mit seinem Flat-Design repräsentiert wunderbar die Modernisierung von New Tab Override. Durch die Bereitstellung des Logos als SVG-Grafik werden nicht länger verschiedene PNG-Grafiken innerhalb der Erweiterung benötigt, was als positiven Nebeneffekt neben einer verbesserten Wartbarkeit auch eine Reduzierung der Dateigröße von New Tab Override hat.

Die verschiedenen Optionen

Wie bisher können beliebige URLs als neuer Tab verwendet werden, oder eine der vordefinierten Optionen about:blank (komplett weiße Seite), about:home (Standard-Startseite) oder die neusten Nachrichten über Mozilla aus diesem Blog.

New Tab Override (WebExtension)

Auch ist es weiterhin möglich, den Fokus beim Öffnen eines neuen Tabs auf die Webseite (zum Beispiel das Google-Suchfeld) statt auf die Adressleiste zu legen. Beim Fokus auf die Adressleiste (Standard-Option) wird derzeit allerdings nicht automatisch die Adressleiste geleert. Dies erfordert eine Änderung seitens Mozilla und wird in zukünftigen Versionen von Firefox wieder möglich sein.

New Tab Override (WebExtension)

Auch die automatische Verwendung der Startseite als neuer Tab erfordert eine Änderung seitens Mozilla und wird in zukünftigen Versionen von Firefox wieder möglich sein. Die vordefinierte Option about:sync-tabs wurde entfernt, da Mozilla diese Seite aus Firefox 55 entfernt hat. Ob synchronisierte Tabs als neuer Tab in späteren Versionen von Firefox möglich sein werden, steht zu diesem Zeitpunkt noch nicht fest. Eine weitere Einschränkung ist, dass bei der Verwendung einer beliebigen URL die Verwendung des Protokolls http:// oder https:// erforderlich ist. Der Zugriff auf lokale Dateien wie file://-Protokoll ist aus Sicherheitsgründen nicht länger möglich. In diesem Fall muss die Datei auf einen Webserver hochgeladen werden, um weiterhin verwendet werden zu können. Die Option, die letzte URL aus der Zwischenablage zu verwenden, wurde in New Tab Override 7.0 nicht neu implementiert.

Live-Validierung von URLs

Ein neues Feature von New Tab Override 7.0 ist die Live-Validierung von URLs während der Eingabe in der Einstellungs-Oberfläche. So erhält der Nutzer ein direktes Feedback.

New Tab Override (WebExtension)

Beim Versuch auf lokale Dateien zuzugreifen, gibt es eine spezialisierte Fehlermeldung.

New Tab Override (WebExtension)

Berechtigungs-System

Eine der großartigen Neuerungen von Mozillas neuem Erweiterungs-Standard der WebExtensions ist das Berechtigungs-System. New Tab Override 7.0 macht davon in idealer Weise Gebrauch. Bei Installation wird nur die absolut notwendige Berechtigung vom Nutzer verlangt.

Für die Verwendung der Option, die neusten Nachrichten über Mozilla als neuer Tab anzuzeigen, wird eine zusätzliche Berechtigung benötigt.

New Tab Override (WebExtension)

Diese kann nachträglich werden und wird damit nicht von von der Mehrheit der Nutzer eingefordert, welche diese Option nicht nutzt. Wird die Berechtigung nicht gewährt, kann diese Option nicht genutzt werden. Der neue Tab zeigt dann einen entsprechenden Hinweis an.

New Tab Override (WebExtension)

Natürlich könnte New Tab Override diese Berechtigung für immer behalten, auch wenn der Nutzer hinterher wieder eine andere Option nutzen möchte. Um ein positives Beispiel für die Verwendung von Berechtigungen zu sein, gibt New Tab Override dem Nutzer zu jedem Zeitpunkt die Möglichkeit, die Berechtigung wieder zu entziehen.

New Tab Override (WebExtension)

Und so sieht die Nachrichten-Option bei erteilter Berechtigung aus:

New Tab Override (WebExtension)

Der Feed wird stündlich aktualisert.

Einstellungen per Tastatur öffnen

Wie bisher können die Einstellungen entweder durch das Symbol in der Navigations-Symbolleiste oder per Add-on Manager von Firefox geöffnet werden. In New Tab Override 7.0 sind zwei neue Möglichkeiten dazu gekommen: entweder per Tastatur-Kurzbefehl Shift + F12 oder per Eingabe von „newtab settings“ in die Adressleiste.

Sonstige Verbesserungen

Abgesehen von der Neuentwicklung als WebExtension wurden auch übernommene Komponenten überarbeitet und der Code modernisiert. Beispielsweise wurde die Nachrichten-Option intern von XMLHttpRequest auf die fetch()-API umgestellt, die Einhaltung moderner Praktiken und des Code-Stils wird via ESLint, stylelint, htmllint sowie JSDoc gewährleistet und der Code wurde sehr viel mehr kommentiert als in bisherigen Versionen.

Geplante Features

Es sind bereits ein paar neue Funktionen geplant. Da sich diese derzeit aber noch in der Evaluierungsphase befinden, gibt es diesbezüglich noch nichts Konkretes anzukündigen.

Entwicklung nun auf GitHub

Die Entwicklung wurde umgezogen und findet nun auf GitHub statt. Damit sind auch andere Entwickler und Übersetzer herzlich eingeladen, sich zu beteiligen, um New Tab Override noch besser zu machen. Das Melden von Fehlern und Vorschlagen von neuen Features erfolgt im Issues Tracker auf GitHub oder hier in den Kommentaren.

Der Beitrag New Tab Override 7.0 als WebExtension veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mailserver mit Dovecot, Postfix, MariaDB und Rspamd unter Debian

Vor wenigen Tagen hat Thomas Leistner sein wirklich gutes Mailserver-Setup für Ubuntu 16.04 neu aufgefrischt und für Debian 9 Stretch veröffentlicht.

Was ich besonders an den Anleitungen mag ist, dass es keine reine Copy & Paste-Anleitung ist, wie man sie wie so oft im Netz findet, sondern Thomas auch die einzelnen Punkte erläutert, was es auch für Einsteiger sehr einfach machen sollte.

2017-08-06 09:15:18 #13165(rspamd_proxy) <ffef9b>; proxy; lua_dkim_sign_handler: cannot load dkim key /var/lib/rspamd/arc/scharner.me.arc.key: cannot stat private key /var/lib/rspamd/arc/scharner.me.arc.key: No such file or directory

Ein einziger Punkt, der mir nicht funktionierte bzw. Probleme machte, war die ARC-Unterstüzung seitens rspamd. Dies lies sich allerdings lösen, in dem ich eine neue, leere arc.conf-Datei angelegt habe. Ist zwar nicht elegant, rspamd wirft keine Fehler mehr. Dennoch vielleicht mal ein Grund, sich mit ARC auseinander zu setzen.

Vor wenigen Tagen hat Thomas Leistner sein wirklich gutes Mailserver-Setup für Ubuntu 16.04 neu aufgefrischt und für Debian 9 Stretch veröffentlicht.

Was ich besonders an den Anleitungen mag ist, dass es keine reine Copy & Paste-Anleitung ist, wie man sie wie so oft im Netz findet, sondern Thomas auch die einzelnen Punkte erläutert, was es auch für Einsteiger sehr einfach machen sollte.

2017-08-06 09:15:18 #13165(rspamd_proxy) <ffef9b>; proxy; lua_dkim_sign_handler: cannot load dkim key /var/lib/rspamd/arc/scharner.me.arc.key: cannot stat private key /var/lib/rspamd/arc/scharner.me.arc.key: No such file or directory

Ein einziger Punkt, der mir nicht funktionierte bzw. Probleme machte, war die ARC-Unterstüzung seitens rspamd. Dies lies sich allerdings lösen, in dem ich eine neue, leere arc.conf-Datei angelegt habe. Ist zwar nicht elegant, rspamd wirft keine Fehler mehr. Dennoch vielleicht mal ein Grund, sich mit ARC auseinander zu setzen.

Mailserver mit Dovecot, Postfix, MariaDB und Rspamd unter Debian

Vor wenigen Tagen hat Thomas Leistner sein wirklich gutes Mailserver-Setup für Ubuntu 16.04 neu aufgefrischt und für Debian 9 Stretch veröffentlicht.

Was ich besonders an den Anleitungen mag ist, dass es keine reine Copy & Paste-Anleitung ist, wie man sie wie so oft im Netz findet, sondern Thomas auch die einzelnen Punkte erläutert, was es auch für Einsteiger sehr einfach machen sollte.

2017-08-06 09:15:18 #13165(rspamd_proxy) <ffef9b>; proxy; lua_dkim_sign_handler: cannot load dkim key /var/lib/rspamd/arc/scharner.me.arc.key: cannot stat private key /var/lib/rspamd/arc/scharner.me.arc.key: No such file or directory

Ein einziger Punkt, der mir nicht funktionierte bzw. Probleme machte, war die ARC-Unterstüzung seitens rspamd. Dies lies sich allerdings lösen, in dem ich eine neue, leere arc.conf-Datei angelegt habe. Ist zwar nicht elegant, rspamd wirft keine Fehler mehr. Dennoch vielleicht mal ein Grund, sich mit ARC auseinander zu setzen.

Mailserver mit Dovecot, Postfix, MariaDB und Rspamd unter Debian

Vor wenigen Tagen hat Thomas Leistner sein wirklich gutes Mailserver-Setup für Ubuntu 16.04 neu aufgefrischt und für Debian 9 Stretch veröffentlicht.

Was ich besonders an den Anleitungen mag ist, dass es keine reine Copy & Paste-Anleitung ist, wie man sie wie so oft im Netz findet, sondern Thomas auch die einzelnen Punkte erläutert, was es auch für Einsteiger sehr einfach machen sollte.

2017-08-06 09:15:18 #13165(rspamd_proxy) <ffef9b>; proxy; lua_dkim_sign_handler: cannot load dkim key /var/lib/rspamd/arc/scharner.me.arc.key: cannot stat private key /var/lib/rspamd/arc/scharner.me.arc.key: No such file or directory

Ein einziger Punkt, der mir nicht funktionierte bzw. Probleme machte, war die ARC-Unterstüzung seitens rspamd. Dies lies sich allerdings lösen, in dem ich eine neue, leere arc.conf-Datei angelegt habe. Ist zwar nicht elegant, rspamd wirft keine Fehler mehr. Dennoch vielleicht mal ein Grund, sich mit ARC auseinander zu setzen.

Mailserver mit Dovecot, Postfix, MariaDB und Rspamd unter Debian

Vor wenigen Tagen hat Thomas Leistner sein wirklich gutes Mailserver-Setup für Ubuntu 16.04 neu aufgefrischt und für Debian 9 Stretch veröffentlicht.

Was ich besonders an den Anleitungen mag ist, dass es keine reine Copy & Paste-Anleitung ist, wie man sie wie so oft im Netz findet, sondern Thomas auch die einzelnen Punkte erläutert, was es auch für Einsteiger sehr einfach machen sollte.

2017-08-06 09:15:18 #13165(rspamd_proxy) <ffef9b>; proxy; lua_dkim_sign_handler: cannot load dkim key /var/lib/rspamd/arc/scharner.me.arc.key: cannot stat private key /var/lib/rspamd/arc/scharner.me.arc.key: No such file or directory

Ein einziger Punkt, der mir nicht funktionierte bzw. Probleme machte, war die ARC-Unterstüzung seitens rspamd. Dies lies sich allerdings lösen, in dem ich eine neue, leere arc.conf-Datei angelegt habe. Ist zwar nicht elegant, rspamd wirft keine Fehler mehr. Dennoch vielleicht mal ein Grund, sich mit ARC auseinander zu setzen.

11. August 2017

Mozilla hat ein erstes Update für Firefox 55 veröffentlicht. Firefox 55.0.1 behebt ein paar Probleme der Versionsreihe 55.

Download Mozilla Firefox 55.0.1 für Microsoft Windows, Apple macOS und Linux

Mozilla hat nur drei Tage nach Veröffentlichung des sehr umfassenden Updates auf Firefox 55 ein erstes außerplanmäßiges Update verteilt. Dieses wird per automatischem Update nur für Nutzer von Firefox 55.0 verteilt. Nutzer von Firefox 54 und niedriger müssen noch etwas auf das Firefox 55-Update warten, während Mozilla ein weiteres Problem untersucht, welches seit Firefox 55.0 für manche Nutzer auftritt und dessen Ursache noch nicht geklärt ist.

Mit Firefox 55.0.1 hat Mozilla ein Problem in der Verschlüsselungsbibliothek NSS behoben, welches verursachte, dass Webseiten für manche Nutzer nicht mehr geladen werden konnten, und gleichzeitig auch Auslöser dafür war, dass Firefox beim Beenden hängen blieb. Außerdem wurde ein Problem bei der Wiederherstellung von Tabs behoben und die Einstellung network.predictor.enable-prefetch wieder von true auf false geschaltet. Schließlich wurde noch das Problem behoben, dass die Seite mit den Neuerungen nach einem Update nicht angezeigt wurde.

Der Beitrag Mozilla veröffentlicht Firefox 55.0.1 erschien zuerst auf soeren-hentzschel.at.

Zur Zeit beschäftige ich mich vermehrt mit Worpdress und Caching.

Bisher setzte ich als Caching-Plugin auf Cachify, ehemals entwickelt von Sergej Müller mit memcached als Backend, welches direkt vom nginx angesprochen wird - so wirklich glücklich, was die Geschwindigkeit angeht, war ich damit aber nicht.

Nach einiger Recherche bin ich nun auf WP-Rocket aufmerksam geworden, einem kostenplichtigen Caching-Plugin. Mein bisheriger Eindruck ist bisher sehr postiv, rein subjektiv gefühlt hat sich die Geschwindigkeit im Gegensatz zu Cachify deutlich verbessert - aber es gibt ja immer noch etwa mehr Optimierungsmöglichkeiten.

Nach weiterer Recherche bin ich dann auf Github auf das Projekt Rocket-Nginx gestoßen. Die Installation ist denkbar einfach. Getestet habe ich dies unter Debian 9 und CentOS 7. Angenommen wird, dass nginx unter /etc/nginx/ seine Konfiguration abgelegt hat:

cd /etc/nginx
git clone https://github.com/maximejobin/rocket-nginx.git
cd rocket-nginx
cp rocket-nginx.ini.disabled rocket-nginx.ini
php rocket-parser.php

Der Aufruft der PHP-Datei generiert eine default.conf, welche in alle eure vHosts eingefügt werden muss, die für eine Wordpress-Installatio mit WP-Rocket genutzt werden. Dies geschieht mit einem einfachen include:

include rocket-nginx/default.conf;

Dieses erweitert eine vorhandene nginx-Konfiguration für eine Wordpress-Installation um nützliche Erweiterungen wie z.B. HSTS und GZIP.

Was die Sache nun besonders hilfreich macht: Im Normalfall werden die von WP-Rocket generierten HTML-Seiten wie folgt ausgegeben:

NGINX → PHP-FPM → PHP → Static file

Durch Nutzung der weiteren Regeln für nginx verkürzt sich dieser Weg wie folgt:

NGINX → Static file

Nginx liefert also direkt die statischen Seiten aus ohne erst den Umweg über PHP gehen zu müssen.

Wordpress, nginx & wp-rocket

Zur Zeit beschäftige ich mich vermehrt mit Worpdress und Caching.

Bisher setzte ich als Caching-Plugin auf Cachify, ehemals entwickelt von Sergej Müller mit memcached als Backend, welches direkt vom nginx angesprochen wird - so wirklich glücklich, was die Geschwindigkeit angeht, war ich damit aber nicht.

Nach einiger Recherche bin ich nun auf WP-Rocket aufmerksam geworden, einem kostenplichtigen Caching-Plugin. Mein bisheriger Eindruck ist bisher sehr postiv, rein subjektiv gefühlt hat sich die Geschwindigkeit im Gegensatz zu Cachify deutlich verbessert - aber es gibt ja immer noch etwa mehr Optimierungsmöglichkeiten.

Nach weiterer Recherche bin ich dann auf Github auf das Projekt Rocket-Nginx gestoßen. Die Installation ist denkbar einfach. Getestet habe ich dies unter Debian 9 und CentOS 7. Angenommen wird, dass nginx unter /etc/nginx/ seine Konfiguration abgelegt hat:

cd /etc/nginx
git clone https://github.com/maximejobin/rocket-nginx.git
cd rocket-nginx
cp rocket-nginx.ini.disabled rocket-nginx.ini
php rocket-parser.php

Der Aufruft der PHP-Datei generiert eine default.conf, welche in alle eure vHosts eingefügt werden muss, die für eine Wordpress-Installatio mit WP-Rocket genutzt werden. Dies geschieht mit einem einfachen include:

include rocket-nginx/default.conf;

Dieses erweitert eine vorhandene nginx-Konfiguration für eine Wordpress-Installation um nützliche Erweiterungen wie z.B. HSTS und GZIP.

Was die Sache nun besonders hilfreich macht: Im Normalfall werden die von WP-Rocket generierten HTML-Seiten wie folgt ausgegeben:

NGINX → PHP-FPM → PHP → Static file

Durch Nutzung der weiteren Regeln für nginx verkürzt sich dieser Weg wie folgt:

NGINX → Static file

Nginx liefert also direkt die statischen Seiten aus ohne erst den Umweg über PHP gehen zu müssen.

Wordpress, nginx & wp-rocket

Zur Zeit beschäftige ich mich vermehrt mit Worpdress und Caching.

Bisher setzte ich als Caching-Plugin auf Cachify, ehemals entwickelt von Sergej Müller mit memcached als Backend, welches direkt vom nginx angesprochen wird - so wirklich glücklich, was die Geschwindigkeit angeht, war ich damit aber nicht.

Nach einiger Recherche bin ich nun auf WP-Rocket aufmerksam geworden, einem kostenplichtigen Caching-Plugin. Mein bisheriger Eindruck ist bisher sehr postiv, rein subjektiv gefühlt hat sich die Geschwindigkeit im Gegensatz zu Cachify deutlich verbessert - aber es gibt ja immer noch etwa mehr Optimierungsmöglichkeiten.

Nach weiterer Recherche bin ich dann auf Github auf das Projekt Rocket-Nginx gestoßen. Die Installation ist denkbar einfach. Getestet habe ich dies unter Debian 9 und CentOS 7. Angenommen wird, dass nginx unter /etc/nginx/ seine Konfiguration abgelegt hat:

cd /etc/nginx
git clone https://github.com/maximejobin/rocket-nginx.git
cd rocket-nginx
cp rocket-nginx.ini.disabled rocket-nginx.ini
php rocket-parser.php

Der Aufruft der PHP-Datei generiert eine default.conf, welche in alle eure vHosts eingefügt werden muss, die für eine Wordpress-Installatio mit WP-Rocket genutzt werden. Dies geschieht mit einem einfachen include:

include rocket-nginx/default.conf;

Dieses erweitert eine vorhandene nginx-Konfiguration für eine Wordpress-Installation um nützliche Erweiterungen wie z.B. HSTS und GZIP.

Was die Sache nun besonders hilfreich macht: Im Normalfall werden die von WP-Rocket generierten HTML-Seiten wie folgt ausgegeben:

NGINX → PHP-FPM → PHP → Static file

Durch Nutzung der weiteren Regeln für nginx verkürzt sich dieser Weg wie folgt:

NGINX → Static file

Nginx liefert also direkt die statischen Seiten aus ohne erst den Umweg über PHP gehen zu müssen.

Wordpress, nginx & wp-rocket

Zur Zeit beschäftige ich mich vermehrt mit Worpdress und Caching.

Bisher setzte ich als Caching-Plugin auf Cachify, ehemals entwickelt von Sergej Müller mit memcached als Backend, welches direkt vom nginx angesprochen wird - so wirklich glücklich, was die Geschwindigkeit angeht, war ich damit aber nicht.

Nach einiger Recherche bin ich nun auf WP-Rocket aufmerksam geworden, einem kostenplichtigen Caching-Plugin. Mein bisheriger Eindruck ist bisher sehr postiv, rein subjektiv gefühlt hat sich die Geschwindigkeit im Gegensatz zu Cachify deutlich verbessert - aber es gibt ja immer noch etwa mehr Optimierungsmöglichkeiten.

Nach weiterer Recherche bin ich dann auf Github auf das Projekt Rocket-Nginx gestoßen. Die Installation ist denkbar einfach. Getestet habe ich dies unter Debian 9 und CentOS 7. Angenommen wird, dass nginx unter /etc/nginx/ seine Konfiguration abgelegt hat:

cd /etc/nginx
git clone https://github.com/maximejobin/rocket-nginx.git
cd rocket-nginx
cp rocket-nginx.ini.disabled rocket-nginx.ini
php rocket-parser.php

Der Aufruft der PHP-Datei generiert eine default.conf, welche in alle eure vHosts eingefügt werden muss, die für eine Wordpress-Installatio mit WP-Rocket genutzt werden. Dies geschieht mit einem einfachen include:

include rocket-nginx/default.conf;

Dieses erweitert eine vorhandene nginx-Konfiguration für eine Wordpress-Installation um nützliche Erweiterungen wie z.B. HSTS und GZIP.

Was die Sache nun besonders hilfreich macht: Im Normalfall werden die von WP-Rocket generierten HTML-Seiten wie folgt ausgegeben:

NGINX → PHP-FPM → PHP → Static file

Durch Nutzung der weiteren Regeln für nginx verkürzt sich dieser Weg wie folgt:

NGINX → Static file

Nginx liefert also direkt die statischen Seiten aus ohne erst den Umweg über PHP gehen zu müssen.

Wordpress, nginx & wp-rocket

Zur Zeit beschäftige ich mich vermehrt mit Worpdress und Caching.

Bisher setzte ich als Caching-Plugin auf Cachify, ehemals entwickelt von Sergej Müller mit memcached als Backend, welches direkt vom nginx angesprochen wird - so wirklich glücklich, was die Geschwindigkeit angeht, war ich damit aber nicht.

Nach einiger Recherche bin ich nun auf WP-Rocket aufmerksam geworden, einem kostenplichtigen Caching-Plugin. Mein bisheriger Eindruck ist bisher sehr postiv, rein subjektiv gefühlt hat sich die Geschwindigkeit im Gegensatz zu Cachify deutlich verbessert - aber es gibt ja immer noch etwa mehr Optimierungsmöglichkeiten.

Nach weiterer Recherche bin ich dann auf Github auf das Projekt Rocket-Nginx gestoßen. Die Installation ist denkbar einfach. Getestet habe ich dies unter Debian 9 und CentOS 7. Angenommen wird, dass nginx unter /etc/nginx/ seine Konfiguration abgelegt hat:

cd /etc/nginx
git clone https://github.com/maximejobin/rocket-nginx.git
cd rocket-nginx
cp rocket-nginx.ini.disabled rocket-nginx.ini
php rocket-parser.php

Der Aufruft der PHP-Datei generiert eine default.conf, welche in alle eure vHosts eingefügt werden muss, die für eine Wordpress-Installatio mit WP-Rocket genutzt werden. Dies geschieht mit einem einfachen include:

include rocket-nginx/default.conf;

Dieses erweitert eine vorhandene nginx-Konfiguration für eine Wordpress-Installation um nützliche Erweiterungen wie z.B. HSTS und GZIP.

Was die Sache nun besonders hilfreich macht: Im Normalfall werden die von WP-Rocket generierten HTML-Seiten wie folgt ausgegeben:

NGINX → PHP-FPM → PHP → Static file

Durch Nutzung der weiteren Regeln für nginx verkürzt sich dieser Weg wie folgt:

NGINX → Static file

Nginx liefert also direkt die statischen Seiten aus ohne erst den Umweg über PHP gehen zu müssen.