My workflow for Sage 9 + WPEngine Git Push using Codeship

sage
1

My workflow for using Sage 9 + WPEngine Git Push

I maintain a couple WP installs that live on WPE. There are a lot of good points in how WPE configures their servers, but the WPE git push setup is a lil limited. I thought it might be helpful for me to share how I’ve worked around the WPE Git setup, and I’d love to hear from other folks maintaining Sage sites on WPE.

The primary issue with WPE and modern build tools is that WPE does not support asset building, so it expects your local repo to contain compiled assets. In order to push a production version of a Sage theme, the /dist directory needs to be under version control… and those aren’t really the files I want to keep in my origin repo.

I settled on using Codeship’s CI platform to clone my repo, then execute build and deploy scripts. Yes, there are probably plenty of other ways to hook a deploy script in, but this was the simplest for an amateur Git user like me. Codeship is free up to 100 builds/mo, which is plenty for these sites. And, they provide shell access, which is very helpful for experimenting.

#My current setup looks like this:

##Local Repo

My .gitignore includes:

dist
node_modules
npm-debug.log
yarn-error.log
yarn.lock
vendor

I use the local repo to branch, build new features, etc., then push to
/

##Origin Repo on github

After pushing to github, the repo is cloned into
/

##Codeship project

Codeship offers virtual machines to clone a repo and then execute build / deploy scripts. I have two Codeship pipelines set up—one for staging and one for production.

With each deploy to codeship, on the remote machine, I build a production version of my theme, destroy the local .gitignore, and swap it for a new file that ignores directories / files that may or may not exist in repo AND should not be on the server, like:

resources/assets
.editorconfig
.eslintrc
.gitattributes
.gitignore
.travis.yml
composer.json
composer.lock
package.json
yarn-error.log
yarn.lock

My Codeship scripts also create a wp-content/themes/theme-name dir structure, so the final push to WPE will drop the theme in the right place. This approach keeps a clean local repo associated with the theme root. I should mention you will need to manually FTP the vendor directory into WPE before any of this will work.

I borrowed very heavily from this helpful guide published Zachary Watkins—he provides some great detailed step by step instructions and some starter scripts to use in Codeship.

Here’s the exact scripts I used for my particular build.

Now if I could just get a good workflow for compiling .blade templates locally…

4 Likes
2

You won’t be able to use this in production unless you precompile the templates in the repo.

3

There might be something I’m missing, but I am pushing uncompiled blade templates to the repo right now. I did see occasional errors when I first pushed to production, but once I loaded each template initially, those errors dropped off. Have you heard anything from WPE about changes to their permissions settings?

4

You need to have your compiled templates in the repo that have been compiled at the path for the specific site e.g. /nas/content/staging/${WPE_INSTALL}/wp-content/uploads/cache/xyz.php. You can’t even just take your local cache folder and upload it because Blade will look for files at a different HASH.php

WPEngine does not give you write permissions via PHP so the templates will never compile.

If you somehow managed to figure it out I’d love to know because I haven’t. I started working on a Docker container that would install wordpress in the directory, compile the templates. But I think I’d rather just drop Blade as a requirement.

5

Edit I just figured out how to do it

6

Excellent, thanks for popping in! Mind sharing what you’ve set up?

7

Will do a write up shortly here

8

Is it hacky? Yes. But does it work? Yes.

Let me know if you have questions. You’ll need to adapt my gitlab config to a circleci one but they are very similar.

https://tobyschrapel.com/2017/05/deploying-sage-9-blade-templates-to-wp-engine-using-gitlab-ci-pipelines/

3 Likes
9

Awesome, this is really helpful stuff. Thanks much for sharing / typing this all up, I’m excited to try it.

10

Lads - anyone able to come up with an my simpler workarounds for dealing with WP Engine?

  • Theme is Sage 9 Beta 3
  • Deployment through buddy.works
  • Hosting is WP Engine

