We’re a little spoiled with WPEngine’s comprehensive git push facilities, as well as their pretty fantastic staging environment.
But for those that have used up all of their WPEngine WordPress instances, there are cheaper hosting alternatives which may not provide managed WP hosting, but do provide git push deployments which makes life infinitely easier for developers and designers out there.
We’ve been using SiteGround lately, which provides git push, albeit in a more rudimentary way. If you’re not careful with what you’re doing, it can lead to some strange results. I’d like to highlight some of the pitfalls I’ve experienced while at the same time walking through what I consider to be a “normal” git-push workflow.
Navigating SiteGround’s cPanel
I like the simplicity that managed WP hosts provide on their dashboards. But for SiteGround, we’re stuck with cPanel for most of our tasks, so here’s a quick rundown of the things you’ll want to pay attention to:
Creating a subdomain
If you haven’t done so yet, you may want to create a subdomain for your install. We use a single domain at SiteGround and put several WP installs using subdomains for testing purposes. Here’s what the subdomain configuration looks like:
If you’re setting up a WP install using your main domain name, you can skip creating a subdomain.
Creating your WordPress instance at SiteGround
When you go to add WordPress to your domain through cPanel, you’re brought to a bizzaro world part of the control panel called “Softaculous.” You’ll notice all of the navigation is now different. Click the big blue Install button to get started:
Select the domain (or subdomain) that you want to turn into a WP install.
Remember to change:
- Database name – it will be auto-generated, I tend to choose something that matches the domain or subdomain so it’s easy to remember what it goes with.
- Table Prefix – I use the normal
wp_– I think changing this has become “security through obscurity” and if you don’t keep your site up to date, this is unlikely to save you from an attack.
- Admin Username – replace the auto-generated username with something useful, but avoid admin since it is easily targeted by attackers
- Admin Email – replace the auto-generated one with a real email address for the site administrator.
When the installation is done, to get back to the regular cPanel, just click the My Accounts tab at the top and then click the red Go to cPanel button.
Creating the git endpoint at SiteGround
Click the SG-Git icon on from cPanel. You’ll be brought to a screen where all of your WordPress installations are displayed, and if they don’t have git repositories associated with them, you’ll be given the option to create one. When you click Create Git Repository for your WP install, a dialog will come up with some git information. Record the git clone command, we’ll use it later.
There will also be a SSH key and possibly the passphrase that goes along with it. Rather than using this key and sharing it with all the developers who you want to be able to push to this SiteGround account, I find it easier to add individual keys via cPanel.
Setting up SSH keys and config
SiteGround only takes DSA keys for SSH. If you don’t have an
id_dsa.pub file in your
~/.ssh directory, you can create one by opening a terminal and running:
ssh-keygen -t dsa
Once your DSA key is generated, you can add it to the SiteGround control panel by clicking the SSH/Shell Access icon in cPanel. Copy the contents of your
~/.ssh/id_dsa.pub file and paste it into the text area on SiteGround:
Many git clients won’t accept the fact that SiteGround uses a non-standard port for SSH. The way to get around this is to create a
~/.ssh/config file with an entry for SiteGround. If the
git clone command SiteGround supplied looks like:
git clone ssh://sguser@mXX.siteground.biz:18765/home/sguser/public_html/git
~/.ssh/config file should contain:
Host mXX.siteground.biz HostName mXX.siteground.biz Port 18765 User sguser
Replace the Host, HostName, and User values with those from your account. I’ve changed them in this example for security purposes. To test you should be able to:
Notice you shouldn’t have to supply the username or the port, my
~/.ssh/config takes care of that. If you didn’t add a passphrase to your DSA key, you should be logged into SiteGround without having to supply a passphrase. Press Control-D to log out.
Now your git endpoint can be simplified for your git client (username and port are removed):
But don’t clone it just yet!
How not to push, and what will happen
The normal WPEngine workflow (for me) would be to create a normal git repository on my system, add an origin of bitbucket.org or github.com and push it there, then add remotes for WPEngine production and staging and proceed to push to those remotes.
The following assume’s I’ve started in the same way, but added SiteGround as a remote named
Since SiteGround’s set up is a bit more rudimentary, if you apply the same workflow and just instead add a SiteGround remote and try to push there (without pulling or cloning from SiteGround first), you’ll likely get a warning like:
Updates were rejected because the remote contains work that you do not have locally.
Per git’s recommendation, you might then try to pull:
git pull sg-staging master
If your git repository was set up to not track WP core files, you’ll get a warning that:
error: The following untracked working tree files would be overwritten by merge: index.php license.txt readme.html wp-activate.php wp-admin/about.php ... Aborting
This is because the core WP files have been added to the SG-git repo, but not your local one. So then if your next move is:
git push sg-staging master --force
Several important files will be removed on your WP install at SiteGround: all of
wp-config.php, and all other PHP files in the webroot folder. Needless to say, your WordPress instance will no longer function without some serious repair.
Git push to SiteGround (modified functional workflow)
I believe the file deletion at SiteGround from the above example stems from the fact that SiteGround sets up the git repository as a full repository and not a
--bare repository. So it seems to be better to start your WP project with a
git clone from SiteGround, but before doing that, I wanted to clean things up…
The easiest solution (if you don’t want core WP files under version control) was to remove them from version control directly at SiteGround before cloning the repo.
Since we’ve already got SSH working, from your terminal you can:
ssh mXX.siteground.biz cd /home/sguser/public_html/git git rm --cached -r wp-admin/ wp-includes/ *.php *.txt *.html git commit -a -m "Removed WP-Core files"
Again, replace the host (
ssh line) and path (
cd line) with the values from your
git clone command supplied by SiteGround. The ones used here are examples. The
git rm command removes the core WP files from revision control, but leaves them on the filesystem, so your installation doesn’t go into a state of disrepair (like above).
Once that is done, you can clone!
git clone ssh://mXX.siteground.biz/home/sguser/public_html/git
SiteGround will be the
origin, so let’s edit that (usually bitbucket.org or github.com is the true origin). This will rename it to
git remote rename origin sg-remote
Now when you want to push to SiteGround, just do:
git push sg-remote master
If you try to push a different branch to SiteGround, the branch will be transferred, but the code won’t be switched to that branch. To get around this you can overwrite SiteGround master by doing:
git push sg-remote my-branch:master
Hopefully this gives you some insight into how the SiteGround git deployments work, so you can use them effectively with minimal frustration.
If you’re interesting in learning more about git deployments or how to set up your own git-push-to-deploy, I recommend starting with this article to familiarize yourself with a basic setup: