We’ve recently made the leap to sage, and we’ve been all smiles ever since. We’re trying to get a vanilla install to work on WPEngine, where we lease a server, and are running into a bit of trouble.
We are using deploybot to run yarn’s build script and deploy the files, and (for now) have opted to sftp the vendor folder…eventually we’ll create a docker container to do all of this, but for now…baby steps.
We’ve deployed the same vanilla Sage 9 theme to two WPEngine installs:
The first one works as expected. The second (with debug on) shows a few warnings, and otherwise, the white screen o’ death. The errors suggested that the blade views were not able to write to wp-content/uploads/cache/compiled and sure enough, when i drill down to that folder, no files exist.
I thought this might be a permissions issue, so I reached out to WPE support and he confirmed that both installs have the same setup underneath the hood.
I am a bit familiar with WPEngine set up, and since I am working with WooCommerce a lot I run into caching troubles frequently. WPEngine uses object caching, you could try and disable this to see if it makes any difference. Find wp-content/object-cache.phpand rename it to wp-content/object-cache.php.bak
Other than that there is a bunch of default plugins that get loaded: wp-content/mu-plugins/wpengine-common
loads a whole set of goodies. http://conschneider.de/?ddownload=1212 - these could in theory cause a conflict. I am not sure if either is present if you use trellis (if you do than probably not), but I guess its worth checking anyways.
WPEngine also keep a list of disallowed plugins and provide explanations and alternatives for each listed item: https://wpengine.com/support/disallowed-plugins/ - if you use one of them in your installation it could be shutdown by WPEngine without notice.
Thanks Constantin, your feedback got me thinking. Turns out it works as expected in their staging environment which has no caching and different permissions. I’m working with their support again, and think I’ll have a solution here soon.
Would love an update for this. I just migrated a site for a client from my local environment to wpengine and got the white screen of death. You were right about the permissions and blade not being able to produce the cache.
I have been trying to figure out a way to remove blades cache
I’ve been talking to wpengine support to see if there is anything they can do about that
So far no luck, so if you find a solution I would love to hear it. It really makes me sad to think I won’t be able to use Sage because we WPENGINE for a lot of our hosting needs
I’ve run into the same issue. An interesting observation—the cache errors seem to interfere with the way blade directives work.
I have a number of directives that simply return a value, like this:
* Create @featured_img Blade directive --
* check if a featured image is big enough to use in single view
*/
sage('blade')->compiler()->directive('featured_img', function () {
return 'App\featured_image_check();';
});```
If I pull the directive out of my template and call the function directly, the template works as expected.
I’ve been talking with support on WPengine (specifically Jared) about this issue. The problem is that due to security restrictions in place by WPE where non logged in users are unable to create/modify/delete files. They do not place the same restrictions on staging so it will work as expected on staging but production will show a white screen. If you check the error logs it will return an error for file_put_contents.
I’d suggest using https://github.com/alwaysblank/blade-generate to compile your views during your build. However right now I am getting requests for filename hashes that don’t exist
I’m at WC Atlanta this weekend but I’ll try get a new version of my docker image for deploybot ready next week. In the meantime you can compile your Blade template in the same directory structure as your WPE install and upload via SFTP
@anon66789415 I was able to use the wp blade compile command from blade-generate.
FYI: I downloaded the command.php file from the repo, put it at the root of my Trellis dev site (site/) and updated the wp-cli.yml in that folder to require the command file:
path: web/wp
require:
- command.php
Then I was able to run wp blade compile from the Vagrant server using ssh in the web/wp folder (or using the --path arg).
I uploaded the compiled files to the WPEngine using SFTP.
I now have the same issue as you where you are getting requests for hashes that do not exist. Were you able to find any workaround?
I am desperate to make it work with WPEngine since I really like Sage and stuck on WPEngine. However it seems that this incompatibility outweighs the benefits of using Sage altogether.
You need to compile the Blade templates using the same folder structure as your WPEngine install since the hash is based on the file location. If you look at your error logs on http://my.wpengine.com for your install you’ll find the directory your site uses. Copy your site on your Vagrant box to that same folder and compile from there. This is the manual process to get your blade templates working.
To automate this I need to extract the Sage container to work outside of WordPress context since my Docker image does not have a database and wp-cli requires one to use wp-cli. I haven’t really looked into how easy this is or whether it’s possible.
I tried to use the correct path but still have errors. I should be doing something wrong.
I went back and used v8.5.1. It is working without issues.
I’ll use v9 probably when it will not be in beta anymore.
Is there a solution that doesn’t require CI or compiling from /nas/content? Would be great to get it to work. Has anyone got WPEngine to budge about this?