Я развернул это приложение (rails 3.2.11) миллион раз, я не испортил никаких настроек, но теперь меня встретили следующим образом:
Почему это произошло неожиданно? Мои приложения application.rb включают config.assets.enabled = true - никогда не возникало проблем.
Фактически, его запуск локально на порт 3000, похоже, не имеет каких-либо проблем.
После развертывания в heroku этим утром кажется, что он ничего не загружает внутри /assets/
Интересно, что после копирования файлов, чтобы попробовать и просто создать новое приложение, git commit приведет к тому, что вы ожидаете, а также длинный список из них, который, как я думаю, может быть связан:
Изменить: Интересно, что некоторые из объектов загружены, как логотип и фон, но все остальное, как вы можете увидеть возврат 404.
У меня была эта проблема сегодня с рельсами 4 на героку. Статья, предоставленная @Jeff, немного устарела, но хранилище gem имеет хороший readme. Подводя итоги, вам нужно добавить два драгоценных камня в ваш Gemfile:
gem 'rails_serve_static_assets' (он решит проблему статических активов) иgem 'rails_stdout_logging' (от которого зависит предыдущий).положить строку в config/environment/production.rb
config.assets.compile = true
он работал, поскольку он будет компилировать активы во время выполнения, как и в среде разработки, но делает приложение медленным, лучший способ - либо скомпилировать активы локально в рабочей среде с помощью функции rake (RAILS_ENV = производственный пакет exec rake assets: precompile) и передать ваши сгенерированные активы в public/assets, а затем выполнить развертывание. или, heroku запустить rake assets: precompile
Heroku выпустила драгоценный камень для обработки активов без необходимости отключения компиляции или компиляции вручную.
https://devcenter.heroku.com/articles/ruby-support#static-assets
Просто добавьте это в свой Gemfile и повторно разверните.
gem 'rails_serve_static_assets', group: [:production]
Для Rails 4 используйте:
config.serve_static_assets = true
По умолчанию установлено значение false. Мы нуждались в этом после удаления драгоценного камня rails_12factor.
Rails рекомендовал отключить этот параметр config.serve_static_assets по умолчанию, т.е. установить значение false. Вот конфигурация по умолчанию в config/environments/production.rb, сгенерированная в rails app
config.serve_static_assets = false
Итак, если вы устанавливаете его в true в своем локальном приложении, тогда это все равно. Но если вы развертываете свое приложение на Apache или ngix или что-то другое, кроме heroku, то не рекомендуется делать config.serve_static_assets=true в вашем файле конфигурации production.rb. Вот документация из направляющих Rails.
config.serve_static_files настраивает Rails для обслуживания статических файлы. Значение по умолчанию равно true, но в рабочей среде как серверное программное обеспечение (например, NGINX или Apache), используемое для запуска вместо этого приложение должно использовать статические активы. В отличие от установите для этого значение true при работе (абсолютно не рекомендуется!) или тестирование вашего приложения в режиме производства с помощью WEBrick. В противном случае вы не будете быть в состоянии использовать кеширование страниц и запросы на файлы, которые существуют регулярно под общим каталогом все равно попадет в ваше приложение Rails.
Чтобы загружать активы с соответствующим отпечатком каждого файла, проверьте, что конфигурация config/environments/production.rb имеет инструкцию:
ruby
# Load assets with fingerprint behavior
config.assets.digest = true