17

I'm looking for a strong streamlined workflow idea for working with Wordpress.

  1. Would like to have my git environment on my own server internally, not using Github to handle repos.
  2. Automatic creation of subdomains upon git branch creation (development.domain.com , ryan.development.domain.com) - Probably some shell script hook would be ideal for this.
  3. Phing PHP/Shell script Handling of the db migration (something like this http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) to handle serialized database replacement upon pushing

Operation would probably go something like this:

  1. getting the current latest wordpress version and branch it out, name of the branch gets a subdomain entry (branchdevelopment.domain.com)
  2. submodule the theme you desire if it's available (i'd like to make my own git repo for this, as I use thesis I'd like to have a blank thesis git repo setup to grab from internally on the server that's already been created)
  3. checkout and make changes , client reviews, once it's pushed to live, the database script will then kick in automatically changing the serialized url values from localhost (or subdomain) to the live url

Is this possible? I've heard Capistrano is also good to utilize with this but not sure how Capistrano entirely works.

I run about 200 sites on my own server and would like to start implementing these sites into a strong git workflow environment so i can streamline my work alot better. As of right now, I basically download an image of the site and work on it locally then upload the changes back to the server. This is very tedious in this day and age.

Does anybody have any solutions regarding this type of workflow / has worked with this in the past? If so, some resources / answer would be greatly appreciated.

  • 3
    Why not use bitbucket as they have unlimited repos for free? – Brian Fegter Sep 10 '13 at 5:50
  • 2
    Search replace has a cli version if you checkout the github repo, you can use that, though I can't comment on how you get the various URLs and parameters to pass into it – Tom J Nowell Sep 11 '13 at 14:59
6

General Questions answered

Nr.1. Would like to have my git environment on my own server internally, not using Github to handle repos.

The first thing I'd do is to check out composer and how it works with WordPress, which is a project by Andrey "@Rarst" Savchenko.

Nr.2. Automatic creation of subdomains upon git branch creation (development.example.com, ryan.development.example.com) - Probably some shell script hook would be ideal for this.

This is something out of scope for this site. Either ask for help on StackOverflow or ask at your hoster. Some hosters don't allow to edit these entries yourself.

Nr.3. Phing PHP/Shell script Handling of the db migration (something like this http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) to handle serialized database replacement upon pushing

I'd set up a multisite/network install. This allows to easily manage all the tables, keep the users in a central place, etc.

WP Gear - a project by Robert "@Wyck" Ellison - has a list of alternate build scripts. Including WordPhing written by himself. @TomJNowells/Interconnect.it script so far isn't in that list.

Operation Questions answered

Nr. 1. getting the current latest wordpress version and branch it out, name of the branch gets a subdomain entry (branchdevelopment.domain.com)

Not sure why one wants to do this: A subdomain for each branch. When you look at the synced WordPress GitHub repository and the list of branches, then you'll see that every branch is named X.Y-branch. So your subdomains would get named for e.g. 3.6-branch. I'm not sure if a subdomain is allowed to start with a digit (it should be, but ask your hoster) and then there's the problem that you'd get a sub-subdomain named 6-branch, which has a sub-sub-subdomain named 3 and another one named 2. And guess pairing 2- and 3-version branches in a subdomain isn't what you want to achieve.

In short: Just checkout 3.6-branch if you need to switch branches.

Nr.2. submodule the theme you desire if it's available (i'd like to make my own git repo for this, as I use thesis I'd like to have a blank thesis git repo setup to grab from internally on the server that's already been created)

Thomas "@toscho" Scholz has written a nice plugin that allows us to use a subdomain to handle themes outside the WordPress directory. You can find it in this answer as well as in this one. Even automatic updates will work for themes since WP 3.6.

You can do the same for MU-Plugins and Plugins by simply setting the following constants in your wp-config.php file:

define( 'WP_PLUGIN_DIR',   'path/to/your/plugins.dev/folder/plugins' );
define( 'WP_PLUGIN_URL',   'https://plugins.dev/plugins' );
define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' );
define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' );

Now simply put all your plugins and themes under version control and push them onto your server. You can easily make them all available using either mu-plugins or default plugins that get network activated.

Nr.3 checkout and make changes, client reviews, once it's pushed to live, the database script will then kick in automatically changing the serialized url values from localhost (or subdomain) to the live url

