Laravel and view caching in development -- can't see changes right away Laravel and view caching in development -- can't see changes right away laravel laravel

Laravel and view caching in development -- can't see changes right away


The #laravel IRC channel is a God send. This had nothing to do with Laravel's behavior at all. This was actually something PHP 5.5 was doing.

The reason this was so baffling is because I upgraded my PHP version from 5.3 and never had this issue.

In your .ini file, you need to tweak your OPcache settings. For me, these settings began at line 1087 in the .ini file and looked something like this:

opcache.memory_consumption=128opcache.interned_strings_buffer=8opcache.max_accelerated_files=4000opcache.revalidate_freq=60opcache.fast_shutdown=1opcache.enable_cli=1

Take particular note of the opcache.revalidate_freq=60. This is what is actually making your views cache. If this is not the desired behavior, set the value to 0 and your views will update every time you make a change. Yay!

EDIT AUGUST 21, 2014

As mentioned by Matt below, make sure to restart your web server to see your changes take effect after you have changed your .ini file.


With newer versions of PHP, opcache doesn't work. This is what I use (in app/filters.php):

App::before(function($request){    // Clear view cache in sandbox (only) with every request    if (App::environment() == 'sandbox') {        $cachedViewsDirectory=app('path.storage').'/views/';        $files = glob($cachedViewsDirectory.'*');        foreach($files as $file) {            if(is_file($file)) {                @unlink($file);            }        }    }});


It's possible this isn't a caching issue at all and doesn't have anything to do with Laravel, Apache or PHP. If you're sharing files into a Virtual Machine like Vagrant, be sure your editor is not using "Atomic Saves" when writing files.

To test this, make a small edit (single character) to a watched file using several different text-editors. Changes saved from editors which implement atomic saves likely won't be noticed by the VM's filesystem.

I'm editing with Sublime Text 3 on a Mac, saving files to a folder which is mounted into a Vagrant VM with NFS. Files are being watched on the local filesystem via Gulp and a livereload refresh is requested from the Vagrant host whenever a file changes.

Changing a single character with Sublime Text 3 using the default atomic_save: true triggers a change but doesn't serve the updated file. Editing in Vim, TextEdit, Sublime Text 2 and TextWrangler all triggered updates and served the updated file contents. Switching to atomic_saves: false brings Sublime Text 3 inline with the other editors, triggering an update and serving the correct file.

Sublime Text 3's default preferences includes this comment:

// Save via writing to an alternate file, and then renaming it over the// original file."atomic_save": true,

The problem might have something to do with changes being written to an unwatched tempfile, then that tempfile replacing our watched file. The modification happens when the tempfile is written, not when it replaces the file we're watching, so no update is triggered. That or something with the NFS cache or VirtualBox's NFS gateway -- there's a lot of stuff in the middle.

Many hours were wasted fiddling with opcache, Apache mods and Laravel hacks before discovering this was just an editor setting.