Umstieg auf PHP 8.0 bzw. 8.1

Der Wechsel der PHP Versionen ist immer mit Vorsicht zu genießen. Das war vor Jahren mit PHP 5.4 auf die 7.x Reihe so und ist nun von 7.4 auf 8.x leider auch so. Aber nachdem nun Nextcloud gemeint hatte, sie müssen mal PHP 7.4 aus der Unterstützung herausnehmen, hab ich mal Ramba Zamba gemacht.
Einfach mal auf dem Webspace PHP 8.0 eingeschaltet. Meine Cloud lief danach einfach weiterhin. Also alles kein Problem. Meine Geschäftsseite läuft auch weiterhin ohne Probleme. Aber dieses Blog lief dann erstmal nicht mehr.

Was hab ich gemacht?
- Einfach mal das PHP Compatibility Checker Plugin installieren und auf die PHP 7.3 checken.
- Das Ergebnis gibt schon mal einen guten Hinweis, welche Plugins oder Themes potenziell Probleme geben werden.
-> Bei mir waren dies beispielsweise das Soundcloud Embed Plugin und das Midhan Kommentar Bearbeitungs-Plugin. Da aber beide Plugins schon uralt sind, hab ich diese mal deaktiviert und mit PHP 8.0 ausprobiert. Hat wunderbar funktioniert.
- Für das Bearbeiten von Kommentaren gibt es diese schlanke Alternative. Es macht was es soll. Der Kommentator kann seinen Kommentar noch 5 Minuten lang editieren oder auch löschen.

Und siehe da, der Umzug auf PHP 8.1 war dann auch kein Thema mehr.

Warum ist PHP 8.0 bzw. 8.1 überhaupt erstrebenswert? Na erstens, weil diese Versionen noch aktuell weiterentwickelt werden und damit auch mit Sicherheitspatches gefüttert werden. Außerdem soll 8.1 nochmal einen enormen Performance Boost bringen. Und gerade für WordPress oder Nextcloud kann PHP nie schnell genug sein.

Einziger Wehmutstropfen: Mein uraltes Toffifee Skript von 2005 tut aktuell nun nicht mehr.
Liegt vielleicht am GET Request. Aber ich bin da aktuell einfach zu faul. Vielleicht kümmere ich mich mal darum, wenn ich viel Zeit und Lust habe.
Oder hat einer meiner Leser einen Tipp, was die Ursache sein könnte?
Ich muss mich da erstmal wieder reinfuchsen und vermutlich sind die REQUEST_METHOD schon problematisch. Aber wie gesagt. Das Teil ist halt und hat eigentlich nur noch historischen Wert. Lustig war es aber trotzdem.

Complianz für sichere Youtube Videos

Youtube Videos erfordern nun explizite Zustimmung

Vor ein paar Tagen hab ich ja über die Google Fonts und wie man sie vom lokalen Webserver ausliefern lassen kann geschrieben. Aber trotzdem hatte mein Blog immer noch Probleme, dass die Youtube Videos weiterhin Schriften von Google geladen haben.
Dies kann ich ganz einfach umgehen, indem ich das Complianz Cookie Plugin installiert haben. Sobald der Benutzer seine Zustimmung erlaubt, werden die Youtube Videos aktiviert. Sollte er es nicht machen, bleiben die Youtube Video deaktiviert.

Ich habe meinen Blog schon weitestgehend optimiert um so wenig Cookies wie möglich zu nutzen.
- Kein Google Analytics stattdessen Statify welches nur die Aufrufe der Seiten anonym zählt.
- Google Fonts werden lokal geladen.
- Youtube Videos werden über die Nocookies Server geladen um Tracking zu vermeiden.
- Eingebettete Videos von Youtube oder Soundcloud werden nur noch nach Cookie Zustimmung geladen.

So sollte ich erstmal fein raus sein.
Falls euch noch etwas auffällt, dann lasst mir doch gerne einen Kommentar da. ;)

WordPress: Google Fonts auf lokalen Server auslagern

Google Fonts ist ja ein Thema. Es gehen auch immer mal wieder Abmahnungen rum. Siehe die Links von LNP 445. Aber als ich Anfang des Jahres geschaut habe, gab es noch keine sinnvolle Möglichkeit per Plugin die Fonts lokal zu laden.
Nun gibt es aber doch die Möglichkeit dazu und das Ganze relativ leicht. Bei Netzgänger gibt es eine tolle Anleitung dazu.
Nämlich mit dem Plugin Local Google Fonts. Das macht seinem Namen alle Ehre. Nämlich die Google Fonts runterzuladen und vom eigenen Server auszuliefern.
Leider habe ich wohl mit dem Twenty Sixteen doch noch ein sehr altes Theme, welche auch nach dem Aktivieren des Plugins immer noch Schriften von Google lädt.
Ihr könnt entweder über die Entwicklerkonsole im Browser checken ob ihr Schriften von Google nachlädt oder einfach mal dieses Tool laufen lassen.
Bei einer Kundin hat es jedenfalls gut funktioniert.
Falls ihr auch ähnliche Probleme habt und Hilfe benötigt schreibt mich gerne an. Ich schau es mir dann und finde sicher eine passende Lösung.

//Update 19.11.2022: Meine Website lädt grundsätzlich schon alle Schriften lokal. Aber durch die eingebundenen Youtube Videos (die übrigens alle über die nocookie Server geladen werden!) werden leider trotzdem Youtube Videos geladen. Das hat mir auch der Ersteller des Plugins bestätigt.
Leider ist es wohl allgemein schwierig, die Google Fonts loszuwerden. Die einfachste Methode ist wohl den Besucher ordentlich drauf hinzuweisen, dann weiß er zumindest worauf er sich einlässt.

Ein weiterer guter Google Fonts Checker ist dieser hier. Damit kann man sogar die zu prüfende URL verlinken. :)
Wer sowieso ganz frisch ein WordPress Theme aufsetzt kann ja auch gleich darauf achten, dass es nach Möglichkeit gar keine Google Fonts Verweise hat. Dann kann man sich die Plugins auch sparen. ;)

Frische WordPress Installationen werden gekapert

Dieses Problem mit gerade frisch installierten WordPress Instanzen ist schon irgendwie bemerkenswert.


Es scheint, dass dies ein wenig mit der Funktionalität von Let's Encrypt zusammenhängt. Durch das sogenannte Certificate Transperancy werden neue Zertifikate von gerade erstellten Domains recht schnell propagiert. Daher kann ein Skript diese Domains recht schnell auf noch nicht komplett durchlaufene WordPress Installations Assistenten suchen und so diese WordPress Instanzen einfach übernehmen.
Mir war vollkommen unbekannt, dass dies heute noch so einfach möglich ist. Denn die meisten ordentlichen Webspace Provider (Domain Factory, Webgo oder Strato) haben alle heute Installer, welche für einen im Hintergrund gleich eine neue WordPress Instanz installieren. Dabei wird auch gleich ein neues Admin Password abgefragt, so dass die Installation fertig ist.
Scheinbar gibt es aber auch noch günstige Webhosting Anbieter, welche solche Automatismen nicht haben. Klar, dann registriert man seine Domäne und vielleicht damit auch gleich noch sein Let's Encrypt Zertifikat und schon ist die Domäne bekannt. Als nächstes lädt man das entpackte WordPress ZIP per FTP auf seinen Webspace. In dieser Zeit kann der Angreifer schon die WordPress Installation gefunden haben und fertig gestellt haben. Gut, findige Leute können das Ganze ja wieder löschen. Aber eventuell merkt man es nicht mal.
In diesem Fall würde ich vermutlich diesen Weg gehen (hab ich nicht ausprobiert):
1. WordPress ZIP hochladen
2. Installation mit einer Zwischendomain (am besten noch ohne Let's Encrypt Zertifikat) durchführen.
3. Richtige Domain einrichten (auf das WordPress Verzeichnis zeigen lassen und Let's Encrypt einrichten).
4. Die wp-config.php noch eine Ebene weiter hochschieben.
5. Die WordPress Instanz mit der richtigen Domain aufrufen und eventuell schauen ob diese in den Einstellungen richtig eingerichtet ist.
-> Vielleicht muss man dazu aber auch noch die wp-config.php anpassen.

Aber damit entfällt in der Theorie ja die Möglichkeit, dass potenzielle Skriptkiddies so schnell durch Certificate Transparency von der WordPress Instanz erfahren ohne dass die Installation schon fertig ist.

Fand ich eben spannend, da meine WordPress Installation auch schon ewig alt ist und ich deshalb schon lange keine frische WordPress Installation mehr gemacht habe.