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.

Maximale Größe von Mails unter Postfix konfigurieren

Standardmäßig ist die maximale Größe von Mails beim MTA Postfix auf 10240000 Byte, knapp 10 MiB, beschränkt. Soll diese Einstellung bearbeitet werden, so muss die entsprechende Konfigurationsdatei von Postfix bearbeitet werden:

nano /etc/postfix/main.cf

In der Datei muss die Option message_size_limit hinzugefügt werden:

message_size_limit = 40960000

In diesem Fall wurde die maximale Größe von Mails auf knapp 40 MiB gesetzt. Nach einem Neustart von Postfix:

service postfix restart

ist die neue Obergrenze gesetzt und Mails können bis zur entsprechenden Größe versendet werden.