I've been around the web for ages, but haven't built any sites for a few years, am rather rusty at the moment, and also am somewhat new to Wordpress, php etc. (I did build one site recently using Concrete 5 but it seems worth it to master Wordpress.)

So, this seems like a dumb question, but I can't find the answer to it anywhere. I'd like to create and maintain a development site, but have a separate live "public" site version elsewhere. In other words, I want my regular site, but also want a place to safely test things before making them go live. How can I do this (i.e. copy all files over? Or?)

I've set up the development site at myclientsite.mymaindomainname.com/wordpress/ .... The live site will be at myclientsite.com (or better, resolving to that domain but living in myclientsite.com/wordpress/ ).

Is this just a simple matter of copying all of my Wordpress files & SQL databases over to the live directory? Or should I set up everything in one place because there's some other way to save versions (other than just backing up)?

Sort of. There will also be a few config settings which will be unique to the dev and live sites. at minimum, this is usually something like an absolute path, DB connection settings, and possible .htaccess

i've implemented this by using a git rep which pushes to both, then a separate branch with a single commit consisting of any customisations as mentioned above, which rebases onto the master branch each time its updated.

(01-03-2012 07:07 PM)bobocat Wrote: Sort of. There will also be a few config settings which will be unique to the dev and live sites. at minimum, this is usually something like an absolute path, DB connection settings, and possible .htaccess

I feel comfortable getting the separate database connections set up. I'm less clear on absolute path and .htaccess. (Right now I am on the standard DH hosting plan - does that make a difference? On my prior hosts, it was easy to find .htaccess, I'm not sure where to find it now.)

Quote:i've implemented this by using a git rep which pushes to both, then a separate branch with a single commit consisting of any customisations as mentioned above, which rebases onto the master branch each time its updated.

The above info is over my head right now, although theoretically it makes sense. Could you provide some more details? Thanks.

Any more clarifications or ideas would be welcome. And, I'm curious, do most WP users just fly bravely with one live site? (i.e. no dev area?)

Sorry, I was speaking in general. I haven't done it in over a year with WP, but I do a similar thing with another site. Those are just the types of things you'll need to watch out for. After I set up WP the way I wanted, I abandoned the dev site. It's just a personal blog, so no big deal.

The hardest part that I remember is if you add a new plugin or something to the dev site, then you'll likely have changes to your DB which will make it differ quite a bit from the live site. And if your live site has comments, then syncing them becomes a pain unless you're will to track down which tables should be added, which should be synced, and which should be left alone. It becomes more trouble than it's worth in my case.

This site is going to be for a business - kind of a portfolio/brochure site. And, we don't plan on having any comments, except in the blog area, which would only be on the live site, so that wouldn't be a problem. That said, I'm just nervous about having one single live site --- because it is a worldwide business (not just my personal blog). What happens if I really screw up and the whole thing blows up!? In my early experiments, I've already managed to completely and utterly disable some of my test sites for a day by messing around with the databases...I figured that out, and they are up again, but it made me realize how fragile it can be to put all of your cards in one basket, so to speak. So I'm trying to figure out how others deal with this issue. Or is it a non-issue? Ie. I should just forge ahead with one site?

it takes a bit of effort to learn, but i think it's worth it. i started off with svn which is ok, but after changing over to git, i would never go back.

however, it won't do revision control of your db... you can add a copy, but it won't be able to show you the changes/differences unless it's in a text format (.sql for example). i wish i knew a better way to handle DB revision control myself.