Cartoons, Comics, Illustrationen, Doodles und Auftragsarbeiten

WordPress Providerwechsel zu all-inkl.com

Als ALL-INKL.COM Anfang des Jahres ein tolles Angebot präsentierte – die ersten 6 Monate frei, dann 9,95€ inklusive Traffic-Flat – konnte ich es nicht abschlagen.

Mit meinem eigentlichen Provider fc-hosting.de häuften sich die Probleme nach deren Hardware-Umzug. Und irgendwie betraf es immer meinen Server. Dadurch dass meine Website sehr grafiklastig geworden ist, habe ich auch immer mit Bangen auf meinen geringes Traffic-Kontingent geschaut.

So spielte ich schon seit längerem mit dem Gedanken w3filter.de über ALL-INKL.COM laufen zu lassen. Aber ich scheute den Aufwand, es gibt eigentlich so gut wie nie, einen Umzug der komplett ohne Probleme vonstatten geht.

Nachdem Google mit Page Speed Online die einfache Möglichkeit geschaffen hat, ohne jeden Aufwand die Geschwindigkeit seines Blogs zu testen dachte ich mir: „ok, mal schauen wo ich stehe.“

Ein Wert von 49 ist schon schockierend. Zum Vergleich, mein anderer Blog kinder-hoertest.de hat einen PageSpeed-Wert von 81!! Den Test kann man übrigens mit jedem – auch fremden – Blog durchführen.

Wir wissen ja inzwischen alle, dass für Google der Page-Speed-Wert einen nicht unbedeutenden Einfluss auf die Bewertung hat.

(Achtung: Update zum Problem chown und FTP, ist gelöst! Endlich sorgenfrei :) + Update:  offizielle Antwort zur Lösung)

ALL-INKL.COM - Webhosting Server Hosting Domain Provider

Ein kleiner Erfahrungsaustausch mit Markus (CowboyOfBottrop.de) hat mich dann dazu bewegt, dann doch möglichst schnell den Umzug zu wagen.

Ganz wichtig: Ich konnte so gut wie alles in Ruhe vorbereiten und habe erst dann als finalen Akt den Nameserver gewechselt.

Einige Schritte zum erfolgreichen Umzug

Als allererstes stand die Übertragung des kompletten Ordners der W3Filter-WordPress-Installation von Provider A zu Provider B.

  • Dazu habe ich mit den angebotenen Bordmitteln des FTP-Dateimanagers von fc-hosting.de ein Archiv meiner WordPress-Installation erzeugt, also den Server die Arbeit machen lassen und nicht lokal auf meinem Rechner. Dieses Archiv habe ich dann downgeloadet.
  • In der KAS-Oberfläche von ALL-INKL.COM habe ich erst mit dem internen Dateimanager (FTP->Aktion) ein passendes Verzeichnis erzeugt, in dem ich später das zuvor erstellte Archiv entpacken würde.
  • Dann konnte ich die Domain w3filter.de anlegen (Domain->Neue Domain anlegen) und direkt mit dem neu angelegten Verzeichnis verbinden.
  • Als nächstes Stand mit Hilfe des internen Dateimanagers die Übertragung und Entpackung des zuvor erzeugten Archivs in das neu angelegte Verzeichnis.

Als nächstes kam die Vorbereitung der Daten und der Datenbank (Datenbank->Neue Datenbank anlegen).

  • Einen Einfluss auf den Datenbanknamen hat man selten, so auch nicht bei ALL-INKL.COM. Also habe ich einfach auf ein starkes Passwort geachtet.
  • Jetzt ist ein guter Zeitpunkt um die Änderungen des Datenbanknamens, des Datenbanknutzers und des Passwortes in der wp-config.php vorzunehmen.
  • Den Tabellennamen und den Tabellenpräfix habe ich übernommen. Wäre ja dumm, wenn nicht 😉
  • Langsam wird es spannend, jetzt kommt nämlich der Export der aktiven Datenbank. Da kann man nicht viel falsch machen. SQL, alle Tabellen und im Zip-Format einstellen und ok.
  • Was jetzt kommt, ist der eigentliche Dreh- und Angelpunkt ob später alles fehlerlos läuft oder auch nicht. Natürlich könnte man später unter der Admin-Oberfläche den neuen direkten Pfad einstellen und dann unter PhpMyAdmin auch noch eventuell verborgene Pfade anpassen, aber warum den Ärger. Viel einfacher ist es in der SQL-Datei direkt alle Änderungen per Suchen&Ersetzen durchzuführen. So kann man ganz einfach auch wirklich ALLE Vorkommnisse der direkten Pfade ändern.
  • Nachdem ich die Pfade abgeändert und die SQL-Datei wieder als Zip-Datei gepackt habe, konnte ich diese dann auch problemlos in der neu erstellten Datenbank bei ALL-INKL.COM importieren.

Die Umstellung der Namerserver

  • Was dann noch blieb war der Eintrag des neuen Nameservers bei meinem Domain-Robot. Hatte ich schon erwähnt, dass ich ein Agenturpaket bei fc-hosting.de besitze? Deswegen habe ich selber Zugriff auf alle meine Domains.Das vereinfacht den Umzug ungemein :)
  • So, eigentlich ist die Vorarbeit beendet. Jetzt bleibt nur noch Abwarten. Je nachdem kann es bis zu 24 Stunden dauern bis die Umstellung durchweg registriert worden ist. Im Falle von w3filter.de waren es 12 Stunden.

Letzte Arbeiten an der laufenden Website

  • Die gute Nachricht war, dass sowohl im Backend wie im Frontend alles perfekt lief. Einzig das Plugin Redirection hatte Probleme mit der .htaccess. Der Grund dafür ist eine Eigenheit bei All-INKL.COM mit den Besitzrechten der Verzeichnisse und Dateien.
  • Entweder ich kann über FTP auf die Daten zugreifen ODER aber über PHP, also über WordPress. Beides gleichzeitig geht nicht. Das ist ärgerlich. Abhilfe schafft da eine partielle Änderung der Besitzrechte.
  • Bei ALL-INKL.COM kann man die Besitzrechte (CHMOD) von Verzeichnissen (auch rekursiv) und von Dateien entweder auf den jeweiligen FTP-Nutzer einstellen (Nutzername) oder aber auf den PHP-User (WWW-DATA) setzen.

  • Das Hauptverzeichnis von w3filter.de und die Datei .htaccess wurden per CHMOD auf PHP-User (WWW-DATA) gesetzt. Damit konnte Redirection direkt auf die .htaccess zugreifen.
  • Wofür das ganze? Nun, damit die Eingabe von http://w3filter.de auf http://www.w3filte.de umgeleitet wird.

Und noch ein Memory-Fehler

  • Wars das? Nicht ganz. Als ich einen Artikel (diesen hier) erstellen wollte kam die Fehlermeldung, dass nicht genügend Speicher zur Verfügung stehen würde. Was sollte das denn schon wieder?
  • Dank des Beitrages von Stefan (Beedy.de) und der Installation von WP-System-Health konnte ich den Grund der Fehlermeldung ausfindig machen. Mickrige 64MB RAM hatte WordPress zur Verfügung.
  • Ein ergänzender Eintrag in der .htaccess Datei (temporäres Zurückstellen der Besitzrechte auf den FTP-Nutzer für die Dauer des Editierens) um den Eintrag:
    • php_value memory_limit 256M
  • und einer Ergänzung in der wp-config.php um diese u.a. Zeile (so weit oben wie möglich) beendete erfolgreich den Umzug nach ALL-INKL.COM. Endlich!
    • /** WordPress zugewiesenen Speicher definieren */
      define('WP_MEMORY_LIMIT', 256);

Was ist jetzt mit dem Page Speed?

Und die gute Nachricht zum Schluss, mein Page-Speed schnellte auf satte 79 hoch.

Mit einem weniger fordernden Theme und vielleicht ein paar Plugins weniger könnte ich das bestimmt noch weiter pushen, aber so ist erst einmal gut :)

Noch Fragen?

Falls noch ein paar Fragen auftauchen sollten, weil ich vielleicht nicht auf jedes klitzekleine Detail eingegangen bin, dann immer her damit.

Lösung zu chown und FTP

Dieses ganze herum gefummele mit dem Setzen einiger Verzeichnisse und Dateien entweder als FTP-Nutzer oder als www-data ging mir mächtigst auf den Keks.

Vor allem bei der Installation von Plugins konnte es zu Problemen kommen, einige ließen sich anstandslos aktualisieren, andere muckten auf, furchtbar.

Hier ist nun die Lösung, die mich endlich befreit aufatmen lässt und mich ALL-INKL.COM nun wirklich komplett empfehlen lässt.

In der Datei .htaccess fügt ihr folgenden Eintrag ein:

  • AddHandler php-fastcgi .php

Das wars! Mehr muss nicht getan werden. Ab jetzt kann ich sowohl als FTP-Nutzer alles bewerkstelligen und unter WordPress kann ich nun auch munter Plugins aktualisieren.

Mein Dank hierfür geht an Hannes Schurig, obwohl er eine leicht andere Syntax hat, aber auch aufzeigt, wie diese Freigabe auf bestimmte Dateien beschränkt werden kann:

  • AddHandler php5-cgi .php

Such euch halt was aus 😉

Update zum Thema Addhandler:

Nachdem ich  nach der Umstellung ein paar Fehler bei einigen Widgets hatte, habe ich den Support von ALL-INKL.COM bemüht. Die Lösung war ganz einfach.

Ein neuer Addhandler benötigt das Löschen der alten Session-Cookies, sowie das Leeren des Browser-Caches und am besten einen Browser-Restart.

In diesem Zusammenhang habe ich direkt angefragt, welche der beiden Addhandler-Varianten zu bevorzugen wäre.

Die Antwort:

die Anweisung

AddHandler php5-cgi .php

ist die korrekte. Die andere ist überholt.

18 Kommentare

  1. Puh. Ich war gerade leicht alarmiert und habe den (mir bisher unbekannten) PageSpeed Test von Google ausprobiert.

    Ich bin beruhigt, denn die meisten meiner Blogs rangieren zwischen 75 und 90 von 100 Punkten :-)

    Sämtliche Projekte sind übrigens bei united-domains gehostet und das seit knapp 3,5 Jahren. Mit 1 Euro pro Monat pro Domain für mich unschlagbar.

  2. Das ist allerdings günstig. Inklusive Traffic-Flat?
    Bei mir ist glaube ich das Theme etwas anspruchsvoll, aber solange es zwischen 70 und 100 ist passt das erst einmal. Einige Frontend-Plugins sind auch etwas unglücklich 😉

  3. Jau. Traffic ist mittlerweile inklusive.

    Der Webspace allerdings nicht, der kostet nochmals 40 Euro im Jahr, zu meiner positiven Überraschung wurde vor knapp einem Jahr sogar der Platz verdoppelt. Einfach so, ohne großes Tamtam :-)

    Ich vermute, dass es ohnehin noch etwas dauern wird, bis Google seine Idee vom Page Speed (als Ranking-Faktor) zu 100% in die Tat umsetzt.

  4. 40 Euro im Jahr und Traffic Flat, das klingt wirklich gut. Da müsste man schon genauer hinschauen, um die Unterschiede zwischen den Tarifen festzustellen. Aber ich bin momentan zufrieden und solange ich keinen Ärger habe ist alles gut 😉

    Ich kann mir allerdings nicht vorstellen, dass Google nur so was ankündigt und den PageSpeed dann nicht zeitnah einfließen lässt.

    Ich kenne mich da auch nicht so aus, Hauptsache ich bin weg von der 40-50 Speed. Der Rest wird sich zeigen.

  5. PageSpeed wird sicherlich einer der Hauptfaktoren werden – und ich hoffe natürlich, dass das bald passiert…

    Übrigens will ich dich bzgl. Hosting und Co. nicht zum Wechseln bewegen. Wenn alles läuft, ist es ja prima.

    Außerdem ist mir heute bereits aufgefallen, dass deine Seite subjektiv gesehen flotter lädt und scrollt. Ich war ja jetzt schon ein paarmal hier, es wirkt nun flüssiger :-)

    Ich hoffe, ich bilde mir das nicht nur ein.

  6. Nee, die Sorge habe ich nicht. Das Gras ist ja sowieso überall grüner, böse Falle das 😉 Der Grund für meinen Wechsel war ja Traffic-Flat, Zugriff auf DNS (so kann ich selber ganz einfach meine Domains umziehen), der gute Rufe bei Bloggern und der deutliche Geschwindigkeitszuwachs.

    Wie du gesehen hast, arbeite ich ja viel mit eigenen Bildern und Flickr war einfach zu langsam zum Verknüpfen, daher war mir gerade Trafficflat wichtig.

    Ist meine Website flotter? Cool, vielleicht sind jetzt auch alle Seiten im Quickcache drinne. Vielleicht hast du aber auch nur neu gebootet, dass passiert mir manchmal mit den vielen offenen Tabs 😉

  7. Glückwunsch zum erfolgreichen Umzug! :-)

    Ich bin ja auch vor nicht allzu langer Zeit mit einigen Webseiten von einem eigenen Rootserver zu All-Inkl.com gezogen, Gott sei Dank hatte ich da nicht so viele Probleme! :-)

    Aber ich hatte den Umzug in mehreren Schritten durchgeführt, vielleicht hat mir das etwas Arbeit erspart.

    Ich muss Jonathan Recht geben, die Seite lädt deutlich schneller. Und ich denke mal, da hat die Cachingfunktion einen großen Anteil dran, zumal die gerade bei All-Inkl richtig gut greifen.

    Mal ein kleiner Tipp, was zwar nicht unbedingt mit Pagespeed zu tun hat, aber mit Fehlern im Quellcode. Ich habe gerade mal aus Spaß mit dem Plugin HTML Validator Deinen Quellcode angesehen, da sind einige Fehler drin, die zwar den Seitenaufbau nicht beschleunigen, aber unter Umständen zu Fehlern in den Browsern führen können.

    Kannst Dir ja mal anschauen, falls Dir zu langweilig wird! :-)

  8. Meinst du echt, dass mir momentan langweilig wird? 😉

    Der Umzug an sich ist ja ziemlich reibungslos und gemütlich verlaufen, die Ergänzung des Addhandlers ist ja etwas, dass nur allinklcom betrifft, aber auch das ist ja geregelt. Je nach Provider sind halt unterschiedliche Einstellungen üblich.

    An die Fehler werde ich mich aber sicherlich mal begeben. Man hätte zwar hoffen können, dass die Pluginschreiber in der Lage sein sollten HTML-Konform zu schreiben, aber was solls.

    Erst mal muss ich jetzt schauen, warum der Visualmode spinnt. Bis vor dem Serverproblem eben (durch ein falsches Skript auf dem Shared server oder Spambots, werde ich noch checken.) lief alles tadellos.

    Ein Blog ist wie ein Häusle, immer was zu tun 😉

  9. War auch eher ironisch gemeint! :-)

    Was mich wundert, dass Du solche Probleme hattest mit dem Addhandler. Ist schon seltsam, wie unterschiedlich die Wege verlaufen können, ich persönlich hatte damit keinerlei Probleme bei meinem Umzug.

    Das mit dem visuellen Modus ist schon seltsam. Irgendwelche Updates gemacht heute? Neue Plugins?

    Und ja, mit einem Blog wird es einem nie langweilig! 😀

  10. War schon klar, keinem Blogger wird je langweilig werden lol

    Wenn du mal googlest wärst du erstaunt, wie viele Blogger bei allinklcom genau damit Probleme haben, also gar nicht wissen, was man un muss, damit man sowohl als FTP-User als auch unter WordPress überall zugreifen kann.
    Bei meinem alten Provider war das gar nicht nötig.

    Nein, habe nichts installiert. Mit dem Timeout fingen die Probleme an. Vielleicht wurde versucht den Artikel im ungünstigsten Augenblick zu speichern. Ich werde morgen oder so einen neuen Beitrag schreiben und dann mal sehen.

  11. Ich mach mir mal Gedanken, habe eine Pagespeed von 31.

  12. 31!!! Wie geht denn so etwas? Selbst bei meinem alten und recht langsamen Provider hatte ich über 44.

    Ist das neu so schlecht oder hast du etwas verändert? Wptouch? Ich muss das mal bei mir testen.

  13. Ohne WPTouch mit dem anderen habe ich 15 :ugly:

  14. Ich habe eben einen Test gefahren, aus dem Samsung Galaxy Pad heraus. Ich habe einen Pagespeed von 73 und du hast momentan einen von 64.

    War wohl nur ein kleiner Verschlucker von Google.

  15. Danke Dir, scheint so.
    Gut geschlafen?

  16. Ja super, bis auf ein aus dem Bett gepurzeltes Kind in meiner Rem-Phase bestens erholt 😉

    Schön, dass mit deinem Pagespeed wieder alles ok ist.

  17. Danke für die sehr sinnvollen Hinweise zum all-inkl.com Hosting.
    Nach einem Check mit TPC! System Overview verbleiben Lücken; PROBLEM: allow_url_include, display_errors; WARNING: open_basedir, allow_url_fopen, magic_quotes_gpc, ModSecurity.

    Leider scheint es nicht möglich diese Lücken mit „php_flag off“ in der .htaccess komplett zu elminieren:
    php_flag display_errors off
    php_flag magic_quotes_gpc off
    sprechen scheinbar an, während folgende Befehle wohl ignoriert werden:
    php_flag allow_url_include off
    php_flag allow_url_fopen off

    Gibt es andere Lösungen, bzw. „Hardening“ (Erschwerung der Ausnutzung) für diese Lücken?

    P.S.: Es gibt hier einen ähnlichen Beitrag (Serendipity Forum all-incl.com): http://board.s9y.org/viewtopic.php?f=10&t=17567

  18. Leider kann ich dir da auch nicht helfen, aber danke für den Link. Ich werde mich zu dem Thema mal schlau machen.