Matomo-Berichte per Cronjob generieren

Matomo ist eine freie Software zur Webanalytik. Früher war Matomo unter dem Namen Piwik bekannt. Wenn Matomo Berichte auf der Weboberfläche anzeigt, so werden diese vorher generiert. Geschieht dies beim Aufruf der Berichte, kann dies, vor allem bei größeren Berichten, zu Problemen führen, da der Server entsprechend viel Zeit für die Erstellung benötigt und dies sich auf die Ladezeit der Weboberfläche auswirkt.

Die Archivierung bei der Anzeige im Browser sollte deaktiviert werden

Als Lösung bietet es sich an die Aufgabe, der Berichterzeugung und Datenaggregierung, an einen Cronjob auszulagern. Dazu muss im ersten Schritt die Crontab-Datei geöffnet werden:

sudo -u www-data crontab -e

Ich die sich öffnende Crontab-Datei wird nun folgende Zeile eingetragen:

*/15 *    * * *   php /var/www/example/matomo/console core:archive > /dev/null

Nachdem die Crontab-Datei gespeichert wurde, wird der Task zur Archivierung und Erstellung der Berichte alle 15 Minuten automatisch gestartet. In den Matomo-Einstellungen unter System -> Allgemeine Einstellungen findet sich der Punkt Archivierungseinstellungen. Hier muss die Archivierung im Browser deaktiviert werden. Damit werden Berichte in Matomo nun per Cronjob erzeugt und beeinflussen die Ladezeiten der Weboberfläche nicht mehr.

Cachify-Cache per Cronjob bereinigen

Cachify ist ein WordPress-Plugin zum einfachen und effektiven Cachen der eigenen WordPress-Instanz. Das Plugin bietet unterschiedliche Methoden für das Caching an. So kann der Cache z.B. in der Datenbank oder auf der Festplatte angelegt werden. Meine bevorzugte Methode ist die Ablage des Caches auf der Festplatte.

Cachify
Cachify
Preis: Kostenlos

Dies hat einige Vorteile. So kann der Cache, wenn vorhanden, direkt über den Webserver ausgeliefert werden. Die Ausführung von PHP oder die Anfrage auf der Datenbank entfällt. Dies wirkt sich extrem positiv auf die Geschwindigkeit aus. Allerdings funktioniert der automatische Ablauf des Caches bei der Festplatten-Methode leider nicht. Hier muss stattdessen ein Cronjob eingerichtet werden:

sudo -u www-data crontab -e

Im Cronjob soll einmal der Cache bereinigt werden und anschließend die Hauptseite geöffnet werden, damit für diese wieder ein Objekt im Cache angelegt wird:

rm -rf /var/www/example/main/wp-content/cache/cachify/*
curl --silent https://example.net > /dev/null

Beim ersten Befehl wird der Ordner, in welchem der Cache liegt, gelöscht. Anschließend wird mit cURL die Hauptseite aufgerufen, um den Cache wieder aufzufüllen. In der Crontab-Datei sieht dies wie folgt aus:

0    *    * * *   rm -rf /var/www/blankensee/main/wp-content/cache/cachify/* & curl --silent https://blankensee.net > /dev/null

Damit wird der Cache einmal in der Stunde gelöscht und der Cache der Hauptseite wieder neu aufgebaut.

gzip-Komprimierung unter Nginx aktivieren

Bei der Auslieferung einer Webseite, kann der Datenstrom mittels gzip komprimiert werden. Im Endeffekt kommt die Komprimierung der Performanz einer Webseite zu Gute, da weniger Daten ausgeliefert werden müssen. Um die gzip-Komprimierung unter Nginx zu aktivieren, muss die entsprechende Konfigurationsdatei bearbeitet werden:

nano /etc/nginx/nginx.conf

In dieser Konfigurationsdatei findet sich folgender Block:

gzip on;

#gzip_vary on;
#gzip_proxied any;
#gzip_comp_level 6;
#gzip_buffers 16 8k;
#gzip_http_version 1.1;
#gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Nachdem die auskommentierten Werte wieder einkommentiert wurden, kann Nginx neu gestartet werden:

service nginx restart

Anschließend ist die Komprimierung mittels gzip aktiv.

Post-ID unter WordPress ermitteln

Manchmal wird die Post-ID einer Seite unter WordPress benötigt. Dann stellt sich die Frage, wie diese ID ermittelt werden kann? Wenn die ID Teil des Permalinks ist, so kann sie einfach anhand der URL ermittelt werden.

Die Post-ID spiegelt sich im Permalink wieder

Bei Beiträgen funktioniert diese Variante in vielen Fällen, bei Seiten wird dies schwieriger. Um die Post-ID einer beliebigen Seite oder eines Beitrages zu ermitteln, muss diese im WordPress-Backend bearbeitet werden. Dort findet sich in der Adressleiste eine URL nach folgendem Schema:

https://seeseekey.net/wp-admin/post.php?post=125008&action=edit

Der Wert hinter dem Parameter post spezifiziert die Post-ID, welche somit ermittelt wurde.

ownCloud und Nextcloud

Mit ownCloud gab es ab 2010 eine Lösung Daten in der Cloud zu lagern, welche nicht bei einem dritten Dienstleister, wie z.B. Dropbox, hinterlegt werden mussten. Im Gegensatz zu anderen Lösungen aus der damaligen Zeit ließ sich ownCloud relativ unkompliziert auf einem einfachen Webspace, welcher über PHP und eine Datenbank verfügte, installieren. Einige Jahre entwickelte sich ownCloud prächtig, bis es zu Meinungsverschiedenheiten über die Ausrichtung von ownCloud kam. Darauf hin verließen Frank Karlitschek, der Hauptentwicker von ownCloud, und einige weitere Entwickler die Firma ownCloud GmbH und spalteten das Projekt unter dem Namen Nextcloud ab.

Eine ownCloud-Installation wird zu Nextcloud migriert

Damit lief die Entwicklung der beiden Lösungen eine Weile parallel, wobei die Community und ein Großteil der Entwicklerkapazitäten gefühlt in Nextcloud steckten. Vor ein paar Tagen kündigte die ownCloud GmbH an, seine Architektur komplett umzustellen, womit die ursprüngliche ownCloud wohl tot ist und Nextcloud der mehr als legitime Nachfolger ist.