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 know this question has been asked a thousand times, but I'm really trying to work out how to get the best out of Git when working with WordPress.

I've scoured the web and read dozens of articles, all that seem to cover the topic briefly. Here's a few of the most notable one's I've read recently.

- Version Controlling WordPress

- Managing WordPress Theme Deployments with Git

- Manage your custom WordPress theme using git instead of FTP

Currently, my workflow looks like this.

  • Install WordPress locally
  • Develop Theme
  • Export WordPress Databases from local server
  • Import WordPress Database to remote server
  • Upload WordPress files and theme via FTP
  • Client makes changes
  • Download WordPress files and theme via FTP and export WordPress Databases from remote server
  • Replace files locally
  • Make development changes
  • Re-upload via FTP, export and import database to remote server

I realise Git can streamline this process. It seems the best way to do this is to have a .gitignore file that ignores certain directories that don't need to be tracked, as well as having both a local and remote wp-config.php file.

But how do you handle the databases? Clients will usually make changes (posts/pages/plugins). Do I still need to export from the remote database and import back on my local server?

Can someone suggest the best workflow for me here? And walk me through the steps.

Also, I'd probably like to use Bitbucket as private repos with them are free, unlike GitHub.

Any help would be appreciated.

Thanks in advance!

share|improve this question
    
How did it go? Did you figure it out? Having the same issues here. –  qwerty Apr 25 '13 at 8:45
3  
Could you focus your question a bit? You ask about git, but then jump to databases and git is not a tool for dealing with those essentially. –  Rarst May 12 '13 at 14:34
3  
I think you question is valid. I have the same workflow and by talking to other developers noticed that they also have the same workflow. But it's really time consuming, and opens a lot of room for error. I would also be interested in a better solution. –  gdaniel May 14 '13 at 16:25

6 Answers 6

I'm one of the developers of WP Migrate DB Pro, and would like to answer @Ennui's question:

"Do you know if the db url replace script it runs takes into account serialized strings?"

Yes, it does handle serialized data. In fact, that is the primary reason I developed the free version of the plugin back in 2009. :)

Unfortunately I only have a reputation of 41, so couldn't reply to @Ennui's comment. Sorry for that.

share|improve this answer
1  
Got 50 now :) Great plugin man. –  Andrew Bartel May 17 '13 at 14:57

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

I haven't tried this myself (yet), but it claims to deploy everything -- DB included.

There is also a tutorial to go with it: Tutorial part 1 | part 2

share|improve this answer

I am borderline on voting to close this as "not constructive" as it seems to be the kind of thing that will solicit debate and opinion rather than answers. But...

That is not what my work flow looks like, and it makes my approach (and answer) different from most of the rest of the answers so far.

  1. Install WordPress locally
    1. This is cloned from a local bare Git repo containing the latest stable release.
    2. I also keep a local copy of the latest release of a few plugins that I nearly always install.
  2. Build the theme and any plugins necessary
  3. Upload to a public staging server
    1. The client is given access but can't change the code and it told that database edits will not be transferred to the production site.
    2. This means that there is no reason to download the code back to the development server.
    3. And no reason to resync the local database
  4. Make changes to the local site based on our staff and the client's feedback.
  5. Upload changes
  6. Repeat as necessary (but with increasing resistance :) )
  7. If we are providing content, which is not always the case, we (not the client) will clean the database on the staging server and upload content.
  8. Deploy by uploading the local code to the production site.
  9. If we have created content, the content is exported from the staging site via the vanilla export tool and imported into the production site.
    1. This is the only time I have to move the database, and it is done with pretty standard tools. I will use Velvet Blues Update URLs to clean up the database if needed.
  10. Debug
  11. The end

Basically, I keep the client away from my stuff as much as possible until we hand over the site.

Code moves one way-- from local to either staging or production. It never moves the other way. That eliminates some of your steps and give me some peace of mind. I do not want to be blamed for the client's tinkering in my code and I don't want to import some hacked file, which is a non-zero possibility.

And the database only moves once, if at all, which greatly reduces the problem. So I guess I manage the "database moving" problem by reducing or removing the need to move the database. It also reduces database corruption issues that can arise and reduces the chances of importing a hack.

True, I do have to configure the production site-- permalinks, menus, etc.-- but that forces me to work on the production site so I consider it a kind of debugging. It helps me confirm that things work on the production site the way they should.

share|improve this answer

Regarding the database "cloning", I use WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

It's a paid service, but doesn't cost much, and easily allows you to pull or push your database from your dev to your live server and vice versa. It changes the URLs and everything else that needs changing on the way.

share|improve this answer
1  
Do you know if the db url replace script it runs takes into account serialized strings? A simple update query to replace the url is bad because it breaks any serialized string with a URL in it (unless the new URL is the same number of characters as the old URL which is rare to say the least). This breaks text widgets and many plugins among other things. I use this script right now but I'd be interested in this plugin if it does the same thing. –  Ennui May 17 '13 at 13:21
    
I've just emailed the developer to come along and answer that question. I haven't had the need for that (yet). –  deadlyhifi May 17 '13 at 14:04
1  
I use this plugin for all my migration needs and have yet to see any issues with serialized strings and the url replace. All custom fields transfer over no problem. Keep in mind it replaces EVERYTHING by default. This includes users/passwords/etc... –  hereswhatidid May 17 '13 at 14:18

I recently did a lot of testing regarding this and here is the workflow I use, which does pretty much what you're asking for:

  • I use wp-cli to manage the wordpress core and update wordpress.
  • I use composer to http://wpackagist.org to manage plugin and theme dependencies.
  • I use git and put core files in the .gitignore. So mostly config and child theme files are in git.

I'm not familiar with the db migration tools but would be a great addition to this workflow.

Here are the full details on the workflow http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

share|improve this answer

Take a look at the bedrock stack. It uses composer to manage the version of Wordpress and third party plugins, and also includes capistrano for deploys, and vagrant / ansible for setting up servers including local virtual servers for development.

share|improve this answer

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.