They told me they wont budge. Because its using file_put_contents which they will not support. Hope they change their mind.
@ivantipov the only other solution is to drop Blade.
Would love to find a simple solution to all of this.
Is there any way to modify the way these cache filenames are generated so that it doesn’t rely on hashes of the wp installs uploads/cache path? I’m uncertain if these are generated through illuminate or something in lib/Sage/ at this point.
WP Engine Sage 9 Fix
After a couple of different support agents today one was able to help. Ask your support agent to change the nginx configuration. Here is what he changed it to:
I placed this in the “Before-in-location” portion of the server block
“set $is_trusted 1;”
1 minute later the white screen of death had disappeared
@tommb That’s great to hear. Thanks for reporting!
I’d love to know if anyone else has also been able to solve the issues with WPE by doing this!
So I just got word from a senior WPE tech saying they aren’t going to allow these NGINX before in-rules anymore due to security problems that could potentially arise with other users installs.
But in that frustrating discussion, he pointed me to the simplest solution I’ve found for generating these cache files on production.
Here’s an email from the tech:
I’m still looking into this myself to see what I can find, but I think one potential solution would be to change where the cache files are compiled. To explain a bit more specifically on why this won’t work, we have some restrictions in place that prevents writing to php files unless the user is authenticated. Since the cache files are being stored at wp-content/uploads/cache/*.php, that’s why it’s running into this problem. Here’s where I was able to find that defined in wp-content/themes/sage/config/view.php:
/* |-------------------------------------------------------------------------- | Compiled View Path |-------------------------------------------------------------------------- | | This option determines where all the compiled Blade templates will be | stored for your application. Typically, this is within the uploads | directory. However, as usual, you are free to change this value. | */ 'compiled' => wp_upload_dir()['basedir'].'/cache',
If we’re able to switch that directory to /tmp, I think this should work without any custom rules being required. I’m looking into the theme documentation to see if that may be an easy change, but wanted to run this by you in case you may know of an easy way to do this.
So just now, I changed that ‘compiled’ directory to ‘/tmp/sage-cache’ and voila, no permission issues and I’m able to generate cache after pushing a theme up to a WPE production install.
EDIT: I’ve noticed with some of the older sites I’ve built, that the config/view.php directory and file don’t exist. Looks like this change was made about 4 months ago so your sage theme will have to have been created after that change happened for this fix to work.
This is huge for me as I’ve pushed several of these sites on to WPE and have had to deal with a chat agent every time.
Hope this helps fellow Sage/WPE users,
Very helpful! Thanks!
Legend - this looks like the way forward! Cheers for the tip
So far this is not working for me. I’m chatting to a support person right now and he’s saying that so far this issue hasn’t been resolved.
Do I need to define a temp directory within the wp-config.php?
This is what I have in my view.php
'compiled' => wp_upload_dir()['basedir'].'/tmp/sage-cache',
Re-read the solved post in this thread and note the value. You aren’t using the same one.
Hi. There are times (maybe many times) I just can’t control hosting. I run into WPE a lot (I actually kind of like it). Has changing the compile directory to ‘/tmp/sage-cache’ been the fix? Any caveats?
Also, have there been any other obstacles with other hosting? I imagine this might occur on managed hosting type scenarios. Another one I am thinking of starting to use is Flywheel.
Hey @John - changing that path has worked for me with no issues or caveats. Easy and as far as I can tell complete fix.
@mmirus Thanks. That’s what I like to hear : ) .
Confirmed. This worked for me and allowed me to duplicate and use template-custom.blade.php.
To echo what I did:
in sage > config > view.php
'compiled' => wp_upload_dir()['basedir'].'/cache',
'compiled' => '/tmp/sage-cache',
And re-upload your view.php file.
For the first it was ok.
Now it seems like the add to cart, and all the cart stuff doesn’t work. For example if you add to cart product, then another, there is only one product in the cart. Cart icon with number of items in it is not updated. Everything works perfectly while youre logged in as admin, but after logout it stops.
I’m afraid that I will have to recreate theme files to simple ones. As Sage is too complicated using it with WPEngine
@Sid - are you testing this on WP Engine’s production or staging environment? If in production, that actually sounds like it might not be a Sage-related problem, but a problem with WP Engine’s caching layer. I would hop on chat with their support and talk with them about creating exceptions in their caching for your cart page and cookies, and anything else you might need to do.
Basically, any time there is user- or session-specific content in your theme (like a shopping cart) you will need to make sure those parts of the theme/templates aren’t being cached by WP Engine. Same for info they depend on from the client, like cookies. You can do that by creating exceptions in their caching layer (by talking with support) or by loading those pieces of content separately via an AJAX call after the page has loaded.
Ahhhh You were right. Thank You for pushing me to contact them. As yesterday I was chatting with them all day because of this topic problem. So i really haven’t thought they will help me with this. Thank You again!
@toby - your link above is broken, here’s the correct one:
Can anyone confirm that this process still works with the latest versions of Trellis, Bedrock and Sage?
We have a project we built for a client currently being controlled with Github and hosted on a DO droplet. They are insistent that the final staging and production environments are hosted with WPEngine.
We’re trying to get them to consider Kinsta but have a feeling they won’t want to switch. Ben Word wrote a great article on how to use Bedrock and Trellis on Kinsta, so that seems like a no brainer for a client wanting to use managed hosting --> https://kinsta.com/blog/bedrock-trellis/
Anyone have an recent news on this stack with WPEngine?
Thank you all.
AFAIK you just can’t use Trellis and Bedrock on WPE, only Sage. Someone else may have better info, though.
That is my understanding as well.
Getting Sage to run on WPE was a pain on it’s own, but I don’t think it’s possible to manipulate the root folder structure of a WPE install and have it work properly. If you need Trellis and Bedrock to work, I’d suggest saving yourself the headache and attempting to convince them to switch over to a Kinsta install.