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.
Would love to find a simple solution to all of this.
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,
Multiple layouts in Sage 9?
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.
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!