[wp-hackers] Site Address during development

Christopher Bratlien chrisbratlien at gmail.com
Thu Sep 2 15:44:10 UTC 2010


FYI, the example code I posted above works in the RSS feed too. I just
double checked. Feel free to download the plugin I referenced if you would
like to try it too.

Example:

http://dev-thematic.bratliensoftware.com/wp-hackers-test/

See the Taj Mahal picture? In the content box, I used the Media Uploader,
and when I hit Publish, my example code rewrote the URL in the content box
to look like [url]/wp-content/uploads/2010/09/pThumb57JiND.jpg

Now, checking the RSS feed (http://dev-thematic.bratliensoftware.com/feed/)
the image URL shows up as
http://dev-thematic.bratliensoftware.com/wp-content/uploads/2010/09/pThumb57JiND-300x225.jpg

So I guess shortcodes must work in RSS feeds too.

Cheers
Chris

On Thu, Sep 2, 2010 at 10:34 AM, Mike Schinkel
<mikeschinkel at newclarity.net>wrote:

> Hi All,
>
> I've had exactly the same problem so I wrote a plugin to address it. Please
> take a look:
>
> http://mikeschinkel.com/downloads/wp-migrate-webhosts-0.5.zip
>
> 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:
>
> register_webhost_defaults(array(
>  'database'  => 'example_db',
>  'user'      => 'example_user',
>  'password'  => '12345',
>  'host'      => 'localhost',
>  'sitepath'  => '',        // '' if WordPress is installed in the root
> ));
> register_webhost('dev',array(
>  'name'      => 'Example Local Development',
>  'host'      => '127.0.0.1:3306',
>  'domain'    => 'example.dev',
>  'rootdir'   => '/Users/mikeschinkel/Sites/example/trunk',
> ));
> register_webhost('test',array(
>  'name'      => 'Example Test Server',
>  'rootdir'   => '/home/example/public_html/test',
>  'domain'    => 'test.example.com',
> ));
> register_webhost('stage',array(
>  'name'      => 'Example Staging Server',
>  'rootdir'   => '/home/example/public_html/stage',
>  'domain'    => 'stage.example.com',
> ));
> register_webhost('live',array(
>  '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:
>
> http://wordpress.stackexchange.com/questions/119/
>
> 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.
>
> -Mike
>
> 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
> > http://www.PlanetMike.com
> >
> > Christmas Music 24 Hours a Day, 7 Days a week
> > http://www.ChristmasMusic247.com
> >
> > "Injustice anywhere is a threat to justice everywhere."
> > - Martin Luther King Jr.
> > _______________________________________________
> > 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
>



-- 
Chris Bratlien
I write code (so you don't have to)
 http://chrisbratlien.com | 1-979-229-5685 | Skype: chrisbratlien


More information about the wp-hackers mailing list