Sage/Acorn At WP Engine

sage
1

related thread and a few others.

The nutshell of that previous thread is that Sage / Acorn usage at WP Engine requires some workarounds to because the compiled file extension is .php, and WP Engine’s platform is preventing some requests from writing .php files to the filesystem. It seems to me that if we could get that file extension changed, or configurable, the problem would go away.

I’ve spent some time tracking down the underlying issue there, and the great folks at Laravel added configurability that should be available in a future cut of 9.x.

Once that is cut, it seems like the key integration point is in the ViewServiceProvider where there remains a file extension forced to .php, and I’m uncertain about whether the new configuration directive is automatically made available or requires additional wiring work.

Any thoughts there? Am I on a productive path?

2

I’m getting a feeling of silent agreement, or at least a silent desire for me to translate this observation into a concrete change to talk about. I’m going to look into making a change that introspects the base class of ViewServiceProvider to look for the new property, so that when available, the configured file extension is used for the “loader” file.

1 Like
3

Side change - running the tests with ./vendor/bin/pest fails on Mac due to case hijinks and an unexpected interaction with the phpunit loader attempting to load tests/Helpers.php automatically, and the bootstrap already loading it as tests/helpers.php. I may submit a separate patch for that, but thats for later :slight_smile:

4

Mirroring the Laravel change, this leads to a pretty small diff. My open challenge is that existing test coverage doesn’t seem to matter for it. I may float the change as is as a PR tomorrow, risk seems low.

--- a/src/Roots/Acorn/View/ViewServiceProvider.php
+++ b/src/Roots/Acorn/View/ViewServiceProvider.php
@@ -111,11 +111,12 @@ class ViewServiceProvider extends ViewServiceProviderBase
             $path = $this->getPath();
             $id = md5($this->getCompiled());
             $compiled_path = $app['config']['view.compiled'];
+            $compiled_extension = $app['config']->get('view.compiled_extension', 'php');

             $content = "<?= \\Roots\\view('{$view}', \$data ?? get_defined_vars())->render(); ?>"
                 . "\n<?php /**PATH {$path} ENDPATH**/ ?>";

-            if (! file_exists($loader = "{$compiled_path}/{$id}-loader.php")) {
+            if (! file_exists($loader = "{$compiled_path}/{$id}-loader.{$compiled_extension}")) {
                 file_put_contents($loader, $content);
             }
6

Contribution attempted. enable configuration of loader file extension by will0 · Pull Request #222 · roots/acorn · GitHub

And the testing issue, separate because its rather unrelated: make pest run test successfully on case insensitive filesystems by will0 · Pull Request #223 · roots/acorn · GitHub

7

Anything I can do to help outline the motivation for the proposed changes? Any issues I’m not considering?

8

Hey @will0 :wave:

Thanks for taking the time to really dig into this and get that upstream feature in there as well as your PR in Acorn. :pray:

I checked out your PR a few days ago. The main issue is that this feature is only added to L9, but the current stable version of Acorn is L8. My hope had been that the next release of L8 would have the feature added so I was waiting to see that come out. Unfortunately it’s not looking like they’re going to backport it.

All of this is to say that in order to get this into the current stable branch of Acorn, it will need to be implemented on our end. You’re welcome to handle that if you want, just make sure you’re targeting the 2.x branch and not the main branch.

9

It also just occurred to me that you could probably get around this issue all together if you precompile your views. Use wp acorn view:cache prior to deployment. You might consider checking out other commands that generate PHP cache files, such as for configs and providers. Acorn 2.x: WP-CLI | Roots Documentation

10

Hey thanks!

Absolutely generating the PHP files first would be ideal, there are just human factors in workflow adoption that are outside of my control there :slight_smile:

OK, I’ll find some time to target 2.x, thanks for helping me navigate the change!