Entfernen des gist-Plugins und YouTube aus WordPress

Ich habe nun das nächste Plugin aus WordPress entfernt. Auch habe ich mir nochmals Gedanken über dieses Plugin gemacht und es ist definitiv nicht Datenschutz konform, wenn ich Daten aus Github nachgeladen habe. Ich hatte zwar somit immer die neueste Version des Codes eingebunden, aber es war eigentlich eine Faulheit auf Kosten der Lesenden.

Im Moment suche nun Shortcodes mit der Bezeichnung gist id=“ und kopiere den Inhalt dieser Gists in den Fließtext. Die richtige Aufgabe während meiner Krankmeldung. Falls ich mich mit etwas anderem als im Bett liegen und Hörbuch hören befassen möchte. Für das Teilen von Code habe ich mir noch keine Gedanken gemacht, aber es wird definitiv selbst gehostet und sollte keinen großen Pflegebedarf haben. Bis jetzt habe ich hier leider noch nichts gefunden. Gitlab und ähnliche Projekte wären mit Kanonen auf Spatzen geschossen. Gitweb wäre ein Lösung, habe ich noch nicht im shared Hosting noch nicht getestet.

Vor sehr langer Zeit war es einmal in der Blogosphäre gang und gebe die Videos der Plattform YouTube einzubinden. Damit ich hier nicht mit den Daten der Lesenden hausieren gehe, hatte ich das Plugin „Lazy Load for Videos“ installiert. Diese direkten Links wurden nun gegen normale ausgetauscht

Ich konnte mir viel Handarbeit wieder zwei Plugins deaktivieren und entfernen.
Mittlerweile sind nun 9 Plugins deaktiviert bzw entfernt worden.

Cookieless WordPress seit heute

Ich habe nun meine Bannermeldung nach dem Telekommunikation-Telemedien-Datenschutz-Gesetz (TTDSG) abgeschaltet.
Siehe hierzu auch das Urteil des Bundesgerichtshofs vom 28. Mai 2020, Aktenzeichen I ZR 7/16.
Ich betrieb meine Installation von Matomo schon so, dass seitens Matomo keine Cookies gesetzt wurden. Durch das Abschalten der Kommentarefunktion in WordPress konnten auch hier auf Cookies verzichtet werden.

Weiterlesen

Auf ein Minimum in WordPress

Nach über 14 Jahren Gebrauch ist WordPress eine Art von Hassliebe. Es ist nicht so, dass ich nicht andere Plattform für das Schreiben im Netz ausprobiert hatte. Ich startete mit WordPress, besuchte Drupal,Octopress und Serendpity, um am Ende doch wieder bei WordPress zu landen.

Somit sitze ich im Moment vor meinem, doch in die Jahre gekommen Blog, und beginne aufzuräumen. Ausgeschaltet habe ich die Kommentarfunktion und konnte hierdurch nun zwei Plugins schon abschalten. Des Weiteren löse ich ein Plugin aus, welches mit Shortcodes eine eine bessere Verlinkung in verschiedene Appstore ermöglichte. Anhand der ID in Shops ließen sich hier automatisch QR-Codes und Screenshots in den Beitrag einbinden. Es dreht sich hier nicht Affiliate-Links. Etwas Arbeit, aber ich brauche es wirklich nicht mehr.

Nach einigen Hin und Her war ich kurz davor eine Migration in Jekyll für das Blog vorzunehmen. Ein statisches Blog hat Vorteile, wie auch Nachteile. Ich hätte serverseitig ein gutes Gefühl, aber betreffend der Arbeit an einem Blog bin ich mir nicht sicher, ob ich dies alles so möchte. Ich bin diesen Weg schon einmal gegangen. Wobei mein Ablauf für ein statisches Blog prädestiniert wäre.

Mein jetziger Ablauf für einen Artikel sieht so aus, dass ich unter Linux, oder macOS, mit Typora meine Posts in Markdown verfasse und dann in WordPress nochmals neu formatiere. Mit Jekyll würde ich hier mir mehr als einen Weg sparen. Aber ich müsste hier zum Beispiel auf zwei bei gute Plugins verzichten müssen, sowie auf den Import der alten Kommentare. Einmal schnell im Web weiterzuarbeiten ist hier keine Option, obwohl diese bei mir nie eigentlich eine Rolle spielt.

