Blog-Umzug: Insights aus dem Maschinenraum – Teil 2

In Teil 1 meiner zwei Blog-Beiträge hatte ich dargelegt, warum ich meinen IT-Blog und weitere Blogs in den letzten Wochen vom Anbieter HostEurope zu All-Inkl umgezogen habe. Der Umzug ist (bis auf Feintuning) weitgehend abgeschlossen. Ich hatte noch einige Insights versprochen, die ich nun in Teil 2 offen legen möchte.

Warum ich eine Multisite-Installation aufgelöst habe

Ich betreibe aktuell insgesamt sechs Blogs unter der Domain borncity.com – von denen einer der IT-Blog hier ist. Auf borncity.com liegt nur eine Startseite, die dann auf einen Teil der Einzelblogs, die unter Sub-URLs wie blog, win, senioren, reisen etc. erreichbar sind, verlinkt.

Das Angebot ist dabei historisch gewachsen – der IT-Blog hier lag bei HostEurope schon immer auf borncity.com/blog und war als Single WordPress-Blog implementiert. Irgendwann vor vielen Jahren beschloss ich dann, dass ein englischsprachiges Pendant zum IT-Blog nicht schlecht wäre – und ich wollte eine "Spielwiese" für meine 50Plus-Buchleserschaft in Form eines Seniorenblogs.

Seinerzeit entstand die Idee, dies als sogenannten Multisite-Blog zu implementieren. Weil ich den deutschen IT-Blog nicht in einem Multisite-Blog transferieren konnte, entstand ein Multisite-Blog, dessen Dateien unter borncity.com lagen, aber Blogs unter URLs wie  borncity.com/win etc. abbildeten. Der große Vorteil eines Multisite-Blogs:

• Man braucht nur eine WordPress-Installation und eine Datenbank. Anschließend werden die Blogs im WordPress Dashboard angelegt.
• Es ist nur eine Benutzeranmeldung erforderlich – man meldet sich an einem Blog an, und kann auf alle Blogs als Administrator zugreifen.
• Plugins werden zentral in der Netzwerkverwaltung des Multisite-Blogs installiert, können auf den Blog-Seiten aber konfiguriert werden.

Was auf den ersten Blick genial erscheint, erwies sich für mich aber im Endeffekt als Pferdefuß.

• Plugins brauchen zwar nur einmal installiert zu werden, müssen aber in der Netzwerkverwaltung aktiviert und ggf. aktualisiert werden.
• Es gibt immer wieder Plugins, die keinen Multisite-Betrieb zulassen oder einfach Probleme bereiten.
• Geht etwas bei einem Blog schief (z.B. Update, Plug-In-Aktualisierung), wirkt sich dies ggf. auf alle Blogs aus.

In meiner HostEurope-Umgebung lief es darauf hinaus, dass eine WordPress-Installation unter borncity.com lag, während eine zweite Installation unter borncity.com/blog zu finden war. Kam es zu Problemen, z.B. bei einem streikenden Plugin, und ich musste per FTP eingreifen, war immer das Rätselraten, wo der Ordner für die Installation zu finden ist.

Mein größtes Problem war aber, dass mit irgend einem WordPress-Update die Verbindung vom Windows Live Writer (WLW) mit der xml-rpc-Schnittstelle des Multisite-Blogs gekappt wurde. Mit dem WLW habe ich die letzten 15 Jahre meine Blog-Beiträge offline verfasst und dann in den Blogs publiziert. Dazu waren die Blog-Zugänge im WLW konfiguriert.

Das Publizieren über die xml-rpc-Schnittstelle ist zwar sicherheitstechnisch unschön, weil es über eine ungesicherte http-Verbindung passiert. Aber es war sehr komfortabel, einen Blog-Beitrag auf Deutsch im WLW zu verfassen, im IT-Blog zu publizieren, dann den Text in Englisch zu übersetzen und dann diese Variante per WLW im englischsprachigen Blog zu veröffentlichen. Im WLW hatte ich zudem zwei Plug-Ins, die mir die Zeichenzahl eines markierten Beitragsbereichs anzeigte sowie das Einfügen von Code-Schnipseln ermöglichte. Die Beitragsbilder am Artikelanfang werden so per Template im Blog eingefügt.

