[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

[Marcus Pope]

Ok, Mike if faking a dev name length to match a production name length is the *right* way to do it, and if you can't envision a potential scenario where your staging url or TLD couldn't possibly match the same length as your production site, then maybe you'll at least concede that it's an extra step that doesn't have to happen if we used root-relative urls.

But even still the search and replace of content is only half the problem, there are a world of other issues that are a direct result of storing absolute urls in the database.

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Mike Little
Sent: Friday, October 28, 2011 4:16 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

On Fri, Oct 28, 2011 at 20:54, Marcus Pope <Marcus.Pope at springbox.com>wrote:

> > Relative URLs are great until they don't work: the RSS issue is
> significant.
>
> Mickey, wordpress processes all of your urls every time you host your 
> page or export via rss/email.  What we propose is that you only need 
> to process those URL's when you export via RSS, via a simple function 
> call.  They are always considered as a use case with this concept and 
> are not broken when you choose to host via root-relative ulrs.
>
> Additionally there are things that don't ever make it into an rss feed 
> that are still forced and munged into an absolute URL like local css 
> and javascript files.  These create headaches when moving through 
> staging environments for enterprise developers.
>
> > When I migrate, it means search-and-replace in the database
>
> And that will break your serialized data if any of your plugins encode 
> data that way or if your site uses any widgets.
>
>
If that happens you are doing it wrong.

I search and replace database dumps to copy from dev to test, or production to dev, every day. None ever break.

Here's a tip: in dev, fake a same length domain name (theclientsdomain.bom instead of theclientsdomain.com) in your hosts file, in test (that needs to be publicly hosted so the client can access it) make sure it's on a same length domain. (get yourself a really short (4- or 5-char) domain so you can create almost any length domains. I own z1.tl so I can host theclientsdoma.z1.tl.
As long as it matches the length of the live domain, search and replace won't break.

And as Otto hinted at, the real important trick is nothing to do with domains. If you take a copy of production data, the hard bit is mangling the user's real names and email addresses in the user database so you don't expose the private data to test or dev staff, or nearly as bad, kick off an email to 20,000 users for "my test post I just published"

Mike
--
Mike Little
http://zed1.com/
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers