Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm working with another team member and they are reside in a different US State. We are working to convert an existing static e-commerce site to a Wordpress site.

I want to have a DEV install of Wordpress so that we both can access it easily. I'm going to do the majority of the coding. He will help with some HTML/CSS and a lot of data related work. Either manually entering in items or figure out some import method.

Here are the options that I've thought through and it makes sense to do Option 2.

Option 1

  • Install Wordpress on my laptop
  • Install DB on my laptop
  • Configure my router to allow incoming HTTP requests and redirect them to my laptop
  • When we want to deploy to PROD, follow steps to move code to server, dump the DB and import into DB on server.

The downside of this is that if I turn my laptop off, or if something goes wrong with my cable modem, my partner won't be able to access Wordpress.

Option 2

  • Install Wordpress on server at the current domain in a subdirectory, ex: domain.com/wordpress
  • Install DB on server
  • Password protect the directory to stop someone or some bot that tries to go into the directory
  • When we want to deploy, update index.php

Are there other Options that could also work?

Version Control

I would also need version control. I could put the install under SVN.

How do people version control databases with the code. Ideally they both should be in sync.

share|improve this question
add comment

4 Answers

Hi @milesmeow:

I think you should go with option #3; either of the two other options will lead to heartache in my experience. You'll end overwriting each other's changes and other issues.

Option #3

You both set up local developments environments and you use a Subversion repository to keep things in sync. I use a free account at Unfuddle with gives you two logins and subversion repositories as well as a ticketing system and task and milestone tracking. Unfuddle works well for me but of course there are many other options, Unfuddle is just the one I know that works well for me.

As for the database, it's very hard to manage databases in source control. What you really have to do is write scripts that rebuild your database from scratch and then version them. Ironically I'm working on exactly that for tomorrow and I asked a question here in hopes to get someone to help me but instead it looks like I'm doing it all myself so I am documenting what I'm getting done in an answer. You can read about it here:

While the above question/answer talks about initializing a new database using standard aspects you could actually do the same with existing data, it would just be more work.

Thus far in my development I've always been able to simply do a forklift upgrade of the database but I'm getting to the point I'll need to manage existing data. So it looks like over time I will be building tools to export data to scripts and/or files where I can easily merge new work with current data. Sounds like you need the same. Hopefully others will come along and we can all handle a piece of this problem; as they say: "Many hands makes for light work."

Sadly my answer is not simple regarding the database but as far as I'm aware this has always been an issue for deployment of database-related systems and scripts that you can test and submit to version control are really the only known way to handle it.

share|improve this answer
    
Thanks for the detailed answer. I've yet to find a good method to keep databases under version control and in sync with your code. I may have to teach my partner subversion. I'm still trying to see if he'll need it. He might just be doing data entry or editing the theme files through Wordpress's admin section. I know it's not ideal, so I may need to have him learn version control. –  milesmeow Sep 13 '10 at 19:38
add comment

I would go for Option 2, except that I don't think simply flipping development to production is a good idea.

Map something like beta.domain.com (if you can) with separate database and work with stuff there. When done - transfer files and database to production site.

share|improve this answer
    
The subdomain sounds like a good idea for this first release, and also going forward once we have a live version of Wordpress in production. –  milesmeow Sep 15 '10 at 17:34
add comment

You're looking for staging basically. That's not something Wordpress is very good with, but as it's PHP and MySQL, there are some tools available next to Wordpress that can help with it:

http://stackoverflow.com/questions/432162/does-anybody-have-a-development-staging-deploying-workflow-with-php-mysql

Staging basically means what Mike already described but it ads some sugar on top. I strongly recommend something like a build system to run stuff prior to release. Especially with Wordpress based applications, otherwise expect a lot of hand-work.

The earlier you start to automate stuff (that's something I need to remind myself as well often enough), the faster you can take off.

share|improve this answer
add comment

Definitely option 2.

just a word on source control, would GIT not be more useful with it's better handling of branching?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.