<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:georss="http://www.georss.org/georss" >

<channel>
	<title>David Coveney &#187; migration</title>
	<atom:link href="http://davidcoveney.com/tag/migration/feed/" rel="self" type="application/rss+xml" />
	<link>http://davidcoveney.com</link>
	<description>Doing things</description>
	<lastBuildDate>Fri, 03 Feb 2012 23:04:09 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
		<item>
		<title>PHP Serialization Fix for WordPress Migrations (&amp; other applications like Expression Engine)</title>
		<link>http://davidcoveney.com/575/php-serialization-fix-for-wordpress-migrations/</link>
		<comments>http://davidcoveney.com/575/php-serialization-fix-for-wordpress-migrations/#comments</comments>
		<pubDate>Mon, 02 Mar 2009 18:49:58 +0000</pubDate>
		<dc:creator>David Coveney</dc:creator>
				<category><![CDATA[Technical]]></category>
		<category><![CDATA[WordPress]]></category>
		<category><![CDATA[export functionality]]></category>
		<category><![CDATA[import functionality]]></category>
		<category><![CDATA[migration]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[serialize]]></category>
		<category><![CDATA[wordpress]]></category>

		<guid isPermaLink="false">http://davidcoveney.com/?p=575</guid>
		<description><![CDATA[Serialization of data loaded into an SQL table is a dreadful thing and makes WordPress migrations harder than they should be, but it happens and so we must deal with it.  I've knocked up a rough and ready bit of code which does its best to resolve the problem.]]></description>
			<content:encoded><![CDATA[<div id="attachment_576" class="wp-caption alignright" style="width: 310px"><a href="http://davidcoveney.com/wp-content/uploads/2009/03/wildebeest_migration.jpg" rel="lightbox[575]"><img class="size-medium wp-image-576" title="wildebeest_migration" src="http://davidcoveney.com/wp-content/uploads/2009/03/wildebeest_migration-300x208.jpg" alt="A different kind of migration - public domain from Wikipedia Commons" width="300" height="208" /></a><p class="wp-caption-text">A different kind of migration - public domain from Wikipedia Commons</p></div>
<p>When you move a WordPress blog from one folder to another, or from one site to another, you normally use the export/import functionality.</p>
<p>This is fine for normal blogs, but say you&#8217;ve developed a new website and set it up on your local machine &#8211; the URL for the site may be something like http://localhost/devsite and the live URL will be something like http://davidcoveney.com &#8211; you won&#8217;t want to set up all the theme options, site options, plugin options and so on all over again.</p>
<p>Instead, a theoretically simple approach is to do a database dump, a search and replace for all references to server paths and URLs, and then reimport that data in the new location.</p>
<p>Should work, but it often falls apart.</p>
<p>What happens is that in WordPress, its themes and its plugins, a lot of data is stored using a method known as serialization.  Now, in my opinion this breaks all known good practice around data &#8211; it&#8217;s language specific, it&#8217;s not relational even though it often could be, and it&#8217;s hard to edit by hand.</p>
<p>One particular problem is that if you change the length of the data in a serialised string you have to change the length declared in the generated string.</p>
<p><em>That&#8217;s very painful when you have hundreds of the fields.</em></p>
<p>So, because I&#8217;d found this painful I decided to knock together a quick application to at least reduce the amount of editing I had to do.  You just do your search and replace, forget about the serialized string lengths, upload your data to the new database, and run this script.</p>
<p><em>Warning: </em>I haven&#8217;t got it to work for widgets and cForms II yet, but the latter has some export functionality anyway, which takes that particular pain away if you plan ahead.  In the meantime, feel free to play with the attached file.  You use it at your own risk, of course.</p>
<p>To use it, download the file linked in this post, extract it, open the file, edit the connection settings, tell it the table you want to scan through, the column, and the unique key field.  If you somehow manage to have more than one unique key to deal with (you shouldn&#8217;t, but then it surprises me what people manage to code up), then you&#8217;ll have to modify the code accordingly.  Once done, make sure you have a backup of that table, and execute the php &#8211; either at the command line or through the browser.  License is WTFPL, and if you&#8217;d like to improve the code, please do and I&#8217;ll host the new version.</p>
<div class="wp-caption alignright" style="width: 56px"><a href="http://davidcoveney.com/wp-content/uploads/2009/03/serialization-fixer.zip"><img title="Serialization-fixer.zip" src="http://davidcoveney.com/wp-includes/images/crystal/archive.png" alt="Serialization-fixer.zip download." width="46" height="60" /></a><p class="wp-caption-text">download file</p></div>
<p><a href="http://davidcoveney.com/wp-content/uploads/2009/03/serialization-fixer.zip">Serialization-fixer.zip download</a></p>
<p><em><strong>BIG WARNING: I take no responsibility for what this code does to your data. Use it at your own risk. Test it. Be careful. OK? Here in the North we might describe the code as being as &#8220;Rough as a badger&#8217;s arse.&#8221; Never felt a badger&#8217;s arse, but I&#8217;ll take their word for it.</strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://davidcoveney.com/575/php-serialization-fix-for-wordpress-migrations/feed/</wfw:commentRss>
		<slash:comments>23</slash:comments>
		</item>
		<item>
		<title>Resolving WordPress Migration Issue</title>
		<link>http://davidcoveney.com/87/resolving-wordpress-migration-issue/</link>
		<comments>http://davidcoveney.com/87/resolving-wordpress-migration-issue/#comments</comments>
		<pubDate>Thu, 13 Jul 2006 16:24:40 +0000</pubDate>
		<dc:creator>David Coveney</dc:creator>
				<category><![CDATA[Technical]]></category>
		<category><![CDATA[migration]]></category>
		<category><![CDATA[resolution]]></category>
		<category><![CDATA[wordpress]]></category>

		<guid isPermaLink="false">http://davidcoveney.com/?p=87</guid>
		<description><![CDATA[I&#8217;m posting this for the benefit of anyone who experiences a similar problem to mine when moving WordPress from a directory into the web&#8217;s root directory. What happened was that many links and pictures, some placed in there by plugins, others simply links that were typed in, had failed. I realised that although I&#8217;d followed&#8230;]]></description>
			<content:encoded><![CDATA[<p>I&#8217;m posting this for the benefit of anyone who experiences a similar problem to mine when moving WordPress from a directory into the web&#8217;s root directory.</p>
<p>What happened was that many links and pictures, some placed in there by plugins, others simply links that were typed in, had failed.</p>
<p>I realised that although I&#8217;d followed the migration instructions, a lot of things were left poorly sorted.  A quick run through of all the tables showed where values were left incorrectly set.  To fix this I wrote the following SQL statements and applied them to my database:</p>
<p>update wp_posts set guid = replace(guid,&#8221;/wordpress&#8221;,&#8221;");</p>
<p>update wp_postmeta set meta_value = replace(meta_value,&#8221;/wordpress&#8221;,&#8221;");</p>
<p>update wp_options set option_value = replace(option_value,&#8221;/wordpress&#8221;,&#8221;");</p>
<p>update wp_posts set post_content = replace(post_content,&#8221;/wordpress&#8221;,&#8221;");</p>
<p>These worked a treat.</p>
<p>To use this yourself I&#8217;ve done a version below that you can edit &#8211; simply replace $$$olddir$$$ with your old directory name (in my case wordpress) and replace $$$newdir$$$ with your new directory name.  If your new directory is the root, remove the / at the beginning of each $$$newdir$$$ &#8211; see my example above.</p>
<p>A couple of warnings though &#8211; <strong>first take a backup of your database!</strong> Then think carefully &#8211; if you don&#8217;t know what you&#8217;re doing you may well be advised in seeking someone out who does.<br />
update wp_posts set guid = replace(guid,&#8221;/$$$olddir$$$&#8221;,&#8221;/$$$newdir$$$&#8221;);</p>
<p>update wp_postmeta set meta_value = replace(meta_value,&#8221;/$$$olddir$$$&#8221;,&#8221;$$$newdir$$$&#8221;);</p>
<p>update wp_options set option_value = replace(option_value,&#8221;/$$$olddir$$$&#8221;,&#8221;$$$newdir$$$&#8221;);</p>
<p>update wp_posts set post_content = replace(post_content,&#8221;/$$$olddir$$$&#8221;,&#8221;$$$newdir$$$&#8221;);</p>
<p>Good luck and have fun!</p>
]]></content:encoded>
			<wfw:commentRss>http://davidcoveney.com/87/resolving-wordpress-migration-issue/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