I’m getting the same white screen errors discussed above and the permission warnings about those cached compiled PHP files in the /uploads/ folder. I’ve been onto WP Engine support for the last 3 days but they can’t help - they seem to have a system (caching system) that works and they won’t alter it for anyone?

1 Like
11

I’m sorry to report that I realize now my instructions above are incorrect. The workflow posted up top is fine for styling changes but won’t compile blade templates.

That said, it is possible to revise the build script slightly to compile files in /cache/ and deploy those as well. I initially got permissions errors the first time I pushed my Sage 9 theme, but I was able to rework the Blade templates and eliminate the errors. Removing some custom Blade directives I had written did the trick. I’m not certain exactly why the custom directives were an issue, but writing regular php inside a Blade template seems to be kosher for WPE, and the more advanced Blade functionality is a little more hit or miss.

Let me know how you make out!

12

Wow - so actually removing blade directives for templates works?

Its a weird one - I can see most of my URLs up there but have the occasional white screen that eventually (day or 2 randomly) resolves? There are no immediate errors in the logs - just warnings about permissions 10 minutes ago - all a bit bizarre. But if you’re saying that those blade directives are an issue then that might explain the above problem URLs!

Thanks for your help James

13

So guys here’s an update. So when i got onto WPE about these ‘white screen’ errors - i immediately gave this discourses URL to guide them on what was the underlying issue - they immediately presumed it was a server layer issue and that’s the course they took in investigating blade templates and run time cache file creations and permission issues.

I spent a few days with WP Engine support figuring out possible solutions. I gave them all the above potential solutions above and all in all they had given up and told me that a theme that used blade templates would not be supported on WP Engine due to interference with their caching layers.

I was just about to move hosting having an angry client in my ear - when i just hoped on support instant chat one last time and talked to a saint called Gareth who rather than looking into my original solution led issue looked at it from a simple cache exclusion perspective and simply excluded “/wp-content/uploads/cache” from the caching layer and BOOOM - site works perfect!

By the way if anyone wants to know how WP Engine caching system works - there’s actually a few types of caching they do. The two major one’s are …

  1. Object - https://wpengine.com/support/wp-engines-object-caching/

  2. Varnish - https://wpengine.com/scale-to-millions-of-hits-a-day-or-hour/

Standard installs use both. WP Engine can customize installs by excluding URL structures, query parameters, folders etc from the cache layer - they do this sort of thing all the time.

So listen bottom line - anyone else having issues with WP Engine protection site - ask a support agent to remove “/wp-content/uploads/cache/” from the caching exclusions later.

Thanks for all your help James also - guided me in the right direction!

3 Likes
14

That is super helpful, Liverpool! Yes, I had spoken to Gareth before, too, he is very helpful indeed. I will certainly try this change and see how it goes.

15

Hey there! I tried your suggestion of getting the cache folder excluded from the WPE cache, but it’s still not working. I’m still getting the php flock error on production that everyone is getting. Did you do anything else that you didn’t mention in your post? Thanks!

1 Like
16

Great article @anon66789415! Thank you for sharing!

17

Hey @jamesfacts, have you had any luck with this? Was about to chat with WP-Engine in a day or two and figured i’d check if it’s working for anyone else. Thanks.

1 Like
18

… I actually decided to go with Docker to simplify my repo management. Will report back once it’s working.

19

Nice, I think I’m about to do the same. Talking to WPE chat about that cache exception didn’t help me unfortunately. Let me know whatever works for you whenever you get a chance. Thanks again.

20

Finally found a working solution to this. I originally tried @liverpoolrc’s suggestion of asking WPE support to add a cache exclusion to wp-content/uploads/cache. But as @timbriteweb mentioned it wasn’t working. After a bit more back and forth with chat support, he attempted to purge the caches after adding the exclusion and it worked!

Here’s some of the transcript of the chat to reference and keep in mind:

I had to purge the caches after adding that cache exclusion mentioned in the link you provided.
I looked through our old tickets and found someone with a similar issue that had the same solution too

As soon as I saw the page was working while logged in I knew it had to be the caching because caching is actually disabled while logged in.

Hope this helps. Good luck.