-
Notifications
You must be signed in to change notification settings - Fork 11.4k
[5.3] Add the ability to disable caching of compiled Blade templates #13938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Under some circumstances, such as when in development, you may opt to disable caching of compiled Blade templates. This change allows caching to be overwritten via a view configuration option.
I think somewhat proposed this before and I thought it always made more sense to support just setting the "compiled" option in views.php to |
And just make an You'd still need to compile the template, you just want the cache to always present as expired, right? |
Yeah I guess so.
|
@@ -73,8 +73,9 @@ public function registerBladeEngine($resolver) | |||
// instance to pass into the engine so it can compile the views properly. | |||
$app->singleton('blade.compiler', function ($app) { | |||
$cache = $app['config']['view.compiled']; | |||
$shouldCache = $app['config']['view.should_cache'] ?: true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this doesn't work. If I set should_cache
to false it's just going to be true again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeh, this doesn't work
You're right @acasar. I did a little more digging based on Taylor's suggestion; setting the I'll do some more work on this this weekend. |
I've done a little more digging; it seems that with a fresh 5.2 install if you set Subsequent commits here should address both that bug, as well as changes discussed in this PR. It doesn't appear as simple as testing for |
Maybe |
Based on the above, I think that having a new config option may still be worthwhile, given the compiler engine requires including the compiled blade via path (and not passing a compiled string around). By the time execution gets to the engine, it has no knowledge of the compiled path being |
Not sure I'm going to end up adding this. There are already so many ways you could do it, such as a global middleware that checks env and runs view:clear or something. |
Thanks @taylorotwell - I agree, there's a few other approaches to this. Although on further inspection, there shouldn't even theoretically be a (server-side) caching issues anyway, given the way expirations are handled internally. |
@taylorotwell Just setting |
Under some circumstances, such as when in development, you may opt to disable caching of compiled Blade templates. This change allows caching to be overwritten via a view configuration option.