Git Push with WPEngine

One of my favorite features of WPEngine is their integrated git push for deployment. Instead of manually SFTP’ing files back and forth, you can easily push code changes while keeping your code version controlled.

WPEngine lets you create unlimited transferrable installs, so you can easily use it for all your site development. When it’s time to go live, you simply type in your client’s email address and they’ll get a direct email walking them through the transfer process.

Create a site on WPEngine

From your WPEngine dashboard, click “Add Install” and give it a name. Once created, you can clone an existing live site here by installing the WPEngine Automated Migration plugin on the live site, typing in your WPE install details, and letting it handle the migration of everything.

Once the install has been created, click “Git Push” in the sidebar, type in your name, and paste your SSH public key. This support article by WPEngine will walk you through it.

Setup Locally

Setup your local development environment. You can use MAMPLocal, or other tools. I also recommend you setup wp cli.

Open Terminal and initialize git in the top level of the website: git init. While you could use it to version control everything (WP core, themes, plugins…), it makes sense to limit it to just the code you’re actively editing using a .gitignore file. I limit it to my custom theme and core functionality plugin. Here’s my gitignore file.

If you’ve created a repo on GitHub, click “Clone or Download” (screenshot), copy the URL they give you, and set it up as a remote. For instance, for my EA Starter theme I would use: git remote add origin [email protected]:billerickson/EA-Starter.git

Go back to the Git Push page in the WPEngine dashboard. In the bottom of the right column you’ll see the two remotes corresponding to your production and staging environment. Add them (make sure you use the correct URL). Example:

git remote add production [email protected]:production/mysite.git
git remote add staging [email protected]/mysite.git

Pushing code updates

As you develop your site, periodically commit your changes: git commit -am 'this is my great commit message'. Push those changes to GitHub: git push origin master. And when you’re ready to push to your production or staging site, simply push to the remote: git push production master.

WPEngine will scan the files, make sure there’s no PHP errors, update the correct files, and clear your cache.

I also recommend using WP Migrate DB Pro to push/pull your database and media. If your site has lots of media, skip the media syncing and use BE Media from Production so that your local install will reference the production site for media rather than having to store a copy of everything locally.

intermediate wordpress wpengine

Receive New Posts by Email