Aber wie erwähnt: Das funktionierte plötzlich, nach einem WordPress-Update nicht mehr. Wie so oft im Blogger-Leben bekam ich von Kollegen, als ich "funktioniert nicht mehr" berichtete, die Rückmeldung "funktioniert hier sehr wohl" als Feedback. Meine Vermutung: Konnte an meiner HostEurope-Lösung liegen, wo Konfigurationsdateien sich gegenseitig beeinflussten und möglicherweise Probleme bereiteten.

Als ich dann mein Konto bei all-inkl.com eingerichtet habe, gab es die Gelegenheit, unter der Domain borncity.eu einen Multisite-Blog zum Testen aufzusetzen. Schon nach wenigen Minuten war klar: Ein Einzelblog funktioniert mit dem Windows Live Writer, ein Multisite-Blog nicht. Die Implementierung des WLW gibt das nicht her.

Und weil es gefragt wurde: Der Open Live Writer (OLW) hilft auch nicht, der streikt genau so, hat aber weitere Nachteile. So wurde im OLW nie eine Plugin-Schnittstelle implementiert. Daher konnte ich meine Hilfs-Plugins aus dem WLW nicht verwenden. Zudem ist die WLW-Rechtschreibprüfung im OLW aus Lizenzgründen entfallen. Dort setzt man auf die Rechtschreibprüfung, die ab Windows 10 verwendet wird. Aus diesem Grund kam der Open Live Writer hier nie zum praktischen Einsatz.

Es gibt zwar BlogDesk als Client für Windows, der sogar mit einem Multisite-Blog unter WordPress funktioniert – zumindest als ich es zum letzten Mal getestet habe. Aber ich bin nie mit Blog-Desk warm geworden – der Windows Live Writer war um Klassen komfortabler.

Ich hatte vor einiger Zeit mal den groben Gedanken, auch den IT-Blog hier mit in den Multisite-Blog umzuziehen, habe das aber (wegen der Windows Live Writer-Problematik) nie praktisch umgesetzt. Nach den oben erwähnten Tests und den gerade geschilderten Erfahrungen war klar: Es wird am neuen Standort keinen Multisite-Blog mehr geben.

Ironie des Schicksals: Die Windows Live Writer-Problematik hat sich inzwischen erledigt. Denn beim neuen Hoster habe ich für borncity.com eine Option https erzwingen aktiviert. Damit kann der Windows Live Writer nicht mehr (per http) auf die xml-rpc-Schnittstelle eines Blogs (egal ob Einzelblog oder Multisite-Blog) zurückgreifen.

Aber ich habe mich dazu entschlossen, die Blogs in Einzelblogs aufzuteilen. Dafür gab es am Ende des Tages folgende Gründe:

• Ich wollte weg von der alten Struktur, dass im Hauptverzeichnis von borncity.com eine WordPress-Installation für einen Multisite-Blog, und im Unterverzeichnis blog die WordPress-Installation für den IT-Blog lag.
• Es war mir zum Schluss nicht mehr möglich, in den Blogs Caching-Plugins einzusetzen. Das war zwar lange Zeit mit dem LightSpeed Cache-Plugin kein Thema. Aber die Probleme mit PHP hatten mich Ende 2023 gezwungen, das Plugin rauszuwerfen und auf WP Fastest Cache zu setzen (war das einzige Plugin, welches auf Anhieb funktionierte). Aber das Cache-Plugin funktionierte nur für den IT-Blog – eine zweite Instanz im Multisite-Blog verursachte Probleme.

Heute bin ich ganz froh, das LightSpeed Cache-Plugin gekickt zu haben – das Plugin ist die letzten Monate durch mehrere fette Sicherheitslücken aufgefallen, die eine Site-Übernahme ermöglichten.

