[wp-hackers] WP Development & Production Sites

[Otto]

On Sun, Nov 28, 2010 at 12:12 PM, Vid Luther <vid at zippykid.com> wrote:
>> Add output buffering and rewriting to dev/staging to rewrite the urls and make dev/staging believe they live at the real address for the purposes of url insertion.
>>
>
> can you point me to a blog post pointing to how to do that?

Okay, let's say your production site is live.example.com and your
staging site is stage.example.com.

On your staging site, you set it up to think it's the live site, with
the live URL. This is to make it identical in content and database and
such with the live site.

Then, in some file that is not going to the live site (wp-config, any
plugin, etc), you'd do something sorta like this:

ob_start('my_callback');
function my_callback($out) {
  return str_replace('live.example.com', 'stage.example.com', $out);
}

Output buffering. It's easy.
http://php.net/manual/en/function.ob-start.php

-Otto


>
> Here is what I'm doing..
>
> wp-config.php includes an "autopress.php" file, which has the following settings, WP_HOME, and WP_SITEURL,
> so all the links on the staging server can point to the right url automatically. The problem is when a client uses the staging environment to seed the content before they go live with a redesign, or a migration to WordPress.
>
> Then all the images that are uploaded, and all the references to said images point to stage.clientname.com..
>
> To address this issue, currently I just go through a checklist, and one of the items in it is to do a mysqldump from stage
> and then run:
>
> find . -type f -name "*" -exec sed -i 's/stage.clientname.com/productionurl/g' {} \;
>
> This addresses some of the lazy theme developers I've run into who hard coded things as well, copy the files to production, and then load the db.
>
> Am I correct in thinking you're suggesting a plugin for staging environment, that knows the site is currently in dev mode, and thus rewrites all image urls to the browser in dev mode, but store everything in the db as if it was production? (this way the plugin doesn't need to be active in production, and thus reducing the need for another conditional check?)..
>
> One could technically make the argument that this environment could be in production as well, if the opcode cache is enabled, this value shouldn't need to be computed on every page load.. kinda like how symfony/ror and other heavier frameworks handle different environments..
>
>
>
>> The database can always reflect the real site address for even when in dev/staging however it is accessed.
>>
>> Cheers
>> --
>> Peter Westwood
>> http://blog.ftwr.co.uk | http://westi.wordpress.com
>> C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>