Im Jahr 2008 war ich zum ersten mal in den USA und habe für die Familie einen einfachen Blog auf Overblog verfasst.
Es dauerte bis 2015, dass ich/wir wieder begann/begannen, Reiseblogs zu schreiben. Carina und ich besuchten damals den Westen der USA und Hawaii und ich erstellte dafür meinen ersten Blog bei WordPress (https://gowest2015.wordpress.com/). 2016 flogen wir nach Schottland und nach Irland, was Anlass zur Einrichtung eines weiteren WP-Blogs gab (https://greenislands2016.wordpress.com/). Zu diesem gesellte sich 2017 ein weiterer Blog, diesmal berichteten wir darin über unsere Reise nach Skandinavien (https://skandinavien2017.wordpress.com/). Ende 2017 startete ich dann einen weiteren Blog, der alles Zukünftige beherbergen sollte. Dieser trägt die Adresse https://middlecreeklife.wordpress.com/.
Anfang 2020, nachdem ich mir einiges an Wissen zu den Themen Internet, Webhosting, Netzwerktechnik usw. angeeignet hatte und inzwischen im Besitz mehrerer Domains war, leistete ich mir einen kostenpflichtigen Tarif für https://middlecreeklife.wordpress.com/, um diesen unter meiner eigenen Subdomain blog.resch.cloud betreiben zu können.
Das ging solange gut, bis ich meine Webpräsenz unter resch.cloud (resch.cloud, cam.resch.cloud, tools.resch.cloud) neu zu gestalten begann und mich im Zuge dessen etwas mit den Themen Datenschutz, Offenlegungspflicht, Impressumspflicht usw. auseinandersetzte. Ich hatte das Gefühl, dass ich Sites, die ich nicht selbst hoste wahrscheinlich nie rechtlich einwandfrei betreiben werden kann, nachdem dabei die Kontrolle über Cookies, Serverlogs usw. fehlt. Dazu kam, dass die Site bei WordPress recht langsam war, die Komprimierung hochgeladener Bilder nicht zuverlässig klappte, ich mit meinem Tarif keine Plugins installieren konnte und sich der spärliche Speicherplatz bei WordPress schnell füllte. Das alles, während sich mein Webhosting-Account bei Hetzner, der IPv6, TLS1.3 und genügend Speicher hatte, zu Tode langweilte.
So kam, was kommen musste und ich beschloss, alle Blogs in einer selbst verwalteten WordPress-Installation bei Hetzner zusammenzufassen.
Die eigene WordPress-Installation
Die erste Mission war, WordPress zu installieren. Das gelang schon fast erschreckend reibungslos, indem man sich in der KonsoleH, der Webspace-Verwaltung von Hetzner, anmeldete, auf „Wordpress installieren“ klickte, eine Subdomain wählte bzw. erstellte (in meinem Fall blogb.resch.cloud, nachdem blog.resch.cloud ja noch in Benutzung war) und Sekunden später die Zugangsdaten zur neuen, eigenen WP-Installation in seinem Mail-Eingang vorfand.
Dann noch mit ein paar Mouseklicks ein Let‘s Encrypt-Zertifikat angefordert, zwecks Sicherheit noch ein paar Zeilen zur htaccess-Datei hinzugefügt, die HSTS usw. aktivieren, das ganze mit dem SSL Server Test von Qualys überprüft und schon war es vollbracht. Meine eigene WordPress-Installation mit IPv6 und TLS1.3 unter meiner Verwaltung war fertig. 🤯
Ich taste mich etwas tollpatschig durch die Admin-Menüs von WordPress, deutlich übersichtlicher und logischer als bei den Sites, die von WordPress selbst gehostet werden. Ich mache, was man halt als erstes so macht und klicke mich durch Themes und deren Optionen. Ich installiere, teste und deinstalliere verschiedene Plugins, mache Updates und kann mich schnell mit der Verwaltung anfreunden und ausreichendes Vertrauen in die Software aufbauen.
Ich überlege, was ich nun mit diesem schnell erlangten Glück anfangen soll. Einen neuen, „finalen“ Blog starten? Nein, das löst mein Datenschutzproblem nicht. Alles Alte abtippen und hunderte Bilder neu aus Lightroom exportieren und hochladen? Nein. Zu fehleranfällig und vor allem viel zu viel Arbeit. Somit:
Daten von WordPress in die neue Installation übertragen
Ein wenig Watscheln und Googeln später klicke ich in einem der alten Blogs auf Werkzeuge -> Daten exportieren -> Alles exportieren und erhalte unverzüglich eine XML-Datei mit allen Seiten, Beiträgen usw. aus dem alten Blog.
Ebenso einfach gestaltet sich der Import in die neue Installation zu Anfang. Man wählt das XML-File, ordnet die Beitragsautoren aktuellen Usern zu, wählt, dass man alle Medien von der alten Site herunterladen und in die neue Site importieren will und klickt auf OK.
Nach einiger Wartezeit bricht das ganze mit einem Serverfehler ab.
Ich experimentiere für mehrere Stunden herum, um dann eine Lösung erarbeitet zu haben:
Man exportiert das XML-File aus der alten Site
Man öffnet das File in einem Texteditor seiner Wahl und lokalisiert den Haufen „<item>“-Elemente in der Mitte des Dokuments
Man entfernt so viele dieser Elemente, dass 1500 bis 3000 Zeilen stehen bleiben. Wichtig ist dabei, nichts anderes als „<item>“-Elemente auszuschneiden
Man speichert die gekürzte Datei unter einem neuen Namen (z.B. „alterblog.wordpress.com_part-1.xml“)
Man öffnet die Originaldatei erneut, entfernt die soeben gespeicherten „<item>“-Elemente und lässt wieder nur ca. 2000 Zeilen stehen.
Das Ziel der Übung ist, die „<item>“-Elemente aus der ursprünglichen Datei auf mehrere Dateien aufzuteilen, die anderen Elemente müssen dabei aber unangetastet bleiben.
Beispiel für ein „<item>“-Element, in dem Fall ist es ein Bild
Die so entstandenen Dateien
Diese neuen Dateien importiert man dann in die neue Site und wählt auch die Option, die Medien zu importieren. Schlägt das fehl, kann man einen zweiten Versuch unternehmen oder das XML-File weiter kürzen.
So importiere ich alle Beiträge, Seiten, Kategorien, Menüs, Schlagworte usw. in den neuen Blog, was mich zuversichtlich genug stimmt, um die Domain blog.resch.cloud von WordPress zu lösen und für den neuen, selbst gehosteten Blog zu benutzen. Dabei erscheint die Meldung, dass man das nicht rückgängig machen kann, außer man bezahlt nochmals (!!!) für den entsprechenden Tarif. Für ein volles Jahr wohlgemerkt. Naja was solls, es soll dann eh so bleiben.
Subdomain blog bei Hetzner eingerichtet, in WordPress blogb.resch.cloud durch blog.resch.cloud ersetzt, DNS-Einträge angepasst, Zertifikat angefordert, Zertifikat erhalten und eigentlich war der neue Blog fertig.
Eigentlich.
Das Importieren der Daten aus den alten Blogs hat nahezu perfekt geklappt, was den Text der Beiträge, die Titel, die Kategorien und die Schlagwörter sowie die Autoren und die Veröffentlichungszeitpunkte angeht.
Bei den Bildern sieht das leider anders aus. Es wurde zwar fast jedes Foto in die neue Mediathek importiert, die Zuordnung der Bilder in den Beiträgen war aber leider oft falsch. Entweder sie verwies auf die Adresse des alten Blogs oder es wurde die Änderung der Domain von blogb.resch.cloud auf blog.resch.cloud nicht übernommen.
Eine Beitragsseite und die aufgerufenen Dateien
Was jetzt also noch fehlt, ist eine Überarbeitung praktisch aller Beiträge hinsichtlich der enthaltenen Fotos. Auch die Links, die auf andere Blogbeiträge verweisen, müssen auf die neue Site umgestellt werden. Außerdem waren manche Galerien scheinbar von Plugins abhängig, die in den Sites auf wordpress.com installiert sind, bei einer eigenen Installation aber nicht funktionieren.
Carina und ich haben das innerhalb weniger Tage erledigt, die alten Sites sind zum Zeitpunkt des Verfassens dieses Beitrags bereits nicht mehr öffentlich erreichbar.
Wir haben dabei entschieden, die Fotos aus den alten Blogs in Form der nativen „Galerien“ zu gestalten, um fürs Erste nicht von Plugins abhängig zu sein. Wie wir zukünftige Beiträge aufbauen, wird sich spätestens bei der nächsten Reise zeigen.
Ein letztes Problem wollte aber noch gelöst werden:
Mails aus WordPress unter eigener Domain verschicken
Wenn man in WordPress einen neuen User anlegt oder wenn jemand einen Kommentar hinterlässt oder wenn man seine eigene eMail-Adresse ändert, werden aus WordPress Mails verschickt. Das passiert direkt am Webserver durch den Einsatz von PHPmailer.
Die Absenderadresse kann man hierbei frei wählen, ich habe mich für blog@resch.cloud entschieden und das dann auf blogadmin@resch.cloud geändert. In beiden Fällen landeten die so versendeten Mails aber beim Empfänger im Spam-Ordner, nachdem noch ein paar Einstellungen anzupassen waren.
Es gibt mehrere Protokolle, um die Echtheit von eMails zu gewährleisten und Spam zu verhindern. Für den aktuellen Fall ist SPF und DMARC relevant.
SPF
SPF funktioniert so, dass man einen DNS-Eintrag unter seiner Domain hinzufügt, in dem man alle Server angibt, die berechtigt sind, eMails mit der eigenen Domain zu verschicken. Ich verwende ProtonMail, mein SPF-Eintrag sieht daher so aus:
@ IN TXT "v=spf1 include:_spf.protonmail.ch mx ~all"
Das heißt, dass alle Mailserver von ProtonMail eMails in meinem Namen versenden dürfen. Versendet ein anderer Server Mails mit meiner Domain, prüft der Empfänger-Server diesen Eintrag und markiert die Mails als Spam.
Nachdem jetzt mein Webserver eMails mit meiner Domain als Absender verschicken soll, muss ich dessen IP-Adressen in den DNS-Eintrag aufnehmen.
@ IN TXT "v=spf1 include:_spf.protonmail.ch mx ip4:188.40.30.46 ip6:2a01:4f8:d0a:11f4::2 ~all"
Auch nach dieser Änderung werden die Mails weiterhin als Spam klassifiziert. Das hat folgenden Grund:
DMARC
DMARC kann zwei Dinge: Einerseits erlaubt es einem Domaininhaber – wieder über einen DNS-Eintrag – festzulegen, was mit einem abgelehnten eMail passieren soll und ob er darüber benachrichtigt werden soll. Andererseits prüft es, ob die Domain der sogenannten From-Adresse (Absenderadresse) mit der Domain der Return-Path-Adresse (Antwortadresse) übereinstimmt. Wäre dem nicht so, könnte man z.B. von bla.com eMails mit google.com als Antwortadresse versenden, was natürlich unerwünscht ist.
In meinem Fall war es so, dass als From-Adresse irgendwas@resch.cloud und als Return-Pathirgendwer@www218.your-server.de, also die Domain der Webserver-Hostmaschine (www218) bei Hetzner angeführt war und DMARC daher das eMail als nicht vertrauenswürdig einstufte.
Abhilfe schaffte das Plugin Stop WP Emails Going to Spam, das die envelope-from– und die Return-Path-Adressen sowie die From– Adresse richtig – also auf die eigene Domain – setzt und somit dafür sorgt, dass die eMail-Empfänger keinen Grund für Misstrauen haben und die Nachrichten nicht im Spam landen.
Vergleich der Mails vor und nach den Änderungen (ja, es gibt noch weitere Unterschiede, die sind aber für diese Erklärung nicht relevant)
Falls jemand selbst vor einem solchen Umzug steht und Fragen dazu hat oder etwas zu diesem Artikel beitragen möchte, so möge er einen Kommentar hinterlassen oder mir ein eMail schicken. Ich möchte an dieser Stelle auch darauf hinweisen, dass ich keineswegs Profi auf diesem Gebiet bin und ich hier nur meine persönlichen Erfahrungen teilen möchte.
Wenn du Feedback loswerden möchtest, nutze bitte das Kontaktformular.
Falls dir mein Beitrag weitergeholfen hat, würde ich mich sehr über einen kleinen Kaffee freuen. Oder du nutzt einen meiner Empfehlungslinks und sparst dir damit etwas Geld: Tesla (500€ Rabatt), Hetzner Cloud (20€ Guthaben), Ufodrive (30€ Rabatt). Außerdem habe ich eine Wunschliste bei Amazon.
