clyphox
Forum Replies Created
-
What ever the issue with this plugin is I’ve just had to give up on it.
I had to do an emergency migration and its totally fudged all the posts up again, I’ve at least had success the old fasioned way:mysqldump origdb > wp_orig.sql cp wp_orig.sql wp_new.sql perl -pi -e "s+old.domain.com+new.domain.com+g" wp_new.sql perl -pi -e "s+/public/sites/oldpath+/public/sites/newpath+g" wp_new.sql # assuming the destination DB and grants are ready just drop it and re_create it with the new variables mysql -e "drop database newdb;" mysql -e "CREATE DATABASE newdb DEFAULT CHARACTER SET utf8;" mysql -uliveusername -plivepassword newdb <~/wp_new.sqlNB: the perl does a search/replace on a file..
I also use it on all files containing matches.. so hard-coded .xml files for some plugins for example sometimes need this.To find a list of files that need changing:
find /path/to/search -type f -exec grep -l <string> {} \;Yes I “think” the trick is to always ensure that your new wordpress databases always have the same character set/collation:
CREATE DATABASE mydb DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;Its still a mystery to me why the official wordpress installation docs exclude this. Maybe I’m wrong :/
ericson, if you’re still in a spot of trouple try this route:
http://wordpress.org/extend/plugins/utf-8-db-converter/
followed by creating the the new DB in utf etc:
http://www.rhyous.com/2009/11/05/how-to-create-a-utf-8-unicode-database-on-mysql/-good luck
I may need to do some tests to verify if this is maybe related to different collation on the DB itself :/ <throws hands up in air>