Ich hatte dann noch mit Blog-Leser Thomas, der einige WordPress-Installationen betreut, kurz Kontakt und ihn gefragt, was er von Multisite-Blogs hält. Die Antwort "Nix, ist ein Rabbit-Hole, gibt nur Probleme". Bestärkte mich im Entschluss, beim Umzug der Blogs den Multisite-Blog auf Einzelblogs aufzutrennen.

Wie trennt man eine Multisite in Einzelblogs auf?

An dieser Stelle stand ich vor der Frage: "Wie kommst Du auf all-inkl.com zu sechs Einzelblogs und einer Startseite". Die alte Startseite war ebenfalls als Blog im Multisite-Blog implementiert.

Der letzte Punkt war vermeintlich schnell gelöst: Ist habe schlicht den Inhalt der Startseite von borncity.com in eine HTML-Datei exportiert und das Ganze dann auf den neuen Webserver hochgeladen, wo es unter borncity.com erreichbar ist. Dadurch habe ich mir zwar einige andere Probleme eingefangen, die ich nun schrittweise korrigieren muss (z.B. Suchfeld geht nicht mehr, die Contentpass-Integration fehlt etc.). Aber ich hatte so die Möglichkeit, für jeden Einzelblog die WordPress-Installation in ein Unterverzeichnis wie blog, win etc. zu verlagern.

Der IT-Blog unter borncity.com/blog machte diesbezüglich auch keine Probleme, lag er doch als Einzelblog unter dieser URL auf HostEurope vor. Ich habe dann im betreffenden Ordner eine WordPress-Instanz neu installieren lassen und dann diese Instanz für den Datenbank-Zugriff für eine vorhandene Datenbank konfiguriert. Nachdem ich die fehlenden Plugins nachinstalliert hatte, lief dieser Blog – ich habe das Ganze vor dem Umzug unter borncity.eu getestet.

Bei der Aufteilung der Multisite-Blogs in Einzelblogs habe ich mir aber in den Fuß geschossen. Ich hatte die "geniale" Idee: Setze eine WordPress-Installation im gewünschten Unterordner auf, und konfiguriere die wp-config.php so, dass diese auf die Tabellen des jeweiligen Blogs in der gemeinsamen Datenbank zeigt. Bei Multisite-Blogs gibt es eine Datenbank, die die Benutzer enthält und für jeden Einzelblog einen Satz mit den Datenbank-Feldern für diesen Blog.

Das Aufsetzen war auch binnen weniger Minuten samt WordPress-Installation erledigt. Als ich den ersten Blog unter der URL borncity.com/win im Browser aufrief, erschien sofort der Inhalt des englischen IT-Blogs. Ich hatte den "Boris Becker"-Moment "das ist ja einfach". Das lange Gesicht gab es, als ich mich als Administrator an diesem Blog anmelden wollte. Meine Zugangsdaten wurden nicht akzeptiert – diesen Benutzer gibt es nicht, hieß es.

Nach einigen Sekunden nachdenken war klar, was passiert war: Ich hatte zwar über die wp-config.php die richtige Tabelle in der Datenbank konfiguriert. Diese enthielt aber keine Einträge für Administratoren und Benutzer, weil diese zentral für alle Multisite-Blogs in eigenen Tabellenfeldern gehalten wurden.

Ich hatte kurz den Gedanken: Kopiere die betreffenden Informationen in phpAdmin in neue Fehler der betreffenden Teiltabelle, hab das aber verworfen. Denn das Ganze ist ein "Rabbit-Hole" – Du frickelst über Stunden und kriegst es doch nicht zum Laufen. Eine bessere Lösung musste her. Da gibt es doch so tolle Plugins, von denen die "Tippgeber unter den Lesern doch so geschwärmt haben".

