Ich muss immer noch von der Migration im April von vier Websites (2x WordPress & 2x Joomla! nach 1x WordPress) einige meiner Beitragsbilder per Hand anpassen, weil die wüst durcheinander gewürfelt wurden und sinngemäß Artikel 123 das Beitragsbild von Artikel 642 hatte. Viele Bilder in den Artikeln waren auch verschwunden, bzw. in der Mediathek falsch zugewiesen. Wollte ich ein Bild in einem Artikel bearbeiten, erschien statt des im Front- und Backend dargestellte Bild ein völlig anderes, das weder in der Beschreibung, noch im Dateinamen auch nur irgendwas mit dem originalen Bild zu tun hatte.
Auch wenn ich in der Suche den Dateinamen des originalen Bildes eingab, erschien das falsche Bild an erster Stelle und dann erst das korrekte Bild. Unnötig zu erwähnen, dass die URL, die im Artikel auf das Bild verweist vollkommen korrekt ist. Ich vermute, dass die intelligente WordPress URL-Autokorrektur etwas damit zu tun hat. Solange das aber nur das Backend betrifft, soll es mir egal sein.
Unverhofft kommt oft
Meine Hoster bisher
Seit 1998 habe ich eine Homepage, hessburg.de. Ich glaube, die war damals noch bei 1&1 gehostet. Runde neun Jahre lang. Nebenher betrieb ich die Website unseres LAN-Clans, die bei Greatnet, gehostet war. Guter Laden. Da stand auch unser eigener Server (wortwörtlich: das war unser Gerät) im Rechenzentrum.
Dann hatte ich mit meinem Bruder zusammen für wenige Jahre einen dedizierten Webserver bei Strato am Start, den ich betreuen musste, weil ich mich mit Linux leidlich auskannte. Aber die Webspace-Pakete wurden immer leistungsfähiger, sodass die Notwendigkeit für einen eigenen Server wegfiel.
Durch die HomeCon kannte ich jemanden, der selber eine Hosting-Firma mit eigenem Rechenzentrum betreibt. Seine Preise waren anfangs noch okay. Ebenso die Leistung. Aber um im Wettbewerb bestehen zu können, wurde die Webspaceschiene für den gemeinen Pöbel eingestampft und nur noch „professinelle“ Tarife angeboten. Davon nahm ich den kleinsten Tarif, der aber preislich bereits nicht mehr mit den Mitbewerbern mithalten konnte.
Anfangs war ich noch sehr zufrieden, aber mit der Zeit wurde es immer „professioneller“: Support außerhalb der Bürozeiten sollte Geld kosten. Nun gut, wozu braucht man schon Support?
Support braucht kein Mensch!
Nun, den braucht man, wenn durch ein Backup der Webspace von (lächerlichen) 20 GB vollläuft. Was? Dann lösche ich eben die Backups? Jo, gute Idee – wenn der Hoster mir nicht den kompletten(!) Zugriff gesperrt hätte. Nicht einmal FTP geht mehr, ebenso wenig der Plex-Dateimanager. Dolle Show, denn wann passiert das? Am Wochenende! Kein Support. Und auch keine hessburg.de-Emails mehr, denn auch die wurden gesperrt. Ja, es wäre ihr Fehler, da wäre etwas falsch beim Überlaufen des Webspaces konfiguriert gewesen, aber das sei nun geändert worden. Okay, alles nur Menschen, kann passieren.
Von Joomla! zu WordPress
Über letzte Pfingsten migrierte ich
hessburg.de
tote-pixel.de
tellerrandforschung.de
hausblog.hessburg.de
auf WordPress unter dieser URL
die Kommentare von JComments
Blauäugig kopierte ich auch die Datenbank und die Files von Matomo, welches wieder unter der gleichen Subdomain an den Start ging. Flugs das Config-File angepasst und schon war Matomo wieder am Start. Nur… das Backend wurde immer langsamer und langsamer. Ein Blick auf die Datenbank offenbarte Düsteres: Die DB war mittlerweile auf einen zweistelligen GB-Betrag angeschwollen!
Mist!
Ohne SSH-Zugriff kann ich Matomo nicht stoppen – das Backend reagierte mittlerweile überhaupt nicht mehr! Also ein Ticket geöffnet. Keine Antwort, ist ja klar. Der Pöbel bekommt keinen Support. Auch scheint es keine Überwachung seitens des Hosters zu geben, die CPU-Leistung musste nun schon Stunden für meinen Webspace am Limit gewesen sein.
Nun wurde auch mein Webspace immer langsamer und langsamer. Ich löschte einfach Matomo und versuchte dasselbe mit der Datenbank, in der Hoffnung, dass das Amok laufende Script mit einer Fehlermeldung abbrechen würde. Das hat am Ende auch funktioniert, nur brauchte das über 24 Stunden dazu. Krass. Gut, das ist nicht schön, aber auch nur bedingt dem Hoste anzulasten, Stichwort: Monitoring.
Am gleichen langen Wochenende richtete ich ein Backup ein. Lokal und in der Cloud. Dabei machte ich einen Fehler: „Halte drei Backups vorrätig“. Inkrementelle Backups kennt Updraft offenbar nicht. Bei mittlerweile knapp 6 GB, die die Website durch die Fotolastigkeit wiegt, hätte das ja eigentlich gepasst. Ja, neee, die E-Mail-Knoten belasten den Webspace ebenfalls, sodass am Ende 23 GB Webspace belegt waren.
Monitoring funktioniert doch!
Das Monitoring des Hoster griff hier, wo es bei der CPU-Last und der vielen GB-großen Datenbank noch versagte. Ich bekam um 03:00 Uhr morgens eine Mail mit der Warnung, dass der Webspace bald voll wäre. Um 08:00 Uhr hatte ich schon wieder keinerlei Zugriff auf meinen Account mehr. Von wegen der Fehler wäre gefixt. Sollte das eine Art Erziehungsmaßnahme oder Werbung für den kostenpflichtigen Support sein? Hat nicht funktioniert!
Alfahosting? Echt jetzt?
So das reichte mir komplett! Da ich für einen Bekannten die Website seines Hotels erstellt hatte, kannte ich Alfahosting. Die haben einen 24h-Support und sind auch bis in die Abendstunden telefonisch erreichbar. Bei denen alles im Preis inbegriffen. Ja, das kann ein kleiner Hoster nicht leisten, das ist mir klar. Anyway, dann sollte eben solche Monitoring-Fehler erst recht nicht passieren.
Den Support bei Alfahosting musste ich für den Bekannten in Anspruch nehmen, weil sich (vereinfacht gesagt) bereits viele an der Site vergangen hatten und unzählige Domains und E-Mail-Konten registriert waren. Dazu kam bei Alfa ein ganz schreckliches Confixx-Backend, das aussah, als hätte es sich seit Mitte der 1990er nicht weiterentwickelt. Absolut unbenutzbar und überhaupt nicht für eine Konfiguration mit vielen Domains und Konten zu gebrauchen. Welche Files und welche Postfächer zu welcher Domain oder Adresse gehörten, kann man nur sehr schwer nachvollziehen.
Das Sahnehäubchen war, dass deren Serverzertifikat nur für eine Domain galt, let’s encrypt kostenpflichtig und das Backend auch noch schrecklich langsam war. Auch die Website war nicht so schnell wie bei meinem bisherigen Hoster, muss man sagen. Gerade die Reaktionszeit war eher Durchschnitt.
Möchtest Du mich unterstützen?
Wenn Du selber auf der Suche nach einem schnellen Hoster mit gutem Support bist, der nicht die Welt kostet, dann kann Du gerne diesen Link benutzen: Alfahosting.de (Werbung). Dadurch bekomme ich eine kleine Provision, aber für Dich wird sich an den günstigen Tarifen nichts ändern. Du zahlst deswegen keinen Cent mehr, als wenn Du direkt auf Alfahosting gehen würdest. Danke!
Hallo Alfahosting!
Aber die neuen Tarife liefen auf neuen Servern und mit einem modifizierten Plesk. Die alten sollte im Laufe des Jahres dahin migriert werden. Mit vier de-Domains, 150 GB Webspace, SSH-Zugang, let’s encrypt und ner Menge anderer Leistungen, die ich nicht unbedingt benötige, sollte mich der Spaß nur 6,99 im Monat kosten. Das ist etwa die Hälfte von dem, was ich bisher zahlte. Dann wäre die Site eben langsamer, mir egal. Ich buchte und stellte für die Domains einen Umzugsantrag.
Die Domains waren schneller neu registriert, als ich ein Backup im Backend hätte durchführen können. Naja, ging ja eh nicht, da ich eh keinen Zugriff mehr hatte. Früher dauert ein Domaintransfer etwas länger als zwei Minuten. So hatte ich auch nach der Freischaltung durch den alten Support keinen Zugriff mehr auf das Backend der alten Installation, was sich noch rächen sollte.
BTW: Der Support meldet sich erst einige Stunden später. Wäre deren Schuld, der Account hätte nicht gesperrt sein sollen. Kennt man schon.
Wo Licht, da Schatten. Einiges gefiel mir im Kundenbereich des alten Hosters besser, aber das ist wohl Gewohnheit und dafür reißt der SSH-Zugriff und die Cron-Jobs echt vieles wieder raus.
Weiße Seite!
Jedes CMS wird bei einem PHP-Fehler eine weiße Seite ausgeben, damit der Webserver nicht angreifbar ist. Auch ich bekam eine weiße Seite präsentiert, nachdem alles umgezogen war. Lange Rede, kurzer Sinn, ich führte die üblichen Schritte für solch eine Fehlersuche durch:
Plugin-Verzeichnis umbenennen (auch in der SQL-DB alle aktiven Plugins gelöscht)
Die wpconfig auf Debug gestellt, aber nichts wurde ausgegeben
Wordfence erstellte htaccess-Rules, also die Datei stumpf gelöscht
Auch die WF-Datei User.ini gelöscht.
Das half alles nichts!
Erst als ich alle Tabellen in der DB löschte, die Wordfence angelegt hatte, funktionierte der Zugriff über das Backend wieder!
Das Frontend blieb immer noch weiß.
Das erneute Setzen der Permalinks im WP-Backend erweckte die Site wieder zum Leben
Backups!
Warum habe ich keine xml-Datei vom WP-Migrationstool durchführen lassen? Solange das Problem mit den falsch zugewiesenen Bildern nicht gefixt ist, wollte ich den Umzug nicht automatisiert durchführen lassen. Zudem wäre auch das ein Spaß geworden, denn dann hätte ich bei Alfa eine deren Kunden-Subdomain als Ziel benutzen müssen.
Warum habe ich kein Backup mit deaktivierten Plugins durchgeführt? Weil ich zu schnell die Domains auf den neuen Hoste registrierte und daher keinen Zugriff mehr auf das WP-Backend hatte.
Kann ich eine Art Backups zu machen uneingeschränkt empfehlen? Ja, die Methode per Hand!
Unter phpMyAdmin die Datenbank dumpen und die Files über SSH oder den Plesk-Dateimanager (nicht WebFTP, der rennt in ein Timeout!) komprimieren und herunterladen.
So hatte ich auch am Abend vor der Sperrung des Accounts frische Backups der Präsenzen gezogen. Auch das bwog mich zu einem sofortigen Wechsel des Hosters.
Speed. Ich. Bin. Speed!
Tja, bei der Migration setzte ich auf ein schlankes Theme, GeneratedPress, das auch einen wirklich tollen Support hat, der selbst für die Free-Version auch alle CSS-Container veröffentlicht hat, sodass man das Theme leicht anpassen kann. Dazu kommt der neue, pfeilschnelle Webspace bei Alfa, der die Site enorm beschleunigte. Am Ende hatte meine Site statt der bisher maximal möglichen 53 Prozentpunkte bei Googles Pagespeed auf einmal 88 %! Noch ein Cache-Plugin, einen Script-Komprimierer, einen Bildoptimierer, einen Webp-Bilder-Konvertierer und -auslieferer sowie einen Script-Blocker für die Homepage und… *bämm* 96 % Speeeeeed!
Vorgehensweise
Eigentlich ist mir SEO total egal, ich verdiene kein Geld mit der Site, ganz im Gegenteil. Aber schnell sollte meine Site schon sein. Als ich dann die 88 % sah, griff die Gamification bei mir voll. Der grüne Bereich fängt bei 90 % an. Den wollte ich haben! 92 % waren durch Webp-Images erreicht, 94 % durch Caching und LazyLoad. Die letzten 2 % durch das Komprimieren der Scripte und das deaktivieren von einigen für die Homepage unnötigen Scripten wie Back-to-Top und der Lightbox, die nur in Artikel zum Tragen kommen.
Warum gebe ich nun auf? 100 % wären doch geil! Nun ich greift die 90-10-Regel. 90% der Arbeit sind die 10 % der Zeit zu schaffen. Für die restlichen 10% der Arbeit braucht man 90% der Zeit.
Mir ist klar, dass durch den Einsatz von HTML5 und meinen schon ganz schön umfangreichen CSS3-Änderungen an dem Template – und nicht zuletzt durch die heftige Grafiklastigkeit der Site, eine Erhöhung des Scores einfach ziemlich schwierig würde.
Ausserdem ahne ich, dass durch die Migration der alten Tarife auf die neuen Server bei Alfa, meine Site bald wieder unter 90 % fallen wird. Ist so. Wenn man irgendwo Neukunde wird, ist der Webserver, der die Site hostet, nach einigen Monaten so voll, dass es eben lansgamer wird. Oder man hat das „Glück“, einer der letzten Kunden zu sein, die auf den Server kommen und so erst gar nicht weiß, was möglich wäre. :-)
Tipps
Eines kann ich Euch aber schon so mit auf den Weg geben: Nehmt lieber einzelne kleine Plugins, statt dieser All-in-One-Schlangenöltools, die zwar viele Sterne und Installationen haben, die Euch aber die Optimierung der Site durch deren Komplexität und die Verlockung, einfach mal jede Option zu aktivieren, nur schwerer machen. Die meisten interessanten Funktionen sind bei denen sowieso Premium.
Klar, man könnte das Plugin auch kaufen, aber woher willst Du wissen, ob sich das lohnt? Meine Erfahrung ist, dass sich einige der Schlangenöltools, die Wunder versprechen, auf die Leistung tatsächlich negativ auswirken. So verlor ich zum Beispiel fast 20 % Leistung durch eines dieser gehypten Tools. Das war sogar bei der Ladezeit in der Realität zu spüren.
Also lieber dedizierte Plugins für einen gewünschten Teilbereich benutzen, dessen Funktion dann kostenlos ist und für dessen Premium-Funktionen wiederrum ein anders dediziertes Tool. So kann man nach und nach sehen, welche „Optimierungen“ sich positiv auf die Leistung auswirken.
Schlangenöle
Freunde, es ist mir klar, dass Ihr total auf solche automagischen Tools abfahrt, weil Euch unter Windows immer versprochen wird, dass Ihr danach achhundertdrölfzig Millionen Pronzent schneller unterwegs seid, aber das ist Bullshit. Gerde im Bereich der Betriebssyteme erkauft Ihr Euch einen minimalen Geschwindigkeitsvorteil durch einen Funktionsverlust, der unter Windows mit dem nächsten Update wieder rückgängig gemacht wird.
Aber klar, eine tolle Beschäftigungsmaßnahme ist die Optimierung von Windows, wenn man nicht damit arbeiten will, sondern das OS selber als eine Art Hobby ansieht. Produktivität sieht anders aus.
Will sagen: Wenn Euch Eure Website unter WordPress schnell genug erscheint, dann lass Euch nicht vom Google Pagespeed irre machen. Ohne Wechsel des Hosters werdet Ihr niemals von 50 % auf 100 % kommen, nicht mal mit einer „Hello World“ Website. Wobei wir bei dem Thema sind: SEO-Optimierung bringt nichts, wenn Ihr keine relevanten Inhalte habt. Steckt die Zeit lieber in Content als in Optimierungsversuche, das bringt mehr.
Vielleicht mache ich mal einen Artikel über die verwendeten Plugins – vor allem, warum ich die verwende. Oder eine Artikelserie?
