Abonniere die neusten Artikel via RSS-Feed oder Atom und verfolge die Kommentare ebenso via RSS-Feed oder Atom-Feed
Anzeige
Das Umziehen des Blog auf einen neuen Provider hatte ich schon vor geraumer Zeit erklärt, Hinweise und Problemlösung sind auch dort zu finden. In diesem Zusammenhang hat sich nicht viel geändert, der Ablauf kann noch immer so durchgeführt werden, auch wenn der Artikel nun schon ein wenig in die Jahre gekommen ist.
Trotzdem steht aber bei dem einen oder anderen ein ganz anderes Problem - der Umzug eines bestehenden Blog zu einer neuen Domain. Dies kann verheerende Auswirkungen auf die Besucherzahlen haben, wobei es nicht um diese Aspekte gehen soll, und die neue Domain macht den Umzug nicht ganz so einfach – oder doch? Wie man mit wenigen Schritten und einfachen Abläufen das Blog auf eine neue Domain umzieht, darum wird es im folgenden gehen.
Bevor es um den eigentlichen Umzug geht, sollte man natürlich ein Backup aller Dateien und Daten in der Datenbank machen, sollte eigentlich nicht mehr erwähnt werden.
robots.txt, die mit nur wenigen Zeilen Inhalt auskommt:
User-agent: *
Disallow: /
Nun könnt ihr ungestört arbeiten und Suchmaschinen nehmen noch keine Notiz von euch.
Update: Jan weist in den Kommentaren darauf hin, dass diese Lösung nicht so gut ist, denn Google indiziert dann die Seite bis zu den kommenden 90 Tagen nicht. In diesem Fall rate ich lieber zu einer Sperrung der neuen Domain via .htaccess-Zugriffsschutz – wie das geht, auch dazu habe ich bereits einen Artikel erstellt. Den passenden Generator findet ihr hier.
Update II: Noch besser ist eine index.php, die mit der Funktion header() ausgestattet, den Besucher Suchmaschine nur hinhält und zum Wiederbesuch bewegt.
<?
header("HTTP/1.0 503 Service Unavailable");
header("Retry-After: 3600");
?>
Weiteres zum Thema findet mal in den Kommentaren.
wp-config.php muss bearbeitet werden. Dazu die Datei im Editor eurer Wahl öffnen und die folgenden Daten ergänzen. Dabei ergänzt ihr die Datei um zwei Konstanten, die nun die neue Domain und das neue Installationsverzeichnis von WordPress definieren.
define('WP_SITEURL', 'http://www.example.com');
define('WP_HOME', 'http://www.example.com/blog');
Die Definition der beiden Konstanten empfiehlt sich auch für jeden anderen Blog, denn damit erspart sich WordPress die Anfrage an die Datenbank und man kitzelt wieder einiges an Zeit für die Performance aus der Installation. Die korrekte Definition ist unbedingt zu prüfen, denn schon ein falsches / kann dem Leser den Besuch verwehren!
Sind die beiden Konstanten definiert, dann ist das daran zu erkennen, dass im Bereich der Einstellungen von WordPress die beiden Felder deaktiviert sind, siehe Screenshot.
robots.txt gelöscht bzw. auf einen neuen Stand gebracht werden. Suchmaschinen bekommen nun Zutritt..htaccess-Datei, die folgenden Inhalt trägt:
Redirect 301 /blog/ http://www.example.com/
Im Grunde war es das schon. Ist also gar nicht so schwer, wie es anfangs scheint. Viel Erfolg beim Umzug.
Kommentarregeln: Bleib cool, kritisch ist in Ordnung, aber wenn du unhöflich bist, dann lösche ich deinen Kommentar. Bitte benutze deinen persönlichen Namen oder Initialen und nicht den Namen eines Unternehmens, dies würde als Spam gewertet und wird gelöscht. Der Zusammenhang zwischen Namen und URL sollte nicht offensichtlich auf Spam hindeuten! ♥ Ansonsten, vielen Dank für den Kommentar und viel Spaß mit meinem Blog.
händischer Spam:
Beachte die Kommentarregeln, jede Form von versuchtem Spam wird gelöscht. Warum und wieso steht in einem meiner Beiträge.
Bezug auf Textstellen:
Du kannst direkt bezug auf Textstellen im Beitrag nehmen. Dazu muss lediglich der Bereich im Artikel markiert werden; daraufhin erscheint ein Button, der den markierten Text in das Kommentarfeld übernimmt und als Zitat auszeichnet. Die Funktion ist nur bei aktivem JavaScript nutzbar.
xHTML:
Du kannst folgende Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <pre> <em> <strong> <strike> <ul> <ul> <li>
Achte darauf, wenn du Code im Kommentar hinterlegen willst, dann muss der Code maskiert sein. Dann wird er nicht interpretiert. Der Code muss mit Hilfe von HTML-Entities dargestellt werden, d.h. dass man z.B. < als < und > als > einfügt.
E-Mail-Benachrichtigung bei neuen Kommentaren ?
Wenn der Haken in der Checkbox gesetzt ist, dann wirst du über neue Kommentare vie E-Mail informiert. Der Versand erfolgt nur, wenn du die URL in der Bestätigungs-E-Mail genutzt hast oder schon Abonnent hier im Blog bist.
Kommentar erscheint nicht:
Alle Kommentare werden manuell geprüft, freigegeben und nach Möglichkeit beantwortet. Bitte um etwas Geduld und Nachsicht.
Identifikationsbilder (Avatare):
Auf Gravatar.com kann man sich mit seiner E-Mail-Adresse registrieren und ein Bild hochladen, dann erscheint dieses Gravatar hier und in vielen weiteren Blogs.
Spamschutz:
Das Kommentarformular ist mit einem Spamschutz ausgerüstet. Solltest du diesen Artikel ohne JavaScript besuchen und kommentieren wollen, so muss du die Frage beantworten und das jeweilige Wort in das Textfeld eingeben.
bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.
Das Weblog wird angetrieben von WordPress und aktuell gibt es 886 Beiträge, 16217 Kommentare in 14 Kategorien und 448 Tags.
Das Blog wird liebevoll mit xHTML & CSS in Handarbeit gestaltet.
Design und Code ist unter Copyright
© 2001 - 2010 bueltge.de [by:ltge.de]
12. August 2008 um 11:59
Frank, bei Punkt 1 muss ich dir leider vehement widersprechen.
Ein Spiderverbot per robots.txt sorgt zwar dafür, dass die Suchmaschinen draußen bleiben, leider bleibt das oft auch so nach Entfernen dieser Einschränkung (bei Google zum Beispiel bis zu 90 Tage lang). Wer also "Disallow: /" nutzt macht sich schon im Vorfeld mit großer Wahrscheinlichkeit die Chance kaputt mit dieser Domain in nächster Zeit gut gefunden zu werden.
Viel besser ist es den Zugang zu der Domain per Passwortabfrage (.htaccess) zu verhindern. Dieser lässt sich dann später einfach entfernen und hat keine Auswirkungen auf das zukünftige Verhalten der Suchmaschinenbots.
Ansonsten wie immer schöner Artikel und Anleitung.
12. August 2008 um 12:02
@Jan Piotrowski: Vielen Dank! Das ist mir nicht bekannt und so sollte ich das ändern und lieber per .htaccess sperren. Danke !
12. August 2008 um 12:26
Vorher war ich ein wenig zu faul direkt die Quellen rauszusuchen, als Beleg für den Sachverhalt habe ich es aber doch getan:
http://www.google.com/support/webmasters/bin/answer.py?answer=35302&hl=dehttp://www.google.com/support/webmasters/bin/answer.py?answer=61062&hl=deMan kann zwar auch die Wiederaufnahme beantragen, aber auf die Idee muss man als gewöhnlicher Webmaster erstmal kommen. Deshalb wie gesagt lieber per .htaccess. Auch dazu noch fix der passende Link:
http://www.drweb.de/htaccess/zugriffsschutz_1.shtml12. August 2008 um 12:47
Gute Tipps. Evtl. ziehe ich mit meiner Domain noch mal um. Hab mir ne neue registriert, will aber meinen jetzigen Webspace behalten. Da streite ich noch mit meinem Hoster
Werde deine Tipps dann aber berücksichtigen.
12. August 2008 um 16:36
Habe erst gestern Dein Plugin gefunden und alle alten Links endlich durch einen neuen Pfad ersetzen können. Diese Hilfe wird sicherlich vielen Bloggern helfen, wobei ein eigenes Plugin dafür toll wäre
Bitte umziehen von /Domain/ auf /neueDomain/
12. August 2008 um 16:37
12. August 2008 um 19:55
12. August 2008 um 20:24
Google per .htaccess auszuschließen ist genauso blödsinnig wie die robots.txt. Ich hatte mal Google aus versehen per .htaccess gesperrt (erst 403 - forbidden, dann 404 - not found). Ich glaube Google ist heute noch sauer auf mich.
Ich würde einfach eine index.htm anlegen in der der typische "Baustellenschild-Inhalt" hinterlegt ist (Hier entsteht demnächst eine neue Domain schaufelndes Männchen-Gif).
Die index.htm hat den Vorteil das man in den meta-Tags ein revisit angeben kann und somit recht genau bestimmen kann wann Google&Co wiederkommen sollen. Das andere Inhalte als die index.htm gecrawlt werden, davor muss man keine Angst haben. Die SuMas können ja nur Seiten entdecken, die auch verlinkt sind.
Ein Problem gibt es allerdings: Ist der Webserver so eingestellt das erst index.php ausgeliefert wird, dann funktioniert das ganze natürlich nicht (sofern eine index.php vorhanden ist). Unter Umständen kann man die Reihenfolge der auszuliefernden Dateitypen in der .htaccess festlegen (sofern der Hoster dies zulässt). Damit wäre es auch möglich eine start.htm anstatt eine index.htm anzugeben, falls man index.htm für irgendwelche Testzwecke benötigt. (weitere Infos: DirectoryIndex)
Ich bin mir nicht sicher in wie weit sich ein Redirect in der .htaccess SEO-Technisch auswirkt (doppelter Content). Aber auch dies wäre dann ja ggf. eine Möglichkeit. Man schickt einfach alle Sumas per Redirect auf die alte Domain. Das hat natürlich den Nachteil das man ggf. die eine oder andere SuMa vergisst oder Crawler/Besucher zufällig auf die Domain aufmerksam werden.
Ich denke die Lösung mit der index.htm(l) ist aber die einfachste.
12. August 2008 um 20:31
@Ralf: Danke dir für die Infos.
Das gefällt mir eh sehr gut - auf die einfachen Sachen kommt man oft nicht.
12. August 2008 um 20:40
Leider wird das so nicht funktionieren Ralf. Eine index.htm verhindert zum Beispiel nicht, dass Deeplinks oder Feeds gespidert werden. Und an das Metatag revisit halten sich Google und Co sowieso nicht.
Natürlich hast du Recht, die von dir angesprochene Methode über die .htaccess 403 forbidden oder 404 not found zu liefern ist natürlich mindestens genau so schlecht wie eine robots.txt die den Zugriff verbietet - alles sorgt dafür, dass die Domain langfristig geblockt wird.
Einen 401 Authorization Required hingegen wird von Googles Bot erfahrungsgemäß neutral behandelt.
12. August 2008 um 21:52
Meine liebste Methode, die Suchmaschinen während der Bauphase von einer Indizierung der Site abzuhalten, ist die Antwort mit dem Status 503 ('Service Unavailable').
Der vom RFC 2616 vorgegebene Anwendungsfall deckt sich genau mit der Wahrheit: "The server is currently unable to handle the request due to [...] maintenance of the server."
Damit verschreckt man den Spider meiner Erfahrung nach nicht ernsthaft, sodass nach Inbetriebsetzung eine zügige Aufnahem der neuen Domain in den Suchindex gewährleistet ist.
Für angemeldete Benutzer mit WordPress- (oder Textpattern)-Logincookie unterdrücke ich diesen Header, damit verhält sich die Site ganz normal, sodass man im Hintergrund schon fast wie live an der Site mit Design und Inhalt arbeiten kann.
13. August 2008 um 09:12
Stimmt, das ist auch eine elegante Lösung, Robert. Und die Harmlosigkeit bezüglich Google und Co. kann ich definitiv bestätigen. Lust den Code mit uns zu teilen?
13. August 2008 um 10:09
Ach Frank, ich könnte dich küssen ^^
Ich habe vor im Laufe der Woche mit meinem Blog umzuziehen und schon nach eine Anleitung gesucht. Es kann ja immer mal sein, dass man auf etwas achten muss.
Auf jeden Fall interessiert mich ebenfalls, wie man Google nun jetzt am besten aussperren sollte ohne dass er bockig ist ^^
Gruß
Wishu
13. August 2008 um 14:45
13. August 2008 um 20:35
Jan, ich hab das ganze
503 Service Unavailable-Handling mal in ein kleines Plugin eingestrickt. Liegt hier zum Herunterladen und Testen herum.13. August 2008 um 21:08
@Robert @TalkPress: Ähnlich habe ich es in dem Plugin !Wartungsmodus gelößt, leider schon sehr lange her. Da das aber bei einem Umzug nicht per Plugin so einfach geht, zumindest so lange WP nicht installiert ist, reicht quasi eine index.php mit den header-Infos siehe PHP.net.
header("HTTP/1.0 503 Service Unavailable"); header("Retry-After: 3600");19. August 2008 um 09:06
Weiß jemand von euch, wie man alte einzelne Beiträge auf ein neues Blog umzieht? Alles einzeln direkt aus der Datenbank exportieren mag ich nicht...
19. August 2008 um 11:40
@markus: Im Grunde bleibt dir nur die DB oder der XML export, den man den händisch auf die entsprechenden Beiträge kürzen muss.
19. August 2008 um 12:09
Danke für den Tipp mit dem XML-Export, das kannte ich soweit gar nicht.
21. September 2008 um 23:03
Vielen Dank für den Beitrag. Von .de zu .com in drei Minuten, die dank deines "!Wartungsmodus"-Plugins sogar hinreichend deklariert waren...
Top!
10. Oktober 2008 um 18:13
Hi,
warum verwendet ihr nicht die .htaccess oder gleich in die httpd.conf folgendes rein. Dann setzt ihr einen Redirect 301 auf die neue Domain und zieht die ganze Domainpower mit:
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^www.altedomain.de$ [NC]
RewriteRule ^(.*)$
http://www.neuedomain.de/$1[R=301,L]LG,
Martin
Options SymLinksIfOwnerMatch
11. Oktober 2008 um 12:31
Martin, weil der von Frank in Punkt 8 vorgeschlagene Redirect in der .htaccess wesentlich eleganter ist und die Suchmaschinen dadurch mitbekommen das die Domain umgezogen ist
2. Februar 2009 um 13:44
Mal eine Frage: Ich habe unter
http://www.xxx.com/deeine WordPress-Installation, die einfach aufhttp://www.xxx.deumgezogen werden soll. Die Datenbank ist unabhängig von diesen Domains und ziehlt auf xyz.your-server.de ab.Würde es reichen, einfach die WordPress-Adresse und die Blog-Adresse zuvor bei der alten Installation von
http://www.xxx.com/deaufhttp://www.xxx.deabzuändern, dann die Daten zu kopieren und auf dem neuen Webspace einzufügen (im Prinzip der gleiche Server)?2. Februar 2009 um 18:21
@Dirk M.: ja, die DB hat ja damit nichts zu tun direkt, aber Inhalte der Db könnten betroffen sein. Daher solltest du eventuell Suchen/ersetzen in der SQL-Datei durchführen. Ansonsten kannst du die Def. der Konstanten, siehe Beitrag oben, in der neuen
wp-config.phpvornehmen, so musst du nicht die Einstellungen im Backend von WP ändern.28. Februar 2009 um 06:39
ich wollte nur kurz ein Dankeschön hier lassen, ich musste einen Blog umziehen, neue DB Version, neue Domain, neuer Server ... mit diesem Beitrag im Hinterkopt hat alles geklappt
6. April 2009 um 15:18
Hallo,
Auch ich bin sehr dankbar für den Beitrag oben. Insbesondere als auffiel das Umlaute und div. Sonderzeichen nach dem DB Export nicht nur bei mir kryptisch werden. In etwa so:
ü = ü
Ü = Ãœ
ö = ö
Ö = Ö
ä = ä
Ä = Ä
á = á
à = "Ã "
â = â
é = é
è = è
ß = ß
"" = Â (nix bzw. doppeltes Leerzeichen)
° = °
Leider hat auch das durchlaufen des Scriptes nicht geholfen. Mir blieb nur per Copy&Paste im Export alles zu ersetzen, z. B. mit ü. Was dann wiederum, importiert, im PHPMyAdmin nicht umgewandelt wurde.
Gibt es irgendeine Einstellung die ich übersehen haben, einen Fehler den ich gemacht haben könnte? Zur Info:
- im alten WP ist das Plugin o42-clean-umlauts installiert
- ich habe der Export in die neue leere Datenbank importiert, da ich bei einem vorherigen Importversuch, nach Installation mit install.php Probleme mit verschobenen Cat-Zuwweisungen hatte.
Es wäre wirklich ganz ganz dufte wenn ich hier Hilfe fände
Liebe Grüße,
Sigema
7. April 2009 um 09:06
@Sigema: nein, ist soweit OK, wenn aber die alte DB so ist, dann kann man nur via Script oder per Suchen/Ersetzen die Zeichen korrigieren. Für letzteres gibt es Plugins und für die Umstellung auf UTF-8 gibt es ebenso Plugins.
15. Juni 2009 um 15:34
Hi! Vielen Dank für die Beschreibung. Das hat bei mir auch soweit funktioniert. Ich habe jetzt allerdings das Problem, dass ich keine automatischen Updates mehr bei wordpress machen kann. Klicke ich das Feld an, dann muss ich ja Nutzername und Kennwort meines Servers angeben. Dort nimmt er aber nicht die Kennungsdaten des neues Servers (neue Domain liegt auf anderem Server) und bringt eine Fehlermeldung, dass diese Daten falsch sind. Wenn ich aber die alten Server-Kennungsdaten eingebe, dann funktioniert das automatische Update wohl zwar ohne Fehlermeldung, aber dort soll das Update ja nicht ausgeführt werden.
Ich hoffe, ich konnte verständlich machen, wo das Problem liegt. Hast Du vielleicht spontan eine Idee, warum er die neuen Kennungsdaten als falsch zurückweist? Mit welchen Daten gleicht er das intern ab? Die wp-config habe ich zumindest mit den neuen URL - so wie oben beschrieben - versehen...
VG!
Michael
15. Juni 2009 um 16:10
@Michael: die Daten, die ich hier nenne, haben dabei keinen Einfluss. Du musst beim automatischen Update die FTP-zugangsdaten hinterlegen, die vom Webspace geliefert werden oder die du selbst definiert hast.
8. August 2009 um 17:40
Auch ich möchte innerhalb der kommenden 2 Wochen mit unserem Blog von
http://www.klosterblog.wat-lo.comaufhttp://www.theravadablog.deumziehen. Beide Domains sind innerhalb eines Webpakets gehostet.Meine Frage:
Könnte hier nochmal jemand kurz auf das wieder einspielen des Datenbankbackups eingehen.
Ich stehe vor folgendem Problem, mein 1&1 Hostingpaket lässt nur eine Datenbank zu, d.h. nach dem Backup muss ich die alte Datenbank löschen.
Muss ich dann quasi eine neue erstellen und mittels eine import Funktion die Daten einspielen?
Danke,
Sascha
9. August 2009 um 16:24
@Sascha: wenn die DB im gleichen Webspace liegt, wie die alte, und sich nur die Domain ändert, dann kannst du doch wieder nutzen.
9. August 2009 um 17:53
@ Frank
So etwas in der Art hatte ich gestern im Anschluss an Deinen Artikel auch noch im Netz gefunden, macht im Grunde ja auch Sinn.
Wie muss ich dann aber weiter vorgehen? Kannst Du mir kurz unter die Arme greifen?
Ich muss wohl auf jeden Fall die Daten, die unter der alten Domain auf dem Server liegen via FTP downloaden und der neuen zuordnen, sprich uploaden, richtig?
Muss ich sonst noch etwas tun?
Danke!
Sascha
9. August 2009 um 18:57
Wenn sich nur die Domain ändert, dann muss man wohl nichts tun, wenn der Provider der gleiche ist. Aber das ist unterschiedlich. Mache in jedem Fall per FTP ein Backup und ebenso von der Datenbank, schadet nicht.
9. August 2009 um 21:40
Ja, es ändert sich lediglich die Domain. Gleicher Provider (1&1), gleiches Hosting Paket, gleicher Server.
Muss ich dann nicht irgendwie die URLs der Beiträge anpassen? Sie würden innerhalb der Datenbank ja noch auf die alte Adresse bezogen sein oder?
9. August 2009 um 22:41
Der Provider (1&1) ist der gleiche, das Hosting Paket ist das fleiche und der Server wohl auch.
Wenn ich aber nur die Daten die ich via FTP von der alten Domain ziehe unter der neuen hochlade, dann passen doch die Beitrags URLs nicht mehr, oder?
Wenn ja, wie passe ich sie an? Ich hab mal Dein Search&Rename installiert, kann aber als Newbie nicht all zu viel damit anfangen.
10. August 2009 um 08:20
@Sascha: die URLs in der Datenbank müssen angepasst werden, wenn es denn welche gibt. Lese mal die Anleitung, dort steht es drin.
10. August 2009 um 09:21
@Frank:
Ich habe nun gestern die Blogdaten via FTP von der einen auf die andere Domain verschoben. Danach war der Blog unter der neuen Domain erreichbar, jedoch waren alle URLs noch mit der alten Adresse versehen. Also habe ich die wp-config.php mit den neuen Adressdaten versehen, was zur Folge hatte, dass die URLs entsprechend der neuen Domain (automatisch) geändert wurden. Nun noch Feedburner und ReCaptcha auf die neue Domain eingestimmt und es sieht so aus, als wenn alles problemlos gelaufen sei.
Abschließend habe ich noch eine .htaccess mit der 301er Meldung im Webspace der alten Domain verankert.
Kann ich es nun riskieren, die Daten der alten Domain zu löschen oder muss noch etwas beachtet werden?
So weit vielen Dank für Deine Hilfe!
10. August 2009 um 11:05
Du musst aber trotzdem URLs in der Datenbank ändern, wenn es denn welche gab. Da die wp-config dort nicht gezogen wird, dass ist pur content.
10. August 2009 um 11:27
Könntest Du mir bitte erklären wie ich herausbekomme ob URLs welche die alte Domain beinhalten in der Datenbank vorhanden sind, wie ich sie finde und wenn vorhanden ändern kann?
Vielen Dank!
10. August 2009 um 12:29
Du kannst via SQL recht gut suchen:
SELECT * FROM wp_posts WHERE post_content LIKE 'http://alte_url%';10. August 2009 um 15:25
Danke Frank!
Nun habe ich via MySQL und dem von Dir genannten Code die Datenbank nach URLs der alten Domain durchsucht und habe einige in versch. Tabellen (wp_ak_twitter, wp_comments, wp_links, wp_options, wp_postmeta, wp_posts, wp_statz, ) gefunden.
Ist es nun ratsam die alten URLs mittels dem Button "Bearbeiten" (MySQL) händisch in die neue Domain-URL zu ändern? Wäre allerdings einiges an Arbeit.
Oder kannst Du mir kurz erklären, wie ich in Search&Rename vorgehen muss, ich steige bei dem Tool nicht so ganz durch, da ich mit SQL normalerweise absolut nichts zu tun habe.
10. August 2009 um 18:36
Du kannst direkt via SQL ändern, mal am Beispiel der Tabelle posts:
UPDATE wp_posts SET post_content = REPLACE(post_kontent, 'alte_url', 'neue_url');. Allerdings geht das einfacher mit dem besagten Plugin: Suchen & Ersetzen.Aber das Plugin bedient nur Tabellen von WordPress; du hast auch Tabellen von Erweiterungen, die du dann nur per SQL ändern kannst.
10. August 2009 um 19:15
Ich hatte es gegen Mittag mit Search&Replace versucht. Ursprünglich bekam ich 62 Treffer angezeigt, was auch der Abfrage über phpMyAdmin entsprach. Nach dem S&R durchgelaufen war wurde mir 0 angezeigt. phpMyAdmin zeigt mir jedoch nach wir vor Treffer an (nicht nur in den Tabellen der Erweiterungen, sondern auch in denen, die eigentlih von S&R bereinigt wurden.
Nutze ich den manuellen Weg mit dem von Dir o.g. Befehl, so bekomme ich jeweils folgenden Fehler angezeigt: #1054 - Unknown column 'post_kontent' in 'field list'