Meinen emailenden Dauertipgeber lassen meine vage geäußerten Umzugspläne keine Ruhe und so versorgt er mich weiterhin mit Links:
- Migrating A Largish Site From WordPress to MovableType 4 ist ein älterer Beitrag aus dem Jahre 2007.
- Heute scheint es einfacher zu gehen, wenn man die Kürze dieses Beitrags betrachtet: Moving From WordPress To Movable Type.
Dabei geht es mir gar nicht so sehr darum, mein WordPress-Blog nach Movable Type zu transportieren, die paar Monate kriege ich schon irgendwie statisch, im schlimmsten Falle mit curl oder wget. Was ich möchte, ist das Beste aus beiden Welten:
- Die Möglichkeit, von überall im Netz mein Blog füttern und administrieren zu können.
- Die Geschwindigkeit, Einfachheit und Sicherheit, die mir statische Seiten bieten (schließlich sind vom Schockwellenreiter nur die Seiten (aus 2000) verschwunden, die ich dynamisch bei EditThisPage hosten ließ und dann fehlen ein paar hundert Bilder aus der Zeit, als mein Weblog dynamisch mit COREblog, einer Zope-Applikation betrieben wurde — die eigentlichen Webseiten hatte ich rechtzeitig vor dem Server-Crash und etwas mühselig mithilfe von
wgetzu statischen Seiten gemacht).
Momentan finde ich zwei Ideen ganz charmant:
Ich reaktiviere meine Räume in der Server-WG und lasse dort Movable Type als Redaktionsserver laufen. Und schicke von dort statische Seiten entweder weiterhin zum Spielzeugprovider oder direkt nach Amazons S3. Ich hätte die von mir schon immer geforderte Trennung von Redaktions- und Produktionsserver und gleichzeitig die Gewißheit, mit den statischen Seiten eine leicht zu sichernde Version des Schockwellenreiters irgendwo zu Backup-Zwecken zusätzlich noch einmal ablegen zu können.- Oder ich gehe ganz in den Cloud. Googles App Engine hat es mir eigentlich schon immer angetan, mit einem von mir in Python geschriebenem Template Toolkit, das statische Seiten herausrendert, hatte ich den Schockwellenreiter schon einmal ein paar Jahre betrieben, warum nicht so etwas, vieleicht mit Hilfe des Django-Frameworks für Googles Cloud entwickeln, das dann ebenfalls statische Seiten nach Amazons S3 herausrendert? Auch in diesem Falle wären Redaktions- und Produktionsserver getrennt und es gilt ebenfalls das für statische Seiten im Abschnitt oben Geschriebene.
Aber ich bin mit meinen Überlegungen noch nicht fertig: Eine weitere in meinem Hinterkopf schwebende Option wäre nämlich, mein Blog mit meinem Wiki zu verschmelzen. Mir gefällt die Einfachheit des Markup-Codes von DokuWiki und die Möglichkeit, ohne die starre Einteilung in Überschrift und Blogbeitrag (und ohne die starre zeitliche Reihenfolge) publizieren zu können — meine Kurzbeiträge brauchen nämlich manchmal keine Überschrift, die ich mir dann erst mühselig aus den Fingern saugen muß.
Sicher, ich hätte dann nicht die Trennung von Redaktions- und Produktionsserver und das DokuWiki rendert auch keine statischen Seiten heraus. Aber immerhin versenkt es seine Inhalte nicht in eine Datenbank, sondern legt sie brav in leicht zu sichernde und wieder zu lesende Textfiles ab.
Und irgendwie ist auch das Perl Template Toolkit noch nicht völlig aus dem Rennen.
Ihr seht, sooo schnell wird eine Änderung hier nicht passieren. Der Leidensdruck ist momentan noch nicht so groß und ich muß noch ein wenig nachdenken …
































Ganz so einfach, wie die MT-Leute das darstellen, ist es nun leider auch wieder nicht. Der beschriebene Weg bringt bei einem Umzug zwar die Blogeinträge mit, nicht aber selbstgehostete verlinkte Inhalte wie Bilder oder Video. Da ist dann Handarbeit nötig, ebenso, wenn man, durch
Schadenjahrelange Lernprozesse klug geworden, solche Inhalte zwar schon auf dem Server hat (z.B. weil man ohne Umzug auf MT umstellt), aber neu sortieren und unterbringen will.Dabei hat mir ein Feature von MT sehr geholfen: Suchen und ersetzen über viele Einträge hinweg. Super!
[...] Dieser Eintrag wurde auf Twitter von Chris D und Jörg Kantel, Astrid P. Kunz erwähnt. Astrid P. Kunz sagte: Noch einmal WordPress nach Movable Type: Meinen emailenden Dauertipgeber lassen meine vage geäußerten Umzugsplä.. http://bit.ly/08KRsIs [...]
Mal ne dumme Frage: Warum willst du aus der App Engine statische Seiten herausrechnen?
Der Grund aktuell sind ja skalierungsprobleme/DB probleme, soweit ich es sehe, aber die hast du dort doch nicht. Das erscheint mir also nicht sinnvoll zu sein, zumal in der App Engine die Scriptlaufzeit stark begrenzt ist, das neuerzeugen aller Seiten würde zum Problem werden.
@LH: Mein Hauptgrund statische Seiten zu erzeugen ist der, daß ich einen immer funktionierenden Fallback haben möchte, z.B. falls es die App Engine einmal nicht mehr gibt oder Google auf einmal mehr Geld dafür verlangt, als ich zahlen kann. Die statischen Seiten des Schockwellenreiters funktionieren alle noch, egal mit welchem Tool sie erzeugt wurden. Und das waren viele: Radio Userland, mein selbstgestricktes Weblogtool in Python, COREblog/Zope und Frontier.
waiting for http://www.schockwellenreiter.de
waiting for http://www.schockwellenreiter.de
waiting for http://www.schockwellenreiter.de
waiting for http://www.schockwellenreiter.de
waiting for http://www.schockwellenreiter.de
waiting for http://www.schockwellenreiter.de
…
ab sofort läuft der Schockwellenreiter bei mir in einem extra Tab. Die Ladezeiten sind wie zu Modem Zeiten. Über 2 Minuten …
Google? Eher trennt sich die Bundesrepublik Deutschland vom Internet.
Ich würde jetzt noch die 8 oder 9 Jahre bis zur Pension warten und dann etwas selber schreiben. Möglichst in C, denn das gibt es noch nicht.
mal überschlagen, was das bei S3 kostet? Du hast ja um 200k Pageviews, jede ca. 30KB? hm, laut S3 Calculator weniger als 2$ pro Monat, ok