Eine Pleite kommt selten alleine. Das Duplicator-Migration-Plugin hatte ja bereits beim Umzug des IT-Blogs gepatzt (das Teil machte wegen der Datenbankgröße einfach die Grätsche und meinte "Du brauchst die Pro-Version, damit es vielleicht klappt"). Beim Multisite-Blog kam dann die Information "Umzug eines Multisite-Blogs in eine Single-Site-Installation wird nur in der Pro-Version unterstützt". Hätte das Duplicator-Plugin den Umzug des IT-Blogs gewuppt, hätte ich an der Stelle die Pro-Version gekauft. Aber so? Hätte, hätte, Fahrradkette. Zwei, drei weitere Migrations-Plugins, die ich kurz getestet habe, erwiesen sich ebenfalls als Nieten.

Am Ende habe ich das in obigem Screenshot abgebildete Migrate-Plugin "Prime Mover" in der Free-Version benutzt, um die Plugins, Layouts und Inhalte der einzelnen Blogs aus dem Multisite-Blog zu exportieren und im Anschluss im jeweils neue aufgesetzten Single-Site-WordPress-Blog zu importieren.

Das klappte bei allen Multisite-Blogs wunderbar. Lediglich ein OpenGraph-Plugin (OG) machte Probleme. Nach dem Import stand mein Staging-Blog, den ich unter borncity.eu aufgesetzt hatte. Aber es gab die Meldung, das Plugin OK hat den Blog abgeschossen und ich konnte das Plugin per FTP jeweils löschen. Später habe ich das Plugin vor dem Export bereits deinstalliert und am neuen Startort reinstalliert bzw. bin im zweiten Schritt auf ein anderes Plugin gewechselt.

Wo ich dann manuell eingreifen musste, war bei den Mediendateien (Bilder). Diese waren wohl nicht in den neuen Blog übertragen worden. Die habe ich dann aus einer Sicherung des alten Blog-Auftritts aus dem tar-Archiv extrahiert und per WinSCP in den korrespondierenden Ordner der WordPress-Installation hochgeladen.

Als alle Blogs unter borncity.eu als Staging-Varianten standen, habe ich die WordPress-Dateien für den IT-Blog in das Verzeichnis für die geplante Domain borncity.com/blog/ kopiert und dann den in Teil 1 skizzierten Domain-Umzug angestoßen.

Es gab zwar kleinere Anpassungsprobleme, weil ich in der wp-config.php erst ein falsches Datenbank-Passwort eingetragen hatte. Es gab daher beim Aufruf des Blogs einen Datenbankfehler. Und als ich das korrigiert hatte, meldete sich der Blog mit einem Setup-Dialog, den einzelne Leser zu sehen bekamen. Ich habe sofort den Tabellen-Alias, der auch falsch hinterlegt war, in der wp-config.php korrigiert, so dass die Blog-Inhalte angezeigt wurden.

Falls jemand sich Gedanken macht, dass die kurzzeitige Anzeige des Setups ein Sicherheitsproblem darstellt: Das trifft imho nicht zu, da außenstehende nicht den Alias für die bestehende Datenbank kennen. Selbst wenn ein Dritte auf die Schnelle WordPress aufgesetzt hätte – spätestens nach der Anpassung der wp-config.php wäre der Zugriff gestoppt worden. Und ich würde im phpAdmin die so angelegten Tabellenfelder sehen.

Im Anschluss habe ich dann die restlichen Blogs von borncity.eu zu borncity.com umgezogen – es waren im Grunde nur die Dateien auf dem Hosting-Paket in ein neues Verzeichnis kopieren und die wp-config.php anzupassen.

Ach ja, einen kleinen Nachteil gab es (neben dem Umstand, dass ich mich nun in mehreren Blogs anmelden muss): Ein von mir lizenziertes Plugin, welches in zwei Blogs eingesetzt werden darf, war im Anschluss wegen Lizenzverbrauchs nicht mehr verwendbar. Ich habe dann eine Business-Lizenz für 50 Sites gekauft, so dass ich sogar noch einige Blogs für weitere spinnerte Ideen aufsetzen könnte.

Mobil-Darstellung und Sonstiges

