framework
framework copied to clipboard
Cache templates parts
I would like to have a cache where I can store some parts of my templates.
Be able to do something like this would e wonderful.
@cacheBlock("posts", 600)
@foreach($category->posts as $key => $post)
@include('modules.post', ["post" => $post])
@endforeach
@endCacheBlock
Unfortunately, I don't see how to implement something like this. I am trying to do something with php closure, but it's almost impossible to work with scout context.
<?php cacheTemplateBlock($univers->name, function() use ($univers, $post) {
?>
@foreach($univers->posts as $key => $post)
@include('modules.post-preview', ["post" => $post])
@endforeach
<?php
}, 0); ?>
I cannot find any documentation on extending Scout :/ So pity.
Any idea ? Previous experience, or wonderful fork bringing the solution ? Of course, I still can put my cache logic in the controller....
The best approach would be to add the Blade directive
method to the Scout API. Currently it's not implemented.
Currently, the master branch has the full version of Blade template engine loaded. You're able to use both scout.php
or blade.php
file extensions for your templates.
I'll look after a simple @cache
directive which stores a view/template for a limited time. Now perhaps this should be tight to the environment like if you're on a local one, do not cache content as it might update but if in another environment, cache the template and return it in place to re-render the (included) view.
@bactisme I'm looking at this to close issues for next release. The idea is to map a @cache
directive to the WordPress caching API so behind the scenes you can install whatever cache driver you want for this to work.
I'm currently out of ideas in order to make this to work. I cannot find a way to store the content shown between 2 blade directives. I've tried a @cache('view.path', 600)
directive where you can store/retrieve and display a sub-view but weirdly there are variables conflicts.
Actually, the best option is to store your data ($category->posts) in cache and pass it to the view. The process to render already stored data will be quite faster than going over the full process of retrieving the full data from database.
I'm keeping this open. We might find another solution to cache sub-views.