Comments

  1. Hi Bill,
    I am glad that your bringing this type of thing up. Many people do not utilize GitHub on WP engine. I agree the ability to spin up transferable client sites is awesome.

    Have you checked out and I’m just saying this because it’s so relevant to what you’re talking about. Have you tryed Pantheon? They have everything you’re talking about and a much deeper Git integration what you said about SFTP and GitHub are done in a manner in which I don’t think can be topped.

    I am not trying to promote something just letting you know that everything you talked about that you liked is built in the right way to pantheon take a look is my advice.

    I love power of versioning and transferring to clients is especially important. Also not having a limit of any type on how long you can develop a site is amazing.

    1. No, I haven’t had a chance to use Pantheon’s offering yet but it looks great. I’m hoping I can get a client hosted with them soon so I can learn more about it.

  2. Bill (or Carrie), how do you deal with your own plugins that you’re using (and perhaps modifying) on a client site that you’re writing a theme for?

    Do you use the individual repo for the plugin, and ignore that plugin in the main client gitignore (which includes both the theme and some plugins), or is there a different way you approach it?

    (I ask because I have a number of plugins that I use over and over that aren’t on the WP repo, like a plugin that adds a content type for testimonials, then outputs that in a default way. It periodically gets a bit more refined during development of an individual site on which it’s being used.)

    1. I have a single “site” repo that contains the website’s theme and core functionality plugin. My gitignore ignores everything BUT those two folders. So as I add new plugins, I don’t have to edit the gitignore to ignore that too.

      For plugins that I use often, I create a repo for it, like EA Share Count and BE Events Calendar.

      1. That’s about what I’d thought; wanted to see if you had a better way. Are you still liking this methodology after using it a bit? I’m thinking of moving to a similar workflow on Flywheel (using DeployHQ to push Git commits onto staging or production), but it’ll be a significant change to workflow.

      2. I like the setup. It’s a bit more work to initially setup, but then pushing / pulling changes are very easy.

        It really helps if you have WP Migrate DB Pro. Their CLI and Media addons help you manage everything that’s not code.

        wp migratedb migrate 1 – Pushes the database and any new media from my local environment to WPEngine. (used for initial migration)

        wp migratedb migrate 2 – Pulls the database and new media from WPE to my local environment (used before making changes to site locally once the client has access and is making changes)

  3. Hey Bill,

    Thanks for writing this up. I’ve been using Git Push with WP Engine for a while now but it’s always good to get your take on something!

    Cheers,
    Nick

  4. So just to clarify… Since WPE doesn’t allow pulling, if the client adds 10 plugins to the site (or edits the stylesheet, etc…), the only way to get those physical file changes back into your local install is to manually download and extract the latest restore point and copy those files into the local install? (and then pull the database with WP Migrate DB Pro)

    As a followup to that, when you’re working on change requests after having sent the site for review, do you tell the client to not make any changes to the review site, so that you don’t wind up with anything out of sync?

    1. That’s exactly why I created wp cli plugin install-missing. Before I start any changes I have a script that:

      git pull origin master make sure I have up-to-date theme & CF plugin
      wp migratedb migrate 2 pull latest copy of DB and media, the profile id = 1 is for pushing to WPE, id = 2 is for pulling
      wp plugin install-missing install any plugins that were added

      My clients aren’t usually tech savvy enough to edit theme files, but if it becomes an issue I think turning on Read Only File Configuration would fix it.

      Clients can still edit content, add media, and install/deactivate plugins. The only thing this doesn’t cover is what version plugins are used, but that’s easily fixed by running wp plugin –update-all on both sites.

      And I’ve only been doing this for a few weeks now so I’m sure there’s things I haven’t thought of yet.

      1. Wanted to swing back by and say thanks, I got this working on WPE with your’s and Carrie’s article. I bought the $200 version of WP Migrate DB Pro through your affiliate link . 🙂

          1. I want to say thanks as well. Great article. I’m new to WP development and the DB syncing was driving me nuts. Your plugin recommendation is perfect. I followed your link and made a purchase.

          2. Glad to help! You might also check out Mergebot which lets you merge changes between two sites. So changes you make to the development database can be recorded and run on the production environment.

  5. Hey Bill! Completely agree with the move from Bitbucket to Github now that unlimited private repositories are permitted – not only is it less of a hassle to have everything in one place – but I also much prefer the GitHub interface (sorry, Bitbucket! ).

    I’ve been using the Git Push feature with WPEngine for some time- still refining the process. I have been manually keeping things in sync between environments (sql dumps and moving media via SFTP) – which I am used to by now – but I’ll definitely look into WP Migrate DB Pro. Cheers!

  6. Hey Bill, great article. I was just wondering about something.

    I don’t want to push some development files, like sass files to production. But I do want to track these locally with git while I’m developing the site. On other hosts I use a task runner like gulp to build a separate build folder and then push just that to the live site. However the way WP Engine works it looks like you push from the root directory making it difficult to do this.

    Thinking about it I suppose I could have two folders in my theme folder “my-theme-production” and “my-theme-live”. Then I can have a git folder in production which produces the live theme. I only track the live theme from the WP Engine git repo.

    How would you approach this?

    Thanks.

      1. I went with having two theme folders, a production and live theme. On my localhost I develop with the production theme and when I want to I use gulp to rebuild the live theme. I use git to push only the live theme. This way I can just push live files and not production files (sass but also things like node modules (which I don’t track locally either)). It seems to work.

        This also means I can have a separate production repo which is just for the theme.

  7. By the way the BE Media from Production plugin is a really fantastic idea. The main site I maintain has more than 5 gig in the uploads folder and being able to pull images from the live site makes updating my local host version a whole lot easier. I love the fact there are so many people in the WP community who are willing to do cool stuff like this for free.

  8. Is there a way to ensure that certain files in your Git repo don’t end published in the web server?

    For instance, I would like to include files like `.travis.yml` and `.editorconfig` in my Git repo, but don’t want the server to have them.

    1. I’m not aware of how to exclude them from WPEngine, but you might try contacting WPE Support. About a year ago I spoke with them and they were considering allowing developers to include their own deployment scripts to run when code is pushed there, like the ones they use to check for PHP errors. There might be a way to set it to remove certain files at that point.

Leave a comment