WordPress 3.8.2, a security release, came out yesterday. Now, if you’re already on WordPress 3.8, your WordPress installation will most likely automatically update, but if you are using Git to manage WordPress as a submodule, and have auto-update disabled, you have to do that manually.
That said, it’s still super easy to do. It definitely outweighs not having a version control system.
Let’s look at the Git commands required to update WordPress from 3.8.1 to 3.8.2. Note that this will work for updating any version.
I’m working on updating several WordPress sites. Part of each site’s update includes converting the WordPress core and all frequently used plugins to Git submodules. While many recommend staying away from submodules all together, I’ve been using them for a while now and never had any issues, that is, until today. Luckily, it’s nothing severe, and in my case, pretty straight forward to fix (once you know the solution), but because the error didn’t make any sense, I’ve decided to document it here.
The main problem is that I’m unable to checkout the
master branch after adding the submodules on the
develop branch. Git complains with the following error:
error: The following untracked working tree files would be overwritten by checkout
That said, let’s look at the problem in detail and how we can solve it.
In a previous blog post I discussed how best to manage file and folder permissions when deploying with Git, but today I’ll show a specific example of what that
post-receive hook might look like for a WordPress project that uses submodules.
I have three servers that I can deploy to, but the
post-receive hook only deploys a project when it encounters the specified branch as defined per server:
- QA waits for a release branch
- Staging waits for the master branch
- Production waits for the master branch
Other than this small difference, the
post-receive hook is identical on all three servers to reduce maintenance.
Lastly, each server has two repositories per project:
- Bare repository – storage unit that uses a
post-receive hook to deploy the project.
- Working repository – web root that will serve the project to the end-user.
This method has several benefits:
- View a combined list of all version-controlled projects via the
- Recover a corrupted web root by cloning a fresh copy from the origin.
- Prevent some issues that may occur during the deployment, since it will fail before post-receive hook is fired.
I received a snippet of code from my good friend Jason today. It goes into your
.bash_profile and what it does is add two pieces of information to your Bash shell prompt when you’re in a Git working directory. With it, you’ll be able to tell:
- Which branch you’re currently on and
- Whether the branch has untracked changes.
The code, now compacted, looks like this:
export PS1='\[email protected]\h:\[\033[1;34m\]\w\[\033[0;33m\]$(git branch 2> /dev/null | sed
-e '/^[^*]/d' -e "s/* \(.*\)/[\1$([[ $(git status 2> /dev/null | tail -n1) !=
"nothing to commit, working directory clean" ]] && echo "*")]/")\[\e[0m\]$ '
Note (added on 5/19/14): I added two manual line breaks to the snippet above for readability, so if you are copying and pasting it, make sure everything ends up on one line. You can also, as Henry suggests, add a line continuation character to the end of the first two lines.
“Holy Halloween, Batman!” is what I thought when I initially saw this, but after a good bit of research, it all made sense. I set off on a mission to be able to explain every character in this one-liner. Hopefully, after you read this, you’ll be able to modify your prompt to meet your needs and feel comfortable creating your own variation of it.
I use Git as a version control and deployment system. When a website gets pushed to a server, all files get pulled into the web root (i.e.
htdocs) by a user named git executing
git pull in the post-receive hook.
By default, all files and folders git creates have 664 and 775 permissions, respectively, and are owned by that user. 664 translates to the user and group being able to read and write, and everyone else only being able to read, and 775 translates to the user and group being able to read, write and execute, and everyone else only being able to read and execute. (That’s a mouthful!)
-rw-rw-r-- 1 git git 30 Aug 15 23:04 test-file.txt
drwxrwxr-x 1 git git 102 Aug 15 23:04 test-directory
Now, in an instance where you need a folder in
htdocs writable by another user, like apache, for let’s say a caching system, you need to be able to set those particular permissions accordingly.
To accomplish this, you really only have two options:
- Set permissions of files to 666 and folders to 777
- Set the owner or group to apache (or a group that apache is a member of)
Personally, I favor restrictive permissions over convenience, so option #1 is out, which means we’re going to take a look at how to implement option #2.