Roots Discourse

Fatal Error retrieving layout that doesn't exist anymore

Sage looks like it’s trying to find a layout file that no longer exists in file structure, or in any blade template in use.

In local dev, this is working as it should after either a yarn build or yarn build:production.

After a yarn build:production and upload to staging host, going to a custom post type that used to use the layout.eve, I see it outputs the fatal error:

**Fatal error** : Uncaught InvalidArgumentException: View [layouts.eve] not found... etc..

I’m uploading the following structure to staging:

app/
config/
dist/
resources/
vendor/
composer.lock
package.json
phpcs.xml
yarn.lock

I don’t think this is a frontend/yarn issue, but rather composer cache since you are mentioning layouts - templates. Try removing “cache” folder in /uploads/cache and refreshing the page (backup first perhaps)?

Also of course make sure that you actually changed to an existing layout and that layout path is correct.

Deleting the cache folder hasn’t resulted in any changes.

After cleaning the Composer cache at the bedrock level, and sage level there is still this issue of the host looking for a file that’s no longer referenced in any files.

Here is the overall error output:

Fatal error : Uncaught InvalidArgumentException: View [layouts.eve] not found. in /var/www/html/web/app/themes/sage/vendor/illuminate/view/FileViewFinder.php:137 Stack trace: #0 /var/www/html/web/app/themes/sage/vendor/illuminate/view/FileViewFinder.php(79): Illuminate\View\FileViewFinder->findInPaths(‘layouts.eve’, Array) #1 /var/www/html/web/app/themes/sage/vendor/illuminate/view/Factory.php(128): Illuminate\View\FileViewFinder->find(‘layouts.eve’) #2 /var/www/html/web/app/uploads/cache/7dba1d8614abb6529df806705a657a01ed064920.php(7): Illuminate\View\Factory->make(‘layouts.eve’, Array) #3 /var/www/html/web/app/themes/sage/vendor/illuminate/view/Engines/PhpEngine.php(43): include(’/var/www/html/w…’) #4 /var/www/html/web/app/themes/sage/vendor/illuminate/view/Engines/CompilerEngine.php(59): Illuminate\View\Engines\PhpEngine->evaluatePath(’/var/www/html/w…’, Array) #5 /var/www/html/web/app/themes/sage/vendor/illuminate/view/View.php(142): Illuminate\View\Engines\CompilerEngine->get(’/var/www/html/w…’, Array) #6 /var/w in /var/www/html/web/app/themes/sage/vendor/illuminate/view/FileViewFinder.php on line 137

Whatever blade you have that compiles to 7dba1d8614abb6529df806705a657a01ed064920.php is still probably trying to extend layouts.eve. You should be able to examine the code in that cached file to determine which blade it is (or do a text search through all your blades for layouts.eve.

Bingo! Thanks for navigating that. I had to download the entire production instance and delete the files that still existed there, but not on local dev.

Even after composer clear-cache, the problem still existed.

composer clear-cache wouldn’t have done anything in this situation. All that command does is clear Composer’s own cache, and all Composer’s cache contains is Composer packages (so it can avoid downloading them again if it doesn’t need to).

There is not currently a command in Sage that clears the blade cache (although I wrote a simple WP-CLI plugin that can delete/regenerate blades); the only way to do so is to just delete or empty the uploads/cache/ folder.

1 Like

Ahh that makes much more sense as a distinction for blade cache. I suppose this is a rare issue?

Either way thanks again.

In my experience yes, it is a rare issue. I’ve encountered it once or twice where blade somehow missed a change to a file and didn’t regenerate it. Since the fix is trivial (delete all cached blades, or use the plugin) it would be pretty easy to add a step to a Trellis deploy that clears out all blades when a new deploy is made (or you could even write a cron job if you’re really paranoid).