[wp-hackers] [GSoC 2011] Moving Wordpress

[Mike Schinkel]

Hi Piyush,

You can also look at using this:

http://wordpress.stackexchange.com/questions/119/easily-move-a-wordpress-install-from-development-to-production/182#182

I've been using it very effectively for months, and it is hookable to allow you to do custom migrations.

Hope this helps.

-Mike

On Mar 20, 2011, at 3:32 PM, Piyush Mishra wrote:

> A much better option would be to retrieve those options unserialize >
> replace in php >serialize again and store.
> The problem is when the user wouldn't want to change the domain.
> Should I try to replace domains within post_content (interlinked posts) ?
> 
> On Mon, Mar 21, 2011 at 12:59 AM, Piyush Mishra <me at piyushmishra.com> wrote:
> 
>> Last year I was discussing this on the mailing list and Otto suggested a
>> really good way of allowing this.
>> 
>> function maybe_unserialize( $original ) {
>>       if ( is_serialized( $original ) ) // don't attempt to unserialize
>>       {
>>               $fixed = preg_replace_callback(
>>                       '!(?<=^|;)s:(\d+)(?=:"(.*?)";(
>> ?:}|a:|s:|b:|i:|o:|N;))!s',
>>                       'serialize_fix_callback',
>>                       $original );
>>               return @unserialize( $fixed );
>>       }
>>       return $original;
>> 
>> }
>> 
>> 
>> On Mon, Mar 21, 2011 at 12:15 AM, Brian Layman <wp-hackers at thecodecave.com
>>> wrote:
>> 
>>> On 3/20/2011 2:09 PM, ErisDS (Hannah Wolfe) wrote:
>>> 
>>>> I have a script which does all of the database stuff.
>>>> 
>>>> http://erisds.co.uk/projects/migrate
>>>> 
>>> 
>>> Nice script.
>>> 
>>> I hope you don't mind if I share some thoughts on it:
>>> 
>>> You are taking some steps to replace the GUID for the posts. However, the
>>> GUID value, even if it has the old URL in there, really does not need to be
>>> changed.  In fact it is probably better to just leave it as is.  Your script
>>> would run faster if you didn't bother to change it. (That said, I've done
>>> the same thing in earlier migration scripts of my own).
>>> 
>>> The major issue I see is that you do not unserialize option_value while
>>> you are updating the options table.  The problem with this is that because
>>> serialized strings encode the length of each string value, a simple
>>> replacement will corrupt the entire serialized value.  So if your script is
>>> run on a blog that has "Welcome to blahblahblah.com" in a text widget and
>>> you str_replace it with "Welcome to blah.com", the new site will have
>>> lost all widgets on every sidebar.  This could also be the case for someone
>>> linking to a privacy policy in theme options. If they type in a full URL
>>> instead of a relative url, then you lose all of the theme options.
>>> 
>>> Serialized values are a MAJOR annoyance to anyone who regularly
>>> manipulates the database directly.  This is a very common issue in migration
>>> tools/tutorials. Talking about it here spreads the word...
>>> 
>>> That said, Nice stuff. Thanks for sharing!
>>> 
>>> Brian Layman
>>> http://eHermitsInc.com
>>> Managed WordPress Hosting
>>> 
>>> 
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>> 
>> 
>> 
>> 
>> --
>> Regards
>> Piyush Mishra
>> http://www.piyushmishra.com/
>> Life's Short, Live it to the maximum
>> 
>> 
> 
> 
> -- 
> Regards
> Piyush Mishra
> http://www.piyushmishra.com/
> Life's Short, Live it to the maximum
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers