I looked at Kinsta’s features grid here:
And, it looks like SSH is included in all Kinsta’s plans now.
Unfortunately it looks like that might have been an error–the features grid is back to how it was before.
Our biggest Sage 9 client is on WPEngine. We use a CircleCI deployment process and it’s working flawlessly.
The DeployBot guide we published recently also covers WP Engine. https://roots.io/guides/automate-sage-9-deployment-with-deploybot/
It would be cool if you could share your
config.yml. CircleCI would be better than DeployBot for most as it’s free plan is enough in most cases.
Warning, this is really rough. I’ve edited out some personal info and tried to generalize some specifics. The shell script in /dev_assets/deployment can probably be bundled into the yml. And it needs better instructions. I have not tested this version. This is definitely alpha code.
@slam - I’m implementing the CCI workflow you’ve outline in your link, but running into issues with WPE validating the PHP when I push to the remote. There are syntax errors bing returned, which appear to be related to the use of PHP 7.2 vs. an older version <= 7. Everything builds fine locally and on CCI, but when it does the push from CCI is fails. Did you run into this issue?
I haven’t run into this issue, no.
But I’ve just this week updated my local containers to PHP 7.2, and my WPE sites are all still 7.0. Still, I can’t see how that would cause an issue.
Check to be sure your local install is PHP 7.2 and you are checking the error logs for issues.
If anyone runs into errors pushing to WP Engine while using Sage, try using the command “git push -o nolint production master” See https://salferrarello.com/wp-engine-syntax-error-composer-autoload_static-php/ for more context.
Tharris! Thanks for bringing this up.
Not a day after you posted this I ran into the same issue. My deploy was rejected due to a dozen PHP errors.
The issue is that WPE is upgrading sites to PHP 7.2, but their linter is still set for PHP 7.0. There’s new syntax in PHP 7.2 that will cause the linter to fail and reject a deploy.
I wasn’t seeing this on my existing sites until I upgraded them to PHP 7.2. When I saw it I remembered your reply and was able to snag the
-o nolint syntax.
Thanks for this solution, it appears to work nicely, the only thing we have noticed however is that when ssh’ing in to the WP Engine server and cd’ing to /tmp the sage-cache directory and cache files don’t appear to be there.
Is anyone else having this issue and, if so, does this mean it’s compiling, temporarily creating the cache, loading the site, and then clearing the cache?
Any help would be appreciated.
Thanks in advance…
Are you experiencing an error or problem on the site? Or is this more of a “how should it be working?” question.
If the site works I think you’re fine
Thanks for the fast response.
The site works fine, it was just a thought that if there are no cache files it is going to have to compile the blade files on each (uncached) request. Is that the case?
If I understand it correctly, WPEngine’s ssh shell isn’t the actual container the site is hosted on. It’s more like some kind of temporary, heavily-siloed ssh environment that is created and destroyed with each ssh session — this is why you can’t do things like create a persistent .bashrc file or add ssh keys.
When a Sage 9 site is run it generates the cache files in the real /tmp folder which the ssh shell does not have access to.
I’m about 80% confident the above is correct. =)
Can’t confirm for sure, but @slam’s explanation sounds likely to me based on my impression of what WPE lets you access via SSH.
The more I think about it, the more likely it seems like the SSH container is a docker service where
sites/mysite/ is volume-mapped to the web root of your install.