Rails с использованием кэшированного application.css, несмотря на изменения

Ответ 1

У меня была такая же проблема. Я остановил сервер, выполнил rm -fr tmp/cache, и мои файлы css были окончательно восстановлены.

Ответ 2

У меня была знакомая проблема после запуска rake assets:precompile в разработке. Возможно, Rails обслуживает предварительно скомпилированные активы из public/assets? Попробуйте очистить это.

Вам не нужно касаться aplication.css.scss в разработке, rails должен обслуживать новый контент, когда изменяется один из файлов @included.

Кроме того, убедитесь, что в config/environments/development.rb

# Do not compress assets
config.assets.compress = false

# Expands the lines which load the assets
config.assets.debug = true

Ответ 3

Во-первых, обычные проверки очистки кэша могут помочь. Очистить кеш браузера. Очистить кеш файл сервера (если вы находитесь в dev/test или можете позволить себе в производстве) и sass-cache:

rake tmp:cache:clear
rm -fr tmp/sass-cache #or 'compass clean' if using compass

Если это не поможет, возможно, Rails скомпилировал ANOTHER application.css в другом месте (что не удалось удалить с помощью очистки кэша)?

Например, я выполнил compass watch app/assets/stylesheets/application.css.scss для целей отладки и создал файл public/asset/application.css, который в силу его местоположения в общедоступном/предотвратил замедление любых изменений в таблице стилей application.css.scss по Rails. Как только я удалю его, приложение снова вытащит из таблиц стилей .scss. Это всего лишь один пример случайного переопределения создания файла. Попробуйте запустить find во всем каталоге приложений, который ищет любые сгенерированные файлы application.css, делая это после очистки кеша, чтобы избежать появления в ваших результатах.

(FYI, чтобы избежать моей конкретной проблемы, теперь я запускаю просмотр компаса с -css-dir, указанным в кеше, чтобы предотвратить проблему.

$ compass watch app/assets/stylesheets/application.css.scss  --css-dir tmp/cache/

)

Ответ 4

Чтобы уничтожить кеш конвейера ресурсов, грубая сила rm -rf tmp/* будет достаточно. Это, безусловно, зафиксировало несколько иначе необъяснимых CSS и Ошибки JavaScript в моем опыте. В качестве превентивной меры это также может быть хорошей идеей очистить кеш после обновления драгоценных камней или изменение конфигурации конвейера активов, хотя это может быть просто суеверие.

Наконец, если вы экспериментируете с рейк-активами: прекомпилируйте в своем среды разработки (подробнее об этом в более поздней статье), вы также захотите rm -rf public/assets/* после этого очистить это.

http://blog.55minutes.com/2012/02/untangling-the-rails-asset-pipeline-part-1-caches-and-compass/

Ответ 5

Случайно У меня была проблема кеширования, связанная с использованием twitter bootstrap и application.css.scss. В основном я изменил application.css.scss на простое application.css и исправил свою проблему. Может быть, это может вам помочь? Если вы еще не поняли это.

Ответ 6

У меня была эта проблема, но я фактически помещал css в application.css, а не в файлы, которые он включал. Я очистил application.css, чтобы просто включить все мои css. Итак, my application.css теперь выглядит следующим образом:

/*
 * This is a manifest file that'll be compiled into application.css, which will include all the files
 * listed below.
 *
 * Any CSS and SCSS file within this directory, lib/assets/stylesheets, vendor/assets/stylesheets,
 * or vendor/assets/stylesheets of plugins, if any, can be referenced here using a relative path.
 *
 * You're free to add application-wide styles to this file and they'll appear at the top of the
 * compiled file, but it generally better to create a new file per style scope.
 *
 *= require_self
 *= require 'bootstrap.min'
 *= require 'global'
 */

Мои изменения отражаются при каждом изменении одного из включенных файлов (например, global.css)