Ресурсы Rails 3.1 считываются в процессе производства, но визуализированный HTML — нет.

В разработке все отлично работает. И приложение развертывается как обычно с помощью Capistrano. Активы (javascript и css) кажутся полностью предварительно скомпилированными, и каждому, наряду с изображениями, дается «отпечаток пальца». Проблема в том, что при использовании image_tag("image-name.png"), на мой взгляд, html, который он создает в производстве, не включает «отпечаток пальца».

Отрендеренный HTML мы получаем в продакшене:

<img alt="Image-name" src="/assets/image-name.png" />

вместо того, что я ожидал, должно быть:

<img alt="Image-name" src="/assets/image-name-b89cae2830c2901f844c353b3f3942fe.png" />

Итак, какие из бесчисленных опций конфигурации Rails 3.1 мы испортили?

Изменить

Проблемные изображения, по-видимому, включены в сторонний Colorbox инструмент просмотра изображений, который мы используем. Rails 3.1 снимает отпечатки своих ресурсов (border.png и т. д.), но очевидно, что исходный код этой библиотеки javascript не использует помощников, таких как image_tag. Таким образом, в производстве он все еще ищет изображения с именем /assets/colorbox/border.png. В настоящее время изображения находятся в /vendor/assets/images и отлично работают в разработке. Есть ли способ предотвратить "отпечатки пальцев" только этих изображений?


ruby-on-rails ruby-on-rails-3 asset-pipeline fingerprinting
person Meltemi    schedule 14.09.2011    source источник
comment
Возможно, вы захотите проверить этот вопрос, stackoverflow.com/questions/7336265/   -  person basicxman    schedule 14.09.2011
comment
Согласно Руководствам по Rails: Настройка .assets.digest в Rails (верно для продакшена, ложно для всего остального). Таким образом, config.assets.digest следует принимать true в рабочей среде и false во всех остальных случаях. Или я неправильно читаю?!?   -  person Meltemi    schedule 14.09.2011
comment
добавление config.assets.digest = true к production.rb кажется частично полезным. Некоторые изображения (мои) работают. Но некоторые из них, включенные в сторонний инструмент javascript (см. редактирование в основном посте), которые мы используем, все еще «сломаны».   -  person Meltemi    schedule 14.09.2011
comment
Я с той же проблемой. Мои изображения на производстве не указывают на версии с отпечатками пальцев.   -  person Min Ming Lo    schedule 16.02.2012

Ответы (1)


arrow_upward
1
arrow_downward

Вот как я взломал сторонние файлы, чтобы все заработало:

Оскорбительные изображения находились в таких файлах, как vendor/assets/stylesheets/colorbox.css. Сначала я изменил расширение файлов на .scss, затем я изменил каждое url(colorbox/image.png) на image_url("color box/image.png"), и теперь все в порядке. Активы обычно обслуживаются в процессе разработки и снимаются в процессе производства.

Тем не менее, хотелось бы увидеть «правильный» способ добавления сторонних (поставщиков) javascript-библиотек и css в приложение Rails 3.1. Команда Rails, должно быть, предвидела готовое решение, которое не требует редактирования?!? Поэтому, пожалуйста, не стесняйтесь предлагать другие решения.

Кроме того: ранее я вручную настроил свой рецепт Capistrano с помощью:

run "cd #{release_path}; RAILS_ENV=production bundle exec rake assets:precompile"

…и сопутствующие ему after deploy:update_code …. Теперь я удалил эти строки и вместо этого добавил load 'deploy/assets к моему Capfile. Я не думаю, что это имеет какое-либо значение в вышеупомянутой проблеме, но я все равно хотел задокументировать ее, поскольку добавление собственного рецепта предварительной компиляции конвейера больше не требуется в Capistrano 2.8, как это было во времена 3.1rc.

person Meltemi    schedule 14.09.2011
comment
У меня ТОЧНО такая же проблема, я удивлен тем, как мало вопросов или сообщений в блогах по этой проблеме. Я выразил точное беспокойство в разделе комментариев Railscasts.com к эпизоду «Обновление до Rails 3.1», сказав то же, что и вы: почему команда Rails не ожидала сторонних библиотек с изображениями? Мы не можем углубляться в изменение url() для каждого файла css, с которым мы сталкиваемся. Это выглядит очень плохо. - person Nik So; 16.09.2011