Ein Problem, mit dem ich mich in den letzten Jahren herum geschlagen habe, war die von den Lesern gewünschte Mobilgeräte-Darstellung. Das von mir für die Blogs verwendete Template TwentyTen gibt keine responsive Anzeigen für Mobilgeräte her. Es gibt in WordPress zwar Vorlagen "wie Sand am Meer", die auch ein responsives Design unterstützen. Ich habe in den letzten Jahren immer mal wieder solche Vorlagen getestet und viele Tage "verbraten".

Mobilgerätedarstellung als Speziallösung

Problem ist schlicht, dass die Designer sich verkünsteln – keine der Vorlagen passte. Die jeweiligen Blogs sollten vom Text gut lesbar sein, die Kommentare vernünftig abbilden, das alte Layout weitgehend widerspiegeln und die bestehenden Inhalte müssen sauber angezeigt werden. Daran ist es immer gescheitert – was nützt mir ein tolles TwentyTwenty-Four-Layout, welches den Blog-Editor in WordPress unterstützt, mein Layout aber verhunzt? Irgend ein TwentySixteen-Layout sah zwar in vielen Belangen gut aus, verbriet mir aber durch eine Design-Volte, wo das Artikelbild und das Datum der Veröffentlichung links neben den Anreißertext gestellt wurde, viel freien Platz. Bei anderen Designs stimmte gar nichts mehr, bei anderen Templates hakte es von der Kommentardarstellung, und, und, und.

In der Vergangenheit hatte ich eine Notlösung. Für die Mobilgerätedarstellung wurde das Template RCG Forest mit den grünen Schriften verwendet, ein Switcher-Plugin schaltete zu diesem Template um, sobald ein Mobilgerät entdeckt wurde.

Im Rahmen des Umzugprojekts hatte ich die Problematik des fehlenden responsive Designe für das Template TwentyTen erwähnt. Blog-Leser Thomas Kessler meldete sich darauf hin und bot mir eine von ihm geschriebene Erweiterung an, der TwentyTen responsive macht (nochmals danke dafür). Nach einigen Tests habe ich diese Erweiterung in den Blogs verwendet und konnte auf das Switcher-Plugin verzichten.

Ergänzung: Thomas hat in den nachfolgenden Kommentaren darauf hingewiesen, dass die Erweiterung allgemein zur Verfügung steht. Man kann sich die als Plugin realisierte Erweiterung unter Responsive Twenty Ten herunterladen. Ist in meinen Augen eine klasse Arbeit – mir hat die Erweiterung "eine Baustelle" abgeräumt.

Thomas hat mir zudem noch einige CSS-Anweisungen geschickt, um bestimmte Probleme mit Kommentarschachtelungen oder einen Bug im Kommentareditor zu korrigieren. Hier die CSS-Ergänzungen, die ich unter Design – Customizer – Zusätzliches CSS aktuell im Blog verwende:

/* Kommentare nummerieren*/
/*
li.depth-1 {
list-style-type: decimal;
display: list-item;
position: relative;
left: 10px;
bottom: 10px;
padding: 10px;
} */
/* Webseite in Kommentar raus */
.comment-form-url{
display:none;
}
/* Durchgestrichene Links normal darstellen */
.broken_link, a.broken_link {
text-decoration: underline;
}

/* generell weniger einruecken bei kommentar antworten, desktop und mobil */
.commentlist li.comment {
padding-left: 5%;
}
@media screen and (max-width: 660px) {
/* kein einruecken bei der ersten kommentar ebene bei mobil */
.commentlist > li.comment {
padding-left: 0;
}
}
/* bug fix fuer plugin simple-comment-editing */
.sce-comment-text {
width: 100%;
margin-right: 10px;
box-sizing: border-box;
}

Die beiden letzten Blöcke sind von Thomas – die ersten CSS-Anweisungen verwende ich, um ggf. Kommentare temporär durchzunummerieren (bei der Auslosung von Gewinnspielen hilfreich), das Feld "Webseite" bei Kommentaren auszublenden oder gebrochene Links nicht durchgestrichen anzeigen zu lassen.

