Laravel и просмотр кэширования в процессе разработки – не могут сразу увидеть изменения

Некоторые друзья и я решили начать работу над проектом, и мы встретили Laravel и подумали, что это хороший инструмент. Мы начали использовать его локально, чтобы разработать некоторые из наших страниц и заметили что-то странное.

Когда мы обновляем представление с различной информацией, потребуется около 5-10 минут, прежде чем информация о просмотре изменится. Это похоже на то, что Laravel кэширует представление и ставит TTL на него.

Я знаю, что это не то, что я делаю на своем локальном веб-сервере, потому что я использовал другие фреймворки, и я никогда не сталкивался с этой проблемой.

При поиске в Интернете я не могу найти отличный ответ о том, как отключить это. Я хочу использовать Laravel, но считаю это бесполезным, если требуется, чтобы мои взгляды обновлялись каждый раз, когда я хочу внести изменения. На самом деле это звучит неэффективно.

Есть ли способ отключить это? Почему мои взгляды навсегда навсегда обновляются из коробки?

Канал IRA IRARALE – это послание Бога. Это никак не связано с поведением Ларавеля. На самом деле это то, что делал PHP 5.5.

Причина, по которой это было настолько непонятно, – это то, что я обновил версию PHP с 5.3 и никогда не сталкивался с этой проблемой.

В вашем .ini-файле вам нужно настроить настройки OPcache. Для меня эти настройки начинались с строки 1087 в файле .ini и выглядели примерно так:

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

Особо следует отметить opcache.revalidate_freq=60 . Это то, что на самом деле делает ваш кеш просмотров. Если это не является желаемым поведением, установите значение 0 и ваши представления будут обновляться каждый раз, когда вы вносите изменения. Ура!

ИЗМЕНИТЬ 21 августа 2014 года

Как упоминалось в Мэтт ниже, обязательно перезапустите веб-сервер, чтобы увидеть, как ваши изменения вступают в силу после изменения вашего .ini-файла.

С более новыми версиями PHP opcache не работает. Это то, что я использую (в 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); } } } }); 

Возможно, это не проблема кеширования и не имеет ничего общего с Laravel, Apache или PHP. Если вы делите файлы на виртуальную машину, например, Vagrant, убедитесь, что ваш редактор не использует «Atomic Saves» при записи файлов.

Чтобы проверить это, сделайте небольшое редактирование (одиночный символ) в просматриваемом файле с помощью нескольких текстовых редакторов. Изменения, сохраненные от редакторов, которые реализуют атомные сейвы, вероятно, не будут замечены файловой системой VM.

Я редактирую Sublime Text 3 на Mac, сохраняя файлы в папку, которая монтируется в Vagrant VM с NFS. Файлы просматриваются в локальной файловой системе через Gulp, и обновление обновления с помощью педалей запрашивается у хозяина Vagrant всякий раз, когда файл изменяется.

Изменение одного символа с помощью Sublime Text 3 с использованием atomic_save: true по умолчанию atomic_save: true запускает изменение, но не обслуживает обновленный файл. Редактирование в Vim, TextEdit, Sublime Text 2 и TextWrangler всех инициированных обновлений и обслуживание обновленного содержимого файла. Переключение на atomic_saves: false привносит Sublime Text 3 в ряд с другими редакторами, вызывая обновление и обслуживая правильный файл.

Предпочтения по умолчанию Sublime Text 3 включают этот комментарий:

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

Проблема может иметь какое-то отношение к изменениям, которые записываются в неподписанный tempfile, а затем в том, что tempfile заменяет наш просмотренный файл. Модификация происходит, когда файл temp написан, а не когда он заменяет файл, который мы просматриваем, поэтому не запускается обновление. Это или что-то с кешем NFS или шлюзом NFS VirtualBox – в середине есть много вещей.

Много часов было потрачено впустую, играя с opcache, модами Apache и халатами Laravel, прежде чем обнаружить, что это всего лишь настройка редактора.

У меня была такая же проблема, как избежать кэширования в админе, поскольку загруженные изображения не обновлялись. Я не рекомендую отключать кеш для всех ваших php-приложений, вы можете это изменить заголовки. Добавить / изменить эту функцию в app/filters.php :

 Route::filter('after', function($response) { // No caching for pages, you can do some checks before $response->header("Pragma", "no-cache"); $response->header("Cache-Control", "no-store, no-cache, must-revalidate, max-age=0"); }); 

Другая возможность, если вы используете виртуальную машину (например, Vagrant), и делиться файлами с вашего хоста через NFS, – это то, что NFS кэширует время модификации. Это заставило бы Laravel думать, что кэшированные скомпилированные шаблоны все еще свежи. Это проблема, с которой я столкнулся сегодня, и решил ее (и связанная с этим проблема с gulp-watch, не замечающая, что файлы стилей и javascript менялись), добавив параметр mount mount lookupcache=none .

Я написал об этом здесь: просмотр файлов для изменений в Vagrant, время изменения файла не обновление

Я должен был также настроить дату / время.

Я использую phpStorm для sftp синхронизации моих файлов ( так как он будет быстрее загружать страницы сервера на виртуальной машине) с помощью VirtualBox Laravel Homestead. В дополнение к opcache.revalidate_freq=0 мне также пришлось убедиться, что у Homestead VM была дата / время, которое было старше операционной системы хоста. В противном случае система не думает, что что-то изменилось.

В ubuntu сделайте sudo dpkg-reconfigure tzdata и установите часовой пояс. Затем, если, например, ваша хост-система в настоящее время находится в 11:01:00, установите VM на несколько более старое время sudo date --set 11:00:50 .

Затем sudo nginx restart . Работал как шарм!

Более того, не забывайте, что это взято из: http://php.net/manual/en/opcache.configuration.php#ini.opcache.revalidate-freq

«Эта директива конфигурации игнорируется, если параметр opcache.validate_timestamps отключен».

Это было для меня.