• Stay in touch. Sign up for the 9seeds newsletter.
  • Deploying to SiteGround via git push

    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:

    cPanel home

    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:

    cPanel subdomain

    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:

    cPanel new install

    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.

    cPanel git info

    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:

    cPanel ssh key

    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

    Then your ~/.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:

    ssh mXX.siteground.biz
    

    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):

    ssh://mXX.siteground.biz/home/sguser/public_html/git

    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 sg-remote.

    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-admin, 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 sg-remote:

    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:

    https://www.digitalocean.com/community/tutorials/how-to-set-up-automatic-deployment-with-git-with-a-vps

    Import/Export issues between MySQL 5.1 and 5.5+

    There have been many advances in recent history that make a WordPress developer’s life easier. WordPress itself is already pretty easy as it’s very tolerant of a myriad of hosting environments. To make things easier for local setup, there’s a fantastic product called DesktopServer by ServerPress which will quickly and easily set up a multitude of local WordPress sandboxes to hack on. DesktopServer currently ships with MySQL 5.1 which is A-OK because WordPress requires version 5.0 or greater.

    When setting up a new development environment, we typically use WP Migrate DB Pro (HIGHLY RECOMMENDED!) to download the latest database data from staging or production into our local sandboxes. Other ways work just as well, like exporting from phpMyAdmin (or native mysqldump) and then using interconnect/it Search and Replace. WP Migrate DB Pro is just so easy because it does everything in one step.

    However, a problem reared its head recently while exporting from WPEngine (which currently uses MySQL 5.6) to DesktopServer. [Read more...]

    Hack to remove numbers from Jetpack sharing (sharedaddy) buttons

    In June 2014, the whole 9seeds crew assembled at WordCamp Orange County 2014. While this has nothing to do with sharing buttons, I wanted to point it out since our remote work environments prevent us from getting together more than once a year. Thanks Orange County, the weather couldn’t have been nicer!

    At the conference, one compelling talk was about Social Media Strategies by Sarah Wefald. She has great real-world social media experience, working with bands – arguably the best use of social media. She’s also a punk-rock karaoke star.

    [Read more...]

    Finding Work/Life Balance as a Remote Worker

    We’ve all said it 1000 times, “I love what I do because I can do it from anywhere.” It’s the dream of pretty much every developer… travel the world and work from exotic locations. But if you’ve ever tried it, you’ve probably figured out that it’s a LOT of work.

    At 9seeds, we all work remotely. Most of us work from home offices, co-working facilities or the occasional coffee shop. But, one of the guys on our team, Jon Brown, just spent 4 months traveling the globe and working along the way. Other than some challenges with scheduling times to chat, you’d almost not have noticed he wasn’t sitting at home working.

    This past weekend at WordCamp Orange County, Jon gave a talk where he discussed finding the work/life balance as a remote worker. It was a great session and made me realize two things; 1) It IS a lot of work, 2) It sounds like the hard work is absolutely worth the effort!

    Finding Focus

    In late December we were wrapping up our biggest quarter to date as a company. As we all took some time off for the holidays, it gave us time to take a serious look at the product side of our business. We had a small number of premium plugins that we made available for sale, and several other free plugins that we were also maintaining. As we headed in to the new year, we wanted to make sure that our time and energy was being spent wisely. As I’m sure you can relate to, when we pulled back the curtains, we realized that we were definitely spread thin.

    When you’re evaluating what projects to keep and which to kill, you have to take a lot in to consideration. Income, potential income, investments in both time and money, and one of the most important elements that I think we lost sight of, personal interest in the project. Even though we were working hard one of our projects, our passion for the product itself, just like Elvis, had left the building.

    Throwing away a lot of work
    In early February we made a decision that should have been made much earlier. We decided to stop developing the WP Event Ticketing plugin. The finial decision was easy to make. Getting to the point of making the decision wasn’t as easy.

    We had spent countless hours over the previous 2-3 years building the plugin, including a complete rewrite that we’d been working on for much of the past year. The thought of throwing that all away was painful. So painful that it kept us from making the final decision for more than a month after we already knew what the right thing to do was. But then…

    Revelation time
    Have you ever gone to bed thinking about a problem and had the answer hit you so hard at 3 in the morning that you sit bolt upright in bed and shout, “Booya, Bitches!” OK, maybe that’s not what you shouted, but I’m pretty sure that’s what I shouted.

    I was forced awake with a single thought:

    Every minute we spend writing code, answering a support ticket or even thinking about the Event Ticketing plugin is one more minute that we are not focusing on our clients or the other products.

    That was it. The switch had been flipped. When I got to my desk I made the, now very easy, call to shut it all down. It felt like a weight had been lifted.

    You’re never done cleaning house
    That moment of clarity has come in handy a few times since then. But none more so than when we received an email asking if we would be interested in selling the WP Affiliate Manager plugin. Honestly, it wasn’t something we had given much thought to. But here we were faced with an opportunity to narrow our focus once again.

    Previous to 9seeds, I spent a decade working for a company that made the bulk of it’s income from affiliate marketing. The affiliate plugin seemed like a natural fit for us to build. But, affiliate marketing isn’t something we do much of these days, so there has been a decline in the amount of energy we’ve put in to the affiliate plugin recently. After some serious consideration, we came to the conclusion that selling WP Affiliate Manager was too good an opportunity for everybody involved that we simply couldn’t pass it up.

    The new owners have a list of short and long term goals for the product that will breath new life in to it. We are excited to see where they take it.

    Time to focus
    As I’ve mentioned in previous posts, Time Tracker is a product that I use literally every single day. It’s a tool we use internally for tracking time we spend working on client projects. We have a nice long list of features and enhancements that we want to add to the plugin. With the sale and transfer of Affiliate Manager complete, I’m thrilled for the additional time that we’ll be able to dedicate to it.

    One question we get asked a lot regarding Time Tracker is if there is a demo of the product they can try out before they purchase. It feels really good to finally be able to answer Yes! You can head over to http://timetrackerdemo.com/ to try out the plugin.

    If you have any questions or feature requests regarding Time Tracker, we’d love to hear from you.