Was ich noch erledigen muss: In der Mobildarstellung die am Seitenende angeklatschte Seitenleiste des Desktop so anpassen, dass nur noch einige relevante Einträge auf Mobilgeräten auftauchen.

Verlinkungen und Plugins

Nach der Aufsplittung des Multisite-Blogs samt Umzug der Domains blieb mir noch, die restlichen Blogs von borncity.eu auf borncity.com umzubiegen, sowie diverse Verlinkungen zu korrigieren. Hier gibt es noch kleinere Baustellen, da ich die Startseite als statisch aufgesetzt habe.

Zudem stehen noch kleinere Anpassungen am Seitendesign und in Richtung "Sicherheit, SEO-Kompatibilität" auf der Agenda.

Neue Blogging-Umgebung

Hinter den Kulissen gibt es noch einige weitere kleinere Änderungen. So habe ich ein Plugin, welches SSL bzw. https im Blog erzwingt, rauswerfen können, weil ich im Webpaket SSL erzwingen für die Domain vorgeben kann. Nebeneffekt: Ich kann den Windows Live Writer nicht mehr zum Bloggen verwenden.

Das letztgenannte Problem habe ich für mich dergestalt gelöst, indem ich den WordPress Gutenberg-Blog-Editor deaktiviert habe. Dadurch wird der klassische Editor erzwungen. Dieser wurde mit dem Plugin Advanced Editor Tools aufgebohrt (ich kann Bilder komfortabel einbinden und habe eine Suchen & Ersetzen-Funktion). Hinzu kommt ein Plugin, welches mir die Zeichenzahl eines Beitrags anzeigt (brauche ich für die VGWort) sowie ein Plugin Post Snippets, mit dem ich meine im Windows Live Writer gewohnten Code-Blöcke in einem Beitrag einfügen kann.

Mit diesen Maßnahmen kann ich komfortabel online im Browser per WordPress-Adminbereich im Classic-Editor bloggen. Die Rechtschreibprüfung übernimmt der Browser – und ich kann auch unter Linux bloggen (heute testweise probiert).

WordFence ist raus

Was ist noch anzumerken? Ich habe einige Plugins zur Spam-Abwehr sowie zur Absicherung der Blogs laufen. Das Plugin WordFence mit Web-Firewall und Überwachung auf Aktualisierungen oder Veränderungen an den Blog-Dateien habe ich rausgeworfen. Warum? Einmal gab es beim "ersten Schuss" meines Umzugsversuchs des IT-Blogs ja das Problem, dass die Blogs auf den alten "HostEurope"-Webspace zeigten. Der all-inkl-Supporter meinte: Da sind WordPress-Reste im Dateisystem, werfen Sie das Plugin raus, exportieren Sie neu und setzen Sie alles neu auf. Andernfalls wird das nie was. Auch Thomas gab mir den Ratschlag "WordFence vor dem Umzug rauszuwerfen".

Ich hätte am neuen Standort WordFence wieder mit rein nehmen können, habe mich aber aktuell aus mehreren Gründen dagegen entschieden. WordFence ist zwar für die meisten Nutzer "narrensicher", hat mir aber einige Nachteile beschert:

• Das Plugin greift in die .htaccess ein und setzt dort Regeln, die dann Kollateralschäden mit anderen Plugins verursachen können. Beim alten HostEurope-Auftritt hatte ich immer eine funktionsfähige Notfall .htaccess auf der Festplatte, um diese bei streikendem Blog per FTP schnell hochzuladen. Ist mir sicher ein halbes Dutzend mal passiert, dass der Blog nach Plugin-Updates oder Änderungen nicht mehr aufrufbar war.
• WordFence nervte mich immer häufiger mit Fehlalarmen und monierte infizierte WordPress-Dateien. Es handelte sich dabei aber um Cache-Inhalte, wo Blog-Beiträge von mir Texte wie "hacked by" enthielten, die von WordFence aber als gehackte Dateien interpretiert wurden. Auch wurden mir oft Plugins als manipuliert angezeigt, wo eine Kontrolle dann  ergab, dass der Plugin-Autor im PHP-Code nur die Version geändert hatte, dies von WordFence aber nicht registriert wurde.
• Zudem hatte ich irgendwo in einem Test gelesen, dass WordFence einige Datenbankverbindungen offen hält, was zu Ressourcen-Problemen führen kann.

