Adding a WordPress Project to a Git Repo

Day Five already. And Monday too. If you’re reading along, well done. Let’s take a breath. OK.

Today I’m going to add my project to a git repository. This is actually quite a fraught topic. The question is always “What goes in?”. Which translates to “Do I commit core code?” The answer, for us, is “As little as possible” and “No”. We only want to commit code that we’ve written or amended. If it can be acquired using Composer, then it has no business sitting in our repository.

So, what do you need to follow along today?

Prerequisites

You’ll need Git installed on your server, and an empty repository to push to. That’s about it. I’ll be adding files and directories to git as if we’ve been coding within a git environment all along, so you’ll need to set that up.

Where We Are At

Before we push any data anywhere let’s recap the state of the filesystem. Here, very very heavily edited, is the state of the files and directories I’ve been working with. The directories are highlighted.

.
./site
./site/wp
./site/wp/wp-includes
./site/wp/wp-admin
./site/index.php
./site/wp-config.php
./site/wp-content
./site/wp-content/themes
./site/wp-content/plugins
./composer.json
./composer.lock
./vendor

Here is what we are going to add to the repo (at this stage).

./composer.json
./composer.lock
./site/index.php
./site/wp-config.php

Everything else is automatically generated by composer install.

The Problem with Committing Configuration

But there is a problem right away. Are we really going to add wp-config.php to the repository? Remember, in Day 4 we configured the configuration file to set up some pretty important constants. I want to commit the file so that I do not have to recreate those changes every time I install in a new location. But If I commit the file as it stands, then I’m adding site-specific credentials to the repository.

Here is where our directory structure comes into its own. I can create a conf/ directory outside of Web space and add a file, conf/siteconf.ini which looks like this:

dbname=getinstance
dbuser=getinstance
dbpass=123456789

Now I must edit ./site/wp-config.php so that it uses this simple configuration file. Here’s what it looks now now:

// ** MySQL settings ** //

/** The name of the database for WordPress */
define( 'DB_NAME', 'getinstance' );

/** MySQL database username */
define( 'DB_USER', 'getinstance' );

/** MySQL database password */
define( 'DB_PASSWORD', '123456789' );

And here are my amendments:

// ** MySQL settings ** //
// do not add credentials here that should not 
// be added to a VC repository!
$conf = parse_ini_file(__DIR__."/../conf/siteconf.ini");

/** The name of the database for WordPress */
define( 'DB_NAME', $conf['dbname'] );

/** MySQL database username */
define( 'DB_USER', $conf['dbuser'] );

/** MySQL database password */
define( 'DB_PASSWORD', $conf['dbpass'] );

So now I can add ./site/wp-config.php to the repository without having to edit it locally.

A Little Automation

I am also going to add a simple script bin/initialsetup.sh so that each time I clear down and try this all out I don’t have to copy and paste my calls to wp-cli all over again. This script saves me some time, and it’s a handy recap of some of the work we’ve done in recent days.

die() {
    echo $1;
    exit 1;
}

if [ $# -lt 7 ]; then 
    die "usage "$0" dbname dbuser pass url adminuser adminmail adminpass"
fi

# local values
DBNAME=$1
DBUSER=$2
DBPASS=$3
URL=$4
ADMINUSER=$5
ADMINMAIL=$6
ADMINPASS=$7

# do the initial install of core, plugins and themes (see day 3)
composer install || die "composer install failed"

# create the database (see day 4)
./vendor/bin/createDbAndUser.sh $DBNAME $DBUSER $DBPASS || die "dbcreation failed"

# create the site local configuration (see day 4)
cat <<EOT >> ./conf/siteconf.ini
dbname=$DBNAME
dbuser=$DBUSER
dbpass=$DBPASS
EOT

# install the database tables (see day 4)
./vendor/bin/wp core install \
    --url=$URL \
    --title=getInstance \
    --admin_user=$ADMINUSER \
    --admin_email=$ADMINMAIL \
    --admin_password=$ADMINPASS \
    --path=site/wp || die "wp-cli core install failed"

# update options to account for subdirectory (see day 4)
./vendor/bin/wp option update \
    siteurl $URL/wp \
    --path=site/wp

Adding Stuff to Git

Now, assuming our root directory is a initialised as a git repo, we are ready to start adding files:

$ git add composer.json 
$ git add composer.lock 
$ git add conf/siteconf.ini.sample 
$ git add site/index.php 
$ git add site/wp-config.php 
$ git add bin/initialsetup.sh

… and to commit and push

$ git commit -am'initial commit'
$ git push origin master

And that’s that. Except it isn’t. The big question is – can we go use this committed work to go from a standing start to a basic WordPress environment without too much hassle?

Clearing Down the Working Directory

So it’s another moment of truth. Can we go from a clone to a working system in just a couple of commands?

First of all, I’ll clear my working directory. And here’s what it looks like now.

$ ls -a
.  ..

Now I’ll drop the database.

$ mysql -u root -p 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 206491
Server version: 5.1.73 Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> drop database getinstance;
Query OK, 12 rows affected (0.01 sec)

So we’re back to a state of innocence. Let’s see if we can get back to Hello World

Trying Out the Repo

First we’ll clone into the current directory.

$ git clone git@bitbucket.org:getinstance/getinstance-site.git .
Initialized empty Git repository in /var/www/getinstance/.git/
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 19 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (19/19), 10.96 KiB, done.
Resolving deltas: 100% (2/2), done.

Let’s look at what we’ve got:

$ find . | grep -v .git
.
./bin
./bin/initialsetup.sh
./site
./site/index.php
./site/wp-config.php
./composer.json
./composer.lock
./conf
./conf/siteconf.ini.sample

Let’s run that initial script and see what falls over.

./bin/initialsetup.sh \
    getinstance \
    getinstance \
    123456789 \
    https://getinstance.com bob \
    matt@getinstance.com \
    pibbling

In fact, quite a lot fell over for me the first few times I ran this, but I tweaked the initialsetup.sh script, and now I consistently get back to this:

Let’s just recap the steps in that script as if we had performed them manually.

First it performed a composer install in order to get WordPress core, plugins and themes.

$ composer install

Then it created the database

$ ./vendor/bin/createDbAndUser.sh getinstance getinstance 123456789

We no longer need to generate the configuration file as we did in day 4, because the wp-config.php file is now stored in the git repo. But we do need to generate the conf/siteconf.ini file it uses.

dbname=getinstance
dbuser=getinstance
dbpass=123456789

Now that the conf/siteconf.ini exists and can be read by our amended site/wp-config.php file we can run wp-cli to generate tables and alter settings.

$ ./vendor/bin/wp core install \
    --url=https://getinstance.com \
    --title=getInstance \
    --admin_user=bob \
    --admin_email=matt@getinstance.com \
    --admin_password=pibbling \
    --path=site/wp

$ ./vendor/bin/wp option update \
    siteurl https://getinstance.com/wp \
    --path=site/wp

Much easier to run the script than each of the commands in turn! But hopefully breaking it down here helps demonstrate the process.

Where next? Well, we could take this skeleton and make it a public package that could then be required by other projects. I might do that in a future day if there’s time. But for the time being, there’s a site to be built and not much time to do it in!

photo credit: cheesy42 366-122 Don’t Hurry! via photopin (license)