WordPress and GitRob Miller • @robmil

• I’ve been using WordPress since 0.72

• These days I’m Head of Digitalat Big Fish, a branding/marketing/design/digital/etc. consultancy based in West London

• We use WordPress for all our sites

• We’ve been using Git with WordPress for just over two years now

Background

• I first gave a version of this talk at WP London in November

• Turns out: it’s hard to teach people Git in an hour

• So I’m going to focus on WordPress

• What are the things to watch out for if you’re using Git when developing WordPress sites/plugins?

A crashcourse in Git

Git? Huh?

• A version control system (VCS)

• Track changes to your files over time

• Revert to any point in the past

• Branch to work on different features simultaneously

• Great for teams — no need to manually integrate work

Git’s advantages

• Works offline — commit, branch, do anything, without an internet connection and without having to connect to another server

• Fast, fast, fast

• Branching is cheap (and amazing)

Distributed version control

• Git is distributed

• cf. centralised systems like CVS, SVN

• Everyone has a fully functioning repository, with a full history

• There’s not necessarily a central, authoritative repository — forks are first-class citizens

Getting into Git

• Sign up for GitHub

• Read http://gitref.org/

• git init and start playing!

Setting up a WordPress project

• What to ignore

• Dealing with uploads

• What to do with core files

What to ignore?

Configuration files

• Configurations are different between development, staging, and live

• How do you manage these changed configurations without having the changes show up as modifications?

• How do you store configurations (so that new team members have them) while allowing them to be changed if necessary?

• Simplest solution: add your config files to your .gitignore

• Store sample config files that people can duplicate as appropriate

• Works okay, but can be better

• Two better options: switch when a file exists, or switch based on hostname

1. if ( file_exists( ‘local-config.php’ ) {2. require_once ‘local-config.php’;3. } else {4. // Live settings5. define(‘DB_HOST’, ‘localhost’);6. define(‘DB_USER’, ‘example’);7. define(‘DB_PASSWORD’, ‘example’);8. define(‘DB_NAME’, ‘wordpress’);9. }

File-based switching

1. if (2. preg_match(3. ‘/^dev\./’,4. $_SERVER[‘HTTP_HOST’]5. )6. ) {7. require_once ‘wp-config-dev.php’;8. } else {9. require_once ‘wp-config-live.php’;10. }

Host-based switching

• Decide whether having a config file that isn’t tracked is a benefit

• Do individual devs on your team want to make config changes that don’t get checked in?

• You can always do both! Checkfor a file, then fall back to host-based switching

Uploads

• Are uploads code, or content?

• If they’re code, it makes sense for them to be in version control

• If they’re content, it makes sense for them not to be

• But isn’t the answer… both?

• No easy solution

• Option one: ignore them entirely

• Option two: ignore them and add them manually

• Option three: ignore them and try to add them automatically/periodically

• Ignoring them entirely is definitely the cleaner solution

• But it’s untenable for us — we want people to be able to clone a repo and have a working site, not one with broken images everywhere

• So we track them, and periodically add new uploads from live

• Is still ugly, though

WordPress core files

• Put WordPress in its own folder

• Define WP_CONTENT_DIR and WP_CONTENT_URL

• Bingo: you have a wp/ directory that you can happily erase/overwrite without affecting your custom files

• You end up with:

• To submodule or not to submodule, though?

• Submodules are, like SVN’s externals, a way to have a repository within a repository

• Seems tempting, right? Track a tag on the WordPress GitHub, and then updating WordPress is just a git checkout away

• Unless you’re very aware of the caveats: don’t do it to yourself!

• Synchronisation issues — it’s possible for different devs to have different WordPress versions, which is bad

• Conflict resolution is nonexistent

• It generally adds complexity and another point of failure in your process

Core and Plugins

• Dealing with the WordPress.org plugins repository

• Dealing with the core SVN repository

• Generally: bypassing SVN

• WordPress is, for better or for worse (ok, for worse) an SVN ecosystem

• But we can deal with that without having to lower ourselves to using SVN

• git-svn to the rescue

• git-svn is a built-in Git tool

• Allows you to interact with (so checkout, update, commit, etc.) SVN repositories directly in Git

1. # Create the repository from the remote:2. git-svn clone -s http://example.com/svn/3. # Make some Git commits of your work4. git commit -m “Something interesting”5. # Get any new commits from SVN:6. git-svn rebase7. # Create an SVN commit for each Git commit:8. git-svn dcommit

A git-svn workflow

• Although you’re using SVN, you don’t actually have to use SVN

• You get to use all the features of Git — use it offline, branch cheaply, etc.

• You’ve got a Git repository, so you can use GitHub to collaborate with others

• Nobody needs to know you’re using Git; externally, it just looks like SVN

What does this mean?

• Another option worth mentioning:

• Just using them both at the same time

• Ignore .svn in Git; ignore .git in SVN

• Commit to each one independently, as and when you please

• So maybe use Git for actual VCS and SVN only for releases; YMMV

• What about when you don’t have commit access, though? (e.g. core)

• You can still generate patches from Git

• git diff --no-prefix > ~/feature.diff

• Generates an SVN-compatible diff that can be applied, as normal, with patch -p0

• To make it the default:

• git config --global diff.noprefix true