Vorerst also bei WordPress auf das nötige Beschränken an Plugins beschränken und dann sehe ich einmal weiter. Es besteht ja die Möglichkeit auch einmal zweigleisig zu fahren und bei Bedarf umzuschalten. In WordPress gibt es die Möglichkeit, Dateien im Format Markdown in WordPress zu importieren. Ich muss auf jeden Fall raus aus den Insellösungen der Shortcodes durch Plugins. Dann wäre das Migrieren und vielleicht auch der Rückweg eine Sache von Minuten. Der Import in Jekyll lokal hat mir hier ein kleines Grauen offenbart.

Ein kleiner Umzug

Ein Dingy Board welches mit einem rechten Fuß in Vans sk8 high gehalten wird.

Diesen Blogpost hatte ich Anfang des Jahres verfasst und irgendwie nicht veröffentlicht.

Friendi.ca ist eine Software, welche ich wirklich jahrelange genossen habe.
Meine Instanz war über 8 Jahre alt und ich hatte dort alle Daten von meinem Account bei Google+ einsammeln lassen und konserviert. Ein Backup wirklich guter Gespräche. Eine gute Software. Anpassbar und mit Verbindungsmöglichkeiten zu vielen anderen proprietären, sowie offenen sozialen Netzwerken. Bis ich nun den Kampf um, und mit, der Software aufgegeben habe.

Weiterlesen

Uptime Kuma, mein Monitoring Werkzeug

black flat screen tv turned on near black and gray audio component
Ibrahim Boran Control panel and buttons of a cruise ferry in the cockpit. Unspash.org

Für mich ist die Erreichbarkeit von Diensten der von mir betreuten Webseiten und Services sehr wichtig. Hierfür nutze ich nicht nur Icinga2 in Verbindung mit Grafana, sondern auch ein ziemlich simples, aber auch mächtiges Werkzeug. Uptime-Kuma eine Opensource on premise Monitoringsoftware.

Weiterlesen

Autoscaling in WordPress 5.3

Um das Autoscaling der hochgeladenen Bilder von max 2560px in Höhe bzw Breite zu unterbinden ist folgende Zeile in der functions.php nötig

add_filter( 'big_image_size_threshold', '__return_false' );

Wird dies nicht vorgenommen werden alle neu hochgeladenen Bilder in Ihrer maximalen Größe automatisch begrenzt. Ich gehe davon aus, dass dies von den meisten unerwünscht ist.

Mir folgenden Code in der functions..php kann aber der Wert auch auf einen selbst definierten geändert werden. In diesem Beispiel wird Ihm ein Wert von 4800px zugewiesen

function dg_big_image_size_threshold( $threshold ) {
	return 4800;
}
add_filter('big_image_size_threshold', 'dg_big_image_size_threshold', 100, 1);

Zabbix Server hängt bei einem Neustart

Photo by Kent Pilcher on Unsplash

Nach dem heutigen Kernelupdate musste ich feststellen, dass unseren Zabbixserver bei einem Reboot immer noch eine vom Maintainer falsch ausgerollte Einstellung plagt. Ein Reboot ist nicht möglich, da in der zuständigen Servicedatei für den SystemD ein TimeoutSec=infinity gesetzt ist. Erst der Zeitwert des forcierten Neustarts würde dem ein Ende setzen

In der Datei /lib/systemd/system/zabbix-server.service sollte ein für den Server passender Wert eingesetzt werden.

[Unit]
Description=Zabbix Server
After=syslog.target
After=network.target

[Service]
Environment="CONFFILE=/etc/zabbix/zabbix_server.conf"
EnvironmentFile=-/etc/default/zabbix-server
Type=forking
Restart=on-failure
PIDFile=/run/zabbix/zabbix_server.pid
KillMode=control-group
ExecStart=/usr/sbin/zabbix_server -c $CONFFILE
ExecStop=/bin/kill -SIGTERM $MAINPID
RestartSec=10s
TimeoutSec=240

[Install]
WantedBy=multi-user.target