Auf Facebook war mir vor Jahren bereits ein Thread von Daniel Ruf untergekommen, der argumentiert, bei Kunden aus Performance-Gründen kein WordFence mehr einzusetzen. Vielmehr setzt er auf die Ninja-Firewall sowie weitere Ninja-Tools (so lasse ich deren Virenscanner sporadisch mitlaufen). Daniel Ruf hat eine Konfigurationsanleitung für Ninja Firewall veröffentlicht, an dem ich mich für die Konfigurierung orientiert habe. Ich werde aber einige Event-Benachrichtigungen per E-Mail abdrehen, da die Mails beim aktualisieren von Plugins etc. bei mehreren Blogs nerven.

Was noch?

Aktuell fahre ich die Blogs alle ohne Caching-Plugin – lediglich ein OP-Cache wurde vom Hoster auf dem Webserver standardmäßig eingeschaltet. Ngix-Cache gibt es nicht, da kein ngix-Server vom Hoster verwendet wird.

Die Blogs laufen aktuell smoother als beim alten Hoster. Ich habe allerdings gelegentlich einige "Gedenksekunden" im Frontend bemerkt. Hier teilte mir der all-inkl-Support mit, das ich wohl das FPM-Limit erreiche und legte mir eine .log-Datei für lange laufende Scripte an.

Dort habe ich gesehen, dass das Plugin Broken Link Checker diese Aussetzer mutmaßlich verursacht, weil die Prüfung auf kaputte Links sehr Ressourcen-intensiv ist. Nachdem ich gebrochene Links korrigiert habe, ist das Plugin deaktiviert und wird nur noch sporadisch laufen.

Die Statistiken für Besucher und Seitenabrufe werden übrigens durch Plugins lokal gehalten. Auf die Vorschaltung von CloudFlare, wie mal von Lesern diskutiert, möchte ich verzichten bzw. werde das ohne Not nicht mit rein nehmen.

Ich möchte in den kommenden Tagen und Wochen noch einige Details ändern, einige kleine Änderungen vornehmen, noch einige Sicherheitsergänzungen und -tests vornehmen und hoffen, dass die Blogs dann "Strich laufen". Unter dem Strich sind beim Umzug durch das Neuaufsetzen der Blogs Dateileichen entfernt worden. Auch die Datenbanken habe ich von Leichen, die Plugins hinterlassen haben, bereinigt.

Die neue Struktur ermöglicht mir auch, progressiver mit einzelnen Blogs umzugehen – eine Fehlkonfigurierung betrifft nur noch einen Blog. Zudem habe ich nun die Chance, bestimmte Blogs mittelfristig auf borncity.eu zu verschieben. Und 10 Euro/Monat günstiger als bei HostEurope ist das Ganze bei all-inkl.com momentan auch geworden. Dass deren Support um Klassen besser als bei HostEurope ist, hatte ich ja bereits in Teil 1 erwähnt.

Damit beende ich den Bericht aus dem Maschinenraum. Die Schilderungen verdeutlichen, dass es nicht mal eben zwei Mausklicks benötigte, um die Blogs umzuziehen. Sondern es wurden im Maschinenraum einige Umbaumaßnahmen vorgenommen. Persönlich habe ich über diesen Umzug einiges gelernt und habe hoffentlich einige Altlasten durch den Umbau samt Bereinigung der Datenbank um Leichen, verursacht durch Plugins, beseitigen können.

Artikelreihe:
Blog-Umzug: Insights aus dem Maschinenraum – Teil 1
Blog-Umzug: Insights aus dem Maschinenraum – Teil 2