[wp-hackers] Site Address during development
mikeschinkel at newclarity.net
Thu Sep 2 15:34:10 UTC 2010
I've had exactly the same problem so I wrote a plugin to address it. Please take a look:
It's goal is to provide a one-click content migration process in the admin. To enable it you "register" all the data about your different hosts in /wp-config.php. Below are examples of the standard information that can be registered but anything that is different can be included such as Google Map API keys:
'database' => 'example_db',
'user' => 'example_user',
'password' => '12345',
'host' => 'localhost',
'sitepath' => '', // '' if WordPress is installed in the root
'name' => 'Example Local Development',
'host' => '127.0.0.1:3306',
'domain' => 'example.dev',
'rootdir' => '/Users/mikeschinkel/Sites/example/trunk',
'name' => 'Example Test Server',
'rootdir' => '/home/example/public_html/test',
'domain' => 'test.example.com',
'name' => 'Example Staging Server',
'rootdir' => '/home/example/public_html/stage',
'domain' => 'stage.example.com',
'name' => 'Example Live Site',
'rootdir' => '/home/example/public_html/',
'password' => '%asd59kar12*fr',
'domain' => 'www.example.com',
It is designed to do the standard migrations that have been discussed on this thread but be hookable so any new migration needed because of a new requirement introduced by a plugin can quickly be coded and incorporated into the migration process. And it can migrate the content from all servers to the current server based on the current URL.
It works by replacing DB_HOST, DB_USER, DB_NAME, DB_PASSWORD, etc. in /wp-config.php because it sets those for you based on the current site's URL matching one of the defined hosts. But you can easily revert back to standard all DB_* defines at any time by just commenting the host registration code out or deleting it and putting the DB_* defines back in page. Note that Nacin (or maybe it was Lebens) saw this at WordCamp Savannah and reacted that end users would be confused by rootdir, which is optional (of course if it's not provided you don't migrate things like upload direction.) So realize this is NOT for end users; it is designed for professionals like those who commented on this list who need to work with dev, test, stage and production servers and it can go away when the project is done if that's what's appropriate.
A writeup about it is here:
Would love to have all of you who are struggling with this to try it and to get your feedback on how well it resolves your use-cases.
On Sep 2, 2010, at 10:48 AM, Michael Clark wrote:
> At 9:30 AM -0500 9/2/10, Otto wrote:
>> On Thu, Sep 2, 2010 at 8:09 AM, Alex Hempton-Smith <hempsworth at gmail.com> wrote:
>>> This is always an ongoing issue for me. Any tips would be great!
>> One easy way that we use: Don't use development URLs, use the real
>> URLs. Just repoint them to your development server.
>> Edit your hosts file, and add a line like this:
>> 127.0.0.1 example.com
>> Then set up WordPress on your local machine using the example.com URL.
>> When you're ready to move it to the live server, delete the line from
>> the hosts file and just move the whole thing over. All the URLs will
>> still say example.com in them, it's just not pointing to your local
>> machine any more.
> This won't work when the client is passing the URL around to their Board of Directors or employees. It's not reasonable to expect many people to change browser or Internet settings, vs simply giving them http://dev.example.com/ .
> But I am glad to see I'm not the only person who is frustrated by this situation. Thanks to Matthew for the MySQL pointer and Codex link. Mike
> Michael Clark
> Christmas Music 24 Hours a Day, 7 Days a week
> "Injustice anywhere is a threat to justice everywhere."
> - Martin Luther King Jr.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers