Das Kopieren eines Wordpress-Blogs funktioniert mit Daten exportieren und Daten importieren recht einfach. Im Detail stellt sich dann doch die eine oder andere Herausforderung:

1. Der neue Blog muß “eingerichtet” sein. D.h das Theme und die dort getroffen Einstellungen sowie die generellen Einstellungen des Blogs werden NICHT übernommen. (Möglicherweise würde es helfen, wenn man die wp_??_options zur Gänze in das neue Blog übernimmt. Doch vermutlich werden dann auch andere Einstellung übernommen, die so gar nicht gewünscht sind …. Nun das sollte ja nicht so aufwendig sein!
2. Bei der Gelegenheit ist mir aufgefallen, dass ich die Optionen des alten Themes “Magazin basic” zwar editieren, aber nicht mehr speicher kann. Nach einigem Suchen habe ich herausgefunden, dass im global.css die id auf display:none gesetzt ist. Habe zunächst dieses CSS geändert doch dann wieder den Originalzustand hergestellt und im function.php des Themes beim DIV eine Styleanweisung engefügt.
3. Das Kopieren der mycustomwidgets ist nicht damit getan, dass man den entsprechenden php-File kopiert, sondern man muß auch die Widgets in der wp_??_options übernehmen. Das sind alle Optionen die im Namen ein mwc enthalten. Diese kann man einfach in die neue Datei kopieren. Wenn dort bereits Optionen mit einer übereinstimmenden Opt_ID vorhanden sind, kann man die IDs in der Ursprungsdatei ändern (Habe kein Problem bemerkt). Die Datei muß trotzdem kopiert werden, oder die Widgets sind neu zu speichern.
4. Beim Importieren sollte man sich vergewissern, dass man tatsächlich im richtigen Blog ist. Als MU-Admin gelingt es einem nämlich die Stammdaten des Blogs zu bearbeiten während man sich in einem anderen befindet. Dies bringt im Importieren dann eher unschöne Ergebnisse.
5. Bei der Einrichtung des DomainMappings ist darauf zu achten, dass in der Haupteinrichtung (für alle Blogs) eine Häckchen für Adminseiten mit Originaladresse aufrufen gesetzt ist, sonst kommt man nicht auf die Admin Seite!

Nun läuft es also wieder!

Zuletzt konnte ich das Plugin nicht installieren, weil VHOST nicht aktiv war. Dann hat mir Fritz die DNS und VHOST Einträge eingefügt. Das Ergebnis war, dass die aktiven Blogs mit VHOST = yes nicht angesprochen werden können. Also habe ich einen Schalter eingefügt, der VHOST in Abhängigkeit vom Servernamen schaltet. Dabei habe ich entdeckt, das ein define nach einem define den Wert nicht mehr ändert. Der Schalter ist in wp_config.php.

Nachdem ich diesen Schritt erfolgreich vollzogen und den Blog test umgestellt sowie einen neuen angelegt hatte, bekam ich beim Installieren des Plugins den Hinweis:

Please copy sunrise.php to
/srv/www/vhosts/www.webcoach.at/blogs//wp-content/sunrise.php
and uncomment the SUNRISE definition in
/srv/www/vhosts/www.webcoach.at/blogs/wp-config.php

den ich prompt ausgeführt habe. Das Auskommentieren in wp-config.php darf allerdings wieder nur unter der Bedignung stattfinden, dass VHOST = yes ist.

Nachdem ich dachte alles richtig gemacht zu haben und das PlugIn installiert hatte waren die Tests nicht erfolgreich. Frustrierend. Wofür nun die ganze Mühe. Ein Nachschalgen half nicht die Beschreibung war dürr und den Code zu analysieren hatte ich keine Lust.

Wenn es nichts gebracht hat, dann wenigstens alles wieder deinstallieren. Als endlich alles wieder bereinigt war ist mir beim letzten Schritt, der Deaktivierung des Codes für VHOST aufgefallen, dass bei der Eingabe der gerouteten Domäne VHOST nicht auf yes gesetzt wird. Wenn das nicht passiert und dies aber die Voraussetzung für das Funktionieren des Plugins ist, liegt die Vermutung nahe, dass das Plugin deswegen nicht funktioniert – es wird ja auch sunrise nicht angesprochen.

Also neuerlicher Versuch, nun ging der Versuchsaufbau schon schneller und siehe da – es arbeitet! Perfekt. Allerdings gibt es noch Probleme mit den Kategorien und dem Archiv, aber auch das wird sich lösen lassen!

Hat sich schon gelöst! Es ist wichtig, dass das neue Blog tatsächlich mit VHOST=yes angelegt wird. Im vorigen Fall wurde der neue Blog offensichtlich anders angelegt und ich habe dann die Adressen geändert. Das hat interessanterweise nicht funktioniert. Obwohl eine Adressänderung beim TestBlog das Problem nicht hat, aber das hatten wir bei der Domainumstellung auch schon! Vielleicht ist es auch ein Cache-Problem (ich glaube dort war es auch so und hat sich nach und nach lösen lassen – muß mal nachsehen)

Abschließend sind die Blogs nun als Default auf VHOST=yes gesetzt, was für jedes neue Blog jedenfalls wirksam werden sollte. Die Blogs für die die alte Zugriffsvariante gilt sind taxativ im wp_config.php aufgezäht. Es sind derzeit alle außer livinglines, foto und test. Für test ist außerdem im indes.php noch ein redirect eingefügt damit der alte Aufruf mit dem Pfad auch funktioniert. Dies wäre für alle weiteren Umstellungen hilfreich.

Bei Coachit ist es geplant, IngridLauer war die Vorreiterin. Eine Domain soll direkt auf ein Blog unserer WordPress-mu Installation zeigen. Das was ich mir einfach vorgestellt habe ist nicht ganz so einfach.

Das Problem beginnt damit, dass ich für eine Domain zumindest ein echtes Verzeichnis brauche. Derartige Verzeichnisse werden für die Blogs in unserem mu aber nicht angelegt und können auch nicht angelegt werden. Ein Redirect wäre möglich, heißt aber, dass nach erfolgreichem Aufruf nicht die gewünschte Adresse in der URL steht.

Wenn man die Domain auf das Basisverzeichnis legt und dann in den Blog-Einstellungen die Domain verändert funktioniert zwar der Blog auf den ersten Blick, aber die AdminSeite kann nicht aufgerufen werden. Damit ist eine Administration des Blogs nicht mehr möglich.

Nun habe ich weiter gesucht und herausgefunden, dass es ein PlugIn gibt. Dieses PlugIn erfreut sich großer Beliebtheit, ich habe es installiert, es kann aber nicht konfiguriert werden. Es gibt eine für mich nicht definierbare Fehlermeldung. Nach Studium der Homepage habe ich den Verdacht, dass dieses Fehlermeldung sich darauf bezieht, dass wir keine Subdomains unterstützen. Wenn ich Subdomains richtig verstehe, dann sind das solche, die statt dem www einen anderen Begriff an den Beginn stellen. Also werde ich Fritz als nächstes bitten, die Subdomains zu aktivieren.

Heute nachmittag werden unsere Domänen übersiedeln. Hintergrund ist eine klarer Struktur der Nutzung. Vorgesehen sind folgende Zuordnungen:

• www.bueroco.com übernimmt die Daten der bisherigen www.coachit.at. Auf diesem Server läuft dann nur noch der “alte” webcoach auf einzig die DPI-Datenbank noch fallweise genutzt wird. Die Homepages (Büro&Co, Coachit) sind nun auf einer neune Site zusammengefasst.
• www.coachit.at übernimmt die Daten der bisherigen www.webcoach.at. Dort sind alle Wikis beheimatet. Die Wikis bekommen neue Aufrufmöglichkeiten. Siehe Liste unten.
• www.livinglines.at/eu/de wird auf das Verzeichnis blogs geroutet und ist damit die Basisdomäne für alle Blogs.

Die Kurzadressen für die Wikis:

• WiMe-BB.webcoach.at für www.coachit.at/WiMe-BB, gilt anlaog für alle WiMe Wikis
• DPI.webcoach.at für webcoach-DPI
• Garantie.webcoach.at für webcoach-GAR
• GAW.webcoach.at für webcoach-GAW
• HUECK.webcoach.at für webcoach-HE
• Reischauer.webcoach.at für webcoach-IO
• Navision.webcoach.at für webcoach-NAV
• ZAT.webcoach.at für webcoach.ZAT

Folgende Wikis sind zur Löschung vorgemerkt:

• webcoach-MAG, bereits gelöscht
• webcoach-3rd
• webcoach-third
• webcoach-WiMed
• webcoach-LL

Folgende Wikis sind von eigenen Domänen ansprechbar:

• Train-PM von Wiki.Positive-Managenment.at
• miraconsult von wiki.miraconsult.at

In der Phase II wird www.coachit.at dann von www.webcoach.at abgezogen und auf /blogs/coachit geroutet. Ab diesem Zeitpunkt können die Wikis über ihre derzeitige Adresse mit Pfadangabe nicht mehr erreicht werden.

Diese Umstellung erfolgt dann, wenn der PHP 5 Server, der neu installiert wird freigegeben ist.

Das Umstellen der Blogs von einer Domäne auf die andere ist nicht ganz trivial. Es ist im Config-File zu ändern aber auch in einer ganzen Reihen von Datenbankeinträgen. Letzten Endes haben wir einen Dump der Datenbank gezogen und dort durch Suchen und Ersetzen die Domäne getauscht. Dabei scheint sich bei den MyWidgets ein Fehler eingeschlichen zu haben. Damit waren die Widgets bei Paul nicht mehr einsatzfähig. Wir haben die alte Datenbank auf webcoach05 rückgesichert und den Eintrag der MyWidgets dort herausgeholt und in die modifizierte Datenbank kopiert. Die Pfadangaben habe ich dann dort manuell umgesetzt. Die Sicherung besteht noch.