Just how does a team of 2+ people go about collaborating on WordPress site development? That’s something I’ve been fooling around with over the last while now.
Having used Git and SVN for programming work, it seemed like a no brainer that this was probably the way to go. SVN has fallen out of favour these days, and I also have moved on to Git.
Collaborating on WordPress theme development.
So far this is what I have come up with. I will not get into how git was set up, lets just say it was awkward, and thankfully the web hosting companies are starting to come around to the fact that people want this installed on their webhosts. So, magically a git system is on place so that all developers can push to the webhost.
Then next thing I set up was a .gitignore file, I can not remember where I grabbed this template from but it is pretty self-explanatory if you can read .gitignore files:
# This is a template .gitignore file for git-managed WordPress projects. # # Fact: you don't want WordPress core files, or your server-specific # configuration files etc., in your project's repository. You just don't. # # Solution: stick this file up your repository root (which it assumes is # also the WordPress root directory) and add exceptions for any plugins, # themes, and other directories that should be under version control. # # See the comments below for more info on how to add exceptions for your # content. Or see git's documentation for more info on .gitignore files: # http://kernel.org/pub/software/scm/git/docs/gitignore.html # Ignore everything in the root except the "wp-content" directory. /* !.gitignore !wp-content/ # Ignore everything in the "wp-content" directory, except the "plugins" # and "themes" directories. wp-content/* !wp-content/plugins/ !wp-content/themes/ # Ignore everything in the "plugins" directory, except the plugins you # specify (see the commented-out examples for hints on how to do this.) wp-content/plugins/* # !wp-content/plugins/my-single-file-plugin.php # !wp-content/plugins/my-directory-plugin/ # Ignore everything in the "themes" directory, except the themes you # specify (see the commented-out example for a hint on how to do this.) wp-content/themes/* # !wp-content/themes/my-theme/ !wp-content/themes/responsive-child/
In addition you will need to add a few lines to your .htaccess file in your git directory to deny access to your .git folder, something like:
# Deny acess to '.git' folder RedirectMatch 404 /\.git
So that takes care of the files you are all working on. Each developer has their own LAMP / XAMPP stack. Designs on their local machine and pushes features to the webhost. All done …like fuck you are!
Collaborating on the WordPress Database
Yeah you’d forgotten that WordPress is a data driven web application? I am still working on this part. Have not quite figured it all out. If you have tried migrating a WordPress installation by hand then you will know it’s not as simple as copying and pasting. WordPress has the web address embedded all over the database and will quickly choke to death if this is not accurate. Even renaming it’s folder will kill it. In addition, various plugins use the machine installation directory, as well as the web directory, and save those strings all over the database. It really ain’t pretty.
Putting the WordPress Database into Git
One thing you could is write scripts to run mysqldump and mysql in git’s pre-commit and post-merge scripts. This would dump out a wordpressDB.sql file into your git directory, and changes could be tracked and merged?
Of course you would need to change all the strings in the sql file between the different installation environments for each machine. Oh and do not forget that WordPress uses php serializable strings in the database, so simple search replace will break the database.
After some searching I found the amazing tool WP-CLI. Wow, this is great! Look it up. You can automate all kinds of things with wp-cli. It also has functionality to search-replace in the database whilst rewriting the serializable strings correctly =)
…I have not yet written any of those scripts yet.
What about all developers just sharing one database?
This is my latest stop-gap solution before something perfect is created. Make your webhosts WordPress database publicly accessible (I know GoDaddy allows this for sure anyhow). Then all use a copy of the webhosts wp-config.php file to connect to the same database by each developer.
In this way, they use their own local files, but everyone shares the same remote database. Now, I know what you are thinking: “Ros! you mad fool! what about all those strings in the database??? this will never work perfectly!” Well you are probably right, but it just might work well enough with a few small changes. So far this has got me a somewhat working solution, but it is far from field tested.
Each wp-config.php file gets the following defined for each WordPress installation using the database:
define ('WP_HOME', 'http://localhost/development-site/');
define ('WP_SITEURL', 'http://localhost/development-site/');
, where the URLs are changed to wherever WordPress is running from locally. Boom! We’re halfway there.
Now if you go uploading media files from your local install, they will have addresses like “http://localhost/…/uploads/mediafile.jpg” and will not exist on the webhost! As they were only uploaded to the local webserver. That shit ain’t gonna fly. Guess what? What Ros? This is really dumb but it might just work: stop the developers from logging in to their local admin altogether? That way if you want to do something that changes the database you got to do it through the webhost’s copy of WordPress.
Implementation is easy, just overwrite “…/wp-admin/index.php” with a nice friendly message telling whoever tries to log in to use the webhost to log into WordPress admin instead.
Will this work? Am I dumb? Maybe not dumb enough!!! Of course plugins are going to need some special treatment. Can only be installed on the webhost. Need to be synced to local development installs, could do that during git pulls from the webhost. The “special” strings may/will be an issue, but that depends on the individual plugin. Solve it on a case by case basis?
Conclusion
There is no conclusion. This is a work in progress, but unfortunately I may not be back to WordPress collaboration for a while. Maybe you have some suggestions? Leave em in the comments so.