How can I allows clients to preview a website before it goes live?
February 27, 2013 7:31 AM Subscribe
One of our clients has a WordPress site running on our IIS Windows server. They want to be able to preview and edit the site before it goes live. How can this be accomplished?
I currently have a couple computers in their office with edited hosts files that allow them to see/edit the new site on those computers, but that solution feels hacky and they want to be able to see the site from any computer. How can I set it up so they can see it from any computer, ideally just by typing in a secret url? Is there something I could put in the server's inetpub/wwwroot folder so they could just type in http://ip.address/something to see the new site?
I currently have a couple computers in their office with edited hosts files that allow them to see/edit the new site on those computers, but that solution feels hacky and they want to be able to see the site from any computer. How can I set it up so they can see it from any computer, ideally just by typing in a secret url? Is there something I could put in the server's inetpub/wwwroot folder so they could just type in http://ip.address/something to see the new site?
I'd use a Coming Soon plugin, and just put it anywhere online. If you're logged in, you see the site, otherwise you get the Coming Soon content.
posted by backwards guitar at 7:49 AM on February 27, 2013 [1 favorite]
posted by backwards guitar at 7:49 AM on February 27, 2013 [1 favorite]
I do the Linux thing, so I'm not sure how well this will translate (though these seem like fairly standard things to me) ...
https://staging.example.com/ -- htpasswd protected
https://dev.example.com -- htpasswd protected
https://www.example.com -- redirects to http://example.com/ which is production
Staging is for what's about to go live, let's the clients mess around and see how things really work. Dev is active development aka HEAD.
posted by Brian Puccio at 8:02 AM on February 27, 2013 [1 favorite]
https://staging.example.com/ -- htpasswd protected
https://dev.example.com -- htpasswd protected
https://www.example.com -- redirects to http://example.com/ which is production
Staging is for what's about to go live, let's the clients mess around and see how things really work. Dev is active development aka HEAD.
posted by Brian Puccio at 8:02 AM on February 27, 2013 [1 favorite]
I use SeedProd's coming soon plugin. It's $50, but you can use it for as many projects as you like. Allows you to set up a passthrough URL so clients can preview; if they log in, they get the usual admin privs. (See under Access Control for other restriction options.) Meanwhile everyone else gets the holding page.
posted by Su at 9:15 AM on February 27, 2013
posted by Su at 9:15 AM on February 27, 2013
You can put the IP address of your dev server as the Site and Blog URL in WordPress' Settings > General. As long as you're not serving multiple virtual hosts on that server (or if the WordPress site is the default site--I haven't configured with an IIS server in quite some time, so I can't offer much direction there, but it should be simple to set the default), it should work fine.
Alternatively, you could publish the site to the live server and use a plugin like backwards guitar suggests. I've used Maintenance Mode with good results in the past. The benefit of this is that the client gets to work on the content on the live version of the database, so you won't have to transfer anything. The drawback is that you'll have to sync your development version with the live site any time you want to modify the theme or plugins... not really that big a deal, since you'll likely have that figured out for continuing updates anyway.
posted by maniactown at 9:16 AM on February 27, 2013
Alternatively, you could publish the site to the live server and use a plugin like backwards guitar suggests. I've used Maintenance Mode with good results in the past. The benefit of this is that the client gets to work on the content on the live version of the database, so you won't have to transfer anything. The drawback is that you'll have to sync your development version with the live site any time you want to modify the theme or plugins... not really that big a deal, since you'll likely have that figured out for continuing updates anyway.
posted by maniactown at 9:16 AM on February 27, 2013
I like Authenticator for this purpose. Prior to that I was using Members Only prior to that but MO did a poorer job handling RSS feeds via feedkey.
posted by artlung at 9:27 AM on February 27, 2013
.htaccess using an HTTP Authentication password would be another way to go.posted by artlung at 9:27 AM on February 27, 2013
Best answer: Comingsoon and other plugins are useful for net new sites, but if you have an existing site at the address they are less useful.
Note that Wordpress needs to know the URL of the site it's running under, so if you set it up as http://staging.clientname.com your content will have a lot of hardcoded links to that URL embedded inside.
This means when it's time to go live, it's not a simple manner of just updating the DNS, you'll need to also change all the content to point to the new host. There's plugins to help with this. It's also really easy to lock yourself out of you site when you make this change.
Wordpress documentation has the details:
http://codex.wordpress.org/Moving_WordPress
While it may feel hacky, the hosts file approach is probably the easiest.
posted by kaefer at 10:14 AM on February 27, 2013
Note that Wordpress needs to know the URL of the site it's running under, so if you set it up as http://staging.clientname.com your content will have a lot of hardcoded links to that URL embedded inside.
This means when it's time to go live, it's not a simple manner of just updating the DNS, you'll need to also change all the content to point to the new host. There's plugins to help with this. It's also really easy to lock yourself out of you site when you make this change.
Wordpress documentation has the details:
http://codex.wordpress.org/Moving_WordPress
While it may feel hacky, the hosts file approach is probably the easiest.
posted by kaefer at 10:14 AM on February 27, 2013
Response by poster: kaefer, that's the exact issue I'm coming up against. They already have an existing site at the correct url.
The wordpress install is already set up to use the correct url, so to launch it all I need to do is update DNS. I'd rather not go mucking through the database with a find and replace to move the site to a from a temporary url, but I suppose if they keep demanding something more elegant than the hosts file trick that's what I'll have to do.
I don't know IIS super well, so I guess I was hoping there was some obscure trick I could pull to make it show the site at a different url and have wordpress somehow play nice with that.
posted by cirrostratus at 11:30 AM on February 27, 2013
The wordpress install is already set up to use the correct url, so to launch it all I need to do is update DNS. I'd rather not go mucking through the database with a find and replace to move the site to a from a temporary url, but I suppose if they keep demanding something more elegant than the hosts file trick that's what I'll have to do.
I don't know IIS super well, so I guess I was hoping there was some obscure trick I could pull to make it show the site at a different url and have wordpress somehow play nice with that.
posted by cirrostratus at 11:30 AM on February 27, 2013
Wait, WordPress bugs out if you change the base URI? Ouch. Sorry, disregard my previous suggestion then. I assumed you'd just change the base URI setting somewhere (something you could automate with a script and integrate with your source code management software; e.g., when finishing off a branch that is the new version/feature) and it would be good to go.
posted by Brian Puccio at 5:59 PM on February 27, 2013
posted by Brian Puccio at 5:59 PM on February 27, 2013
This thread is closed to new comments.
posted by COD at 7:41 AM on February 27, 2013