Step: Move my Media Library content into S3
First off, the uploaded photos should not be under version control; so they shouldn't be in the repository and in the ephemeral filesystem.
This was a tedious process of a few hours since I had about 130 images.
- I set up the S3 plugin I mentioned above, made a few tests and confirmed that it's sweet.
- I SFTP'd into my Wordpress site's wp-content/uploads folder and grabbed everything.
- Then deleted everything from my Media Library,
- Then uploaded it all again and watched it load into S3 and leave my uploads folder empty.
- Then went through every posting and replaced all of the images, which of course were now broken. Annoying, but fortunately I only had 35 pages with images and did it in about 2 hours.
Step: Init repo
I'm a fan of Gitlab. They offer unlimited private repositories for free, which is really excellent. I created the repository, then followed their simple instructions to load my Wordpress files into the repo and basically turn my site into a clone.
I also created a .gitignore file with these two entries for some folders I'll be creating in a little bit. The private is where I'll do some other work I don't want in version control, e.g. working files and database dumps that I want to keep close. The vendor would be generated by composer later on, trust me.
/private/
/vendor/
Step: Add Heroku as a Secondary Master
The trick in allowing git push to push to deploy to Heroku, is that you tell your repo clone to use your Heroku as a secondary master.
heroku git:remote -a your-server-name
As of now, when pushing you will need to distinguish between git push origin master and git push heroku master. One pushes into your git repository (Gitlab, Github) and the other would redeploy to Heroku.
Step: Wordpress Updates
I then noticed that some updates were available for some plugins and for Wordpress itself. So I ran those, and after each one noted that git status reported exactly what I would expect from each upgrade. So three commits later I had Wordpress and plugins all updated, with commit notes for each update. (I could have done this before the repo init, but why not do it under version control?)
Step: Add a Procfile and composer.json file
For Heroku compatibility, it's advisable to add a Procfile and a composer.json and composer.lock file, to indicate to heroku what PHP version to prefer, that you prefer Apache over Nginx, etc. You will want these in version control.
Procfile
web: vendor/bin/heroku-php-apache2
composer.json
{
"require" : {
"php": "^5.6.0"
},
"require-dev": {
"heroku/heroku-buildpack-php": "*"
}
}
composer.lock is generated from the composer.json with a command:
composer update --ignore-platform-reqs
Step: Push to Heroku
All set? Then here goes:
git push heroku masterAnd I visit my website. And it's a Wordpress error that it can't make the database connection. That's to be expected: my wp-config.php has the old credentials and I still need to upload the database content. But that's definitely Wordpress making the error, so a fine start.
Step: Database Configuration
First step was to scrub my database credentials from the wp-config.php file. Yeah, dummy move to forget to do that, but the credentials are wrong for Heroku so are useless, and my local MySQL is going away in an hour anyway. But yes... don't do what I did. ;)
When I scrubbed the database credentials, I replaced them with $_ENV variables like this:
define('DB_NAME', $_ENV['DATABASE_BASE']);Add, commit, push. Site is still dead but it's ready for this next trick.
define('DB_USER', $_ENV['DATABASE_USER']);
define('DB_PASSWORD', $_ENV['DATABASE_PASS']);
define('DB_HOST', $_ENV['DATABASE_HOST']);
Run heroku config and it dumps the app's configuration variables back to me. I tease apart the database URL string, into my set of 4 environment variables for the 4 $_ENV items above.
heroku config:set DATABASE_BASE='heroku_XXX' DATABASE_USER='XXX' DATABASE_PASS='XXX' DATABASE_HOST='XXX'My app/dyno reboots and... the site's up!
Step: Database Data
A simple mysqldump was all it took to take a backup of my database, then loading it was one more command.
mysqldump -h localhost -u olduser -p olddbname > private/dbdump.sql
mysql -h herokuhost -u herokuuser -p herokudbname < private/dbdump.sql
It doesn't get as lot easier than this.
And now the site is up! My data, on a new database on a new Heroku server. Shiny.
Step: Custom Domain
My site is www.fightingfantasyfan.info and not fightingfantasyfan.herokuapp.com Heroku calls this a custom domain. There are two steps in setting up the Heroku app to work properly with a custom domain.
- I hit up Heroku's dashboard and the Settings for my site, and added two domains for it: www.fightingfantasyfan.info and fightingfantasyfan.info This allows it to respond to these alternate hostnames, should they point to this app.
- I went to my domain registrar's domain control panel and set up a CNAME record, so that www.fightingfantasyfan.info is equivalent to fightingfantasyfan.herokuapp.com This took a little bit to propagate, but was done about the time I finished my cup of coffee.