If Toms script/plugin doesn't help you so far, then be told that he accepts pull request on GitHub.

  • 2
    In 2 months I attend this site, I understand that "I'd set up a multisite/network install" is your favourite sentence :) – gmazzap Sep 11 '13 at 15:43
  • @G.M. hehe :) Yes, it is. Generally speaking, I don't even understand why we still have single sites. With a network install, your main domain/site actually is the exact same as your single site install. You just get a lot of options and possibilities on top of it. – kaiser Sep 11 '13 at 15:47
  • Generally speaking I'm agree. Reasons to have single site install are: 1) limited server access 2) the great part of existing code (plugin, themes, snippets) doesn't work properly or have issues with newtwork installs. So if you don't/can't write code by yourself and you actually don't need a network inslall, use a single install is preferable. – gmazzap Sep 11 '13 at 16:02
  • 1
    If Toms script doesn't work, there is a full feature Serialized parser in PHP userland available called Serialized. – hakre Sep 11 '13 at 20:46
  • @hakre As always: Please just edit my question :) – kaiser Sep 11 '13 at 21:55
3

No time to write a full feature answer (I know sort of lame) but probably worth to share anyway (I might edit this because I plan a blog-post on this as well):

That means you can have some trunk/version-branch based WP setup that you can fully hack incl. themes and plugins.

As this is one independent (local) repository, you can push this via ssh to other repositories, for example one:

  • That sits on the remote host where the site should be deployed at (bare repo).
  • That has hooks to make another repository on that host actually merge in the changes you just pushed.

This is outlined in A web-focused Git workflow (Nov 2008; by Joe Maller).

If you then have a configuration switcher that chooses the concrete wp-config.php based on the system it is running on, you can even centrally configure all hosts (development, live, staging, friends, ...) inside the repo.

Upstream changes in WP you do just fetch and merge in the subtree.

Plugins you just update and commit.

Deployment is a simple $ git push remote.

Run daily backups on the remote host for the git repos, the database and the uploaded files and this is cheap, developer friendly and flexible. This works well for single-developer setups as well as for small teams because everybody can checkout from the bare repro on the remote.


There are some caveats:


Now with your checklist and the setup as outlined above:

1. Would like to have my git environment on my own server internally, not using Github to handle repos.

Github only handles upstream repos here (Wordpress), not your own one.

2. Automatic creation of subdomains upon git branch creation (development.domain.com , ryan.development.domain.com) - Probably some shell script hook would be ideal for this.

The setup as outlined is a modular approach with one repo per site. It can handle as many development hosts as you like, it might equally work well with a multi-site install to handle multiple domains, but that would count as one wordpress setup in this approach.

3. Phing PHP/Shell script Handling of the db migration (something like this http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) to handle serialized database replacement upon pushing

This is not needed here as only the code is under version control, the databases are independent between development (, staging) and production as it should be.

You might be looking for an install script that does the domain migration right, but even with better code (that is available) dealing with serialized data search and replace, in this setup here it is normally not necessary as you just push the changes to live, for the test-cases you can quickly create the content in the development database, that is normally the smallest problem (from my practical experience, yours might differ, but I would also suggest to keep such database-migration related topics on questions of it's own here on site - but please ask them).

I run about 200 sites on my own server and would like to start implementing these sites into a strong git workflow environment so i can streamline my work a lot better.

I can not imagine how those sites would become under a string git workflow environment. Perhaps the configuration scripts and configuration data you manage here will be kept under git version control. That could make sense. Otherwise by the sheer amount of sites I think it makes no sense at all to keep all those in one git repo. Perhaps not even one of those because what I outlined above is for sites you develop (incl. the WP core code), not just for installation tasks. So you probably need to first of all create yourself some little map of those 200 sites and how they interact with each other and out of which packages (WP core, Plugins, Themes) those sites consist. First thing could be creating a spreadsheet / matrix and put all sites in.

You can then save it as CSV, put it under version control and make the deployment scripts do their work based on that file.

And if I've learned something with automating tasks: Follow the Unix philosophy, use the existing and well working tools (it's better to spend half a day reading about some commands then trying to search for alternatives because for most jobs, the problems have been solved already) and focus on command-line tools. They are most powerful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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