Compiled files not getting fingerprint rails - javascript

I have a number of environments where I deploy an application. In two of them I deploy the following configuration for assets:
config.assets.enabled = true
config.assets.compress = false
config.assets.compile = true
config.assets.precompile = false
config.assets.digest = true
config.assets.debug = false
config.serve_static_assets = true
My applicaton.js, that compiles a number of .js files on it, is not getting a fingerprint, so I don't serve changes to customers that have already cached it.
The web page then serves all assets precompiled with fingerprint except application.js
Where can I start to look for this failure?

The culprit is the following option :
config.assets.compile = true
It will live compile each file without fingerprint and serve them straight for rails
You should set it to false and use config.assets.precompile which should contain the list of all precompiled filed :
config.assets.precompile += %w(application.js foo.js)
Then don't forget to run rake assets:precompile in your deployment task to recompile new assets.
On a side note, you should also set config.serve_static_assets to false and let nginx / apache / your web server handle it for you, serving assets from rails has a big overhead.

Related

Rails 3.2 continues to serve OLD version of JavaScript asset file - Development Env

I have a Rails 3.2 application, and in it I have a Javascript file (app.'s) which appears to be 'stuck' at a particular, past, version. I've updated the file many times, changing its contents significantly, and being sure each time to Save the file - to no effect. I've rebooted the machine multiple times (thinking at least THAT should clear out the cobwebs) all to no avail. I'm at my wits end trying to think of ways to un-stick this.
I can see that the file is being served, each time I visit the page:
Started GET "/dev-assets/app.js?body=1" for 172.16.0.12 at 2014-04-24 16:49:36 -0700
Served asset /app.js - 200 OK (1ms)
And then later in the same test run (not modified - as I expect):
Started GET "/dev-assets/app.js?body=1" for 172.16.0.10 at 2014-04-24 16:51:31 -0700
Served asset /app.js - 304 Not Modified (0ms)
But STILL it has the old contents (which, have a call to 'location.assign' which has since been removed - so the behavior should be significantly different than what I'm seeing.
I have these settings in my development.rb file (but this is not the complete file):
config.cache_classes = false
# Log error messages when you accidentally call methods on nil.
config.whiny_nils = true
# Show full error reports and disable caching
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
# From Rails issue 10091 - attemp to keep from loading scripts
# multiple times
config.assets.prefix = "/dev-assets"
# Do not compress assets
config.assets.compress = false
# Expands the lines which load the assets
config.assets.debug = true
# Workaround documented in Rails issue 4145
config.serve_static_assets = false
Anyone have any idea how I can clear this old file?
Note - this is very similar to:
Clear the cache from the Rails asset pipeline
But none of those suggestions have helped me.
This isn't a Rails problem. Rails is serving up the correct file, as verified by by fetching the file in the browser:
http://localhost:3000/dev-assets/app.js

Rails custom layouts - routingerror in production

I have an admin section of my site that uses an 'admin' layout.
class Admin::BaseController < ActionController::Base
layout "admin"
in layouts/admin.html.slim
= stylesheet_link_tag "admin", :media => "all"
= javascript_include_tag "admin"
I get an error for the admin.js and admin.css
Started GET "/stylesheets/admin.css" for x.x.x.x at 2013-10-25 13:18:16 +0000
F, [2013-10-25T13:18:16.505425 #31550] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/stylesheets/admin.css"):
this works perfectly in development and the frontend assets are loading normally in production, what can the problem be?
The reason is that your rails server (webrick, thin, ...) serves your assets uncompiled, where it looks for it in several places (like app/assets or vendor/assets). In production, rails assumes that the production webserver handles asset serving, which are served from public/.
Since compilation on runtime – or delivering them uncompiled at all – slows down page serving, they are compiled into the name of its known manifest-files that reference your styles (that is application.{css/js} by default), which you do by invoking rake assets:precompile.
Add config.assets.precompile += %w( admin.css ) to config/application.rb or config/environments/production.rb to add your admin.css manifest so rails know that it also has to compile that one. Then run rake assets:precompile (if you've put it into the later, you may need to add RAILS_ENV=production).

Jquery not working after precompile

An image was causing a problem on my heroku app so I changed config.assets.compile = false to config.assets.compile = true in production.rb. I then ran rake assets:precompile and pushed to the heroku server. Jquery works fine on the app website, but no longer works on my local copy. No errors are thrown in the javascript console. Here are some important files as they stand now.
Production.rb
Nonogrammed::Application.configure do
# Settings specified here will take precedence over those in config/application.rb
# Code is not reloaded between requests
config.cache_classes = true
# Full error reports are disabled and caching is turned on
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
# Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = false
# Compress JavaScripts and CSS
config.assets.compress = true
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = false
# Generate digests for assets URLs
config.assets.digest = true
# Defaults to nil and saved in location specified by config.assets.prefix
# config.assets.manifest = YOUR_PATH
# Specifies the header that your server uses for sending files
# config.action_dispatch.x_sendfile_header = "X-Sendfile" # for apache
# config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect' # for nginx
# Force all access to the app over SSL, use Strict-Transport-Security, and use secure cookies.
# config.force_ssl = true
# See everything in the log (default is :info)
# config.log_level = :debug
# Prepend all log lines with the following tags
# config.log_tags = [ :subdomain, :uuid ]
# Use a different logger for distributed setups
# config.logger = ActiveSupport::TaggedLogging.new(SyslogLogger.new)
# Use a different cache store in production
# config.cache_store = :mem_cache_store
# Enable serving of images, stylesheets, and JavaScripts from an asset server
# config.action_controller.asset_host = "http://assets.example.com"
# Precompile additional assets (application.js, application.css, and all non-JS/CSS are already added)
# config.assets.precompile += %w( search.js )
# Disable delivery errors, bad email addresses will be ignored
# config.action_mailer.raise_delivery_errors = false
# Enable threaded mode
# config.threadsafe!
# Enable locale fallbacks for I18n (makes lookups for any locale fall back to
# the I18n.default_locale when a translation can not be found)
config.i18n.fallbacks = true
# Send deprecation notices to registered listeners
config.active_support.deprecation = :notify
# Log the query plan for queries taking more than this (works
# with SQLite, MySQL, and PostgreSQL)
# config.active_record.auto_explain_threshold_in_seconds = 0.5
end
Application.js
//= require jquery
//= require jquery_ujs
//= require jquery.ui.core
//= require jquery.ui.widget
//= require jquery.ui.mouse
//= require jquery.ui.draggable
//= require twitter/bootstrap
//= require_tree .
$(function() {
$( "#draggable" ).draggable({ handle: "#handle" , containment: [0,0,1200,1000] , cursor: "crosshair" });
});
UPDATE: This was caused by deleting an image , making a new image with the same name, and then pushing to heroku. Don't do that!
There's no need to precompile on your local. Sprockets automatically compiles static asset at server start.
To resolve things, delete the compiled files in the public/assets directory, commit your changes, then deploy to Heroku again.
Then, in Heroku, compile your assets by running the following from your command line:
# from command line via the Heroku Toolbelt
rake run assets:precompile
Your local assets will compile on server start (thus rendering jQuery usable again), and your assets on Heroku will be precompiled to the public/assets directory as they should be.
UPDATE:
You may need to clear your browser cache to ensure that the updated asset path is loaded into your markup.

Rails Heroku Precompiled Assets Not Loading JS?

I'm setting up my Rails app on Heroku, and running into a problem where all my CSS assets are loaded but none of my JS assets are. I'm using memcached, and followed these instructions: https://devcenter.heroku.com/articles/rack-cache-memcached-rails31.
One thing I noticed is that when I change config.assets.compile to "true" in my production.rb file, all the JS is loaded successfully but obviously the initial load of the site is tremendously slow. How can I troubleshoot this problem? I'm new to Heroku, so am unsure and haven't found anything online that is helpful.
I assume that since all my JS files are in /assets/javascripts/, that the should be included automatically, but it seems as if they're not.
Here's my production.rb:
BrainDb::Application.configure do
# Settings specified here will take precedence over those in config/application.rb
client = Dalli::Client.new
config.action_dispatch.rack_cache = {
:metastore => client,
:entitystore => client,
:allow_reload => false
}
# Code is not reloaded between requests
config.cache_classes = true
# Full error reports are disabled and caching is turned on
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
# Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = true
config.static_cache_control = "public, max-age=2592000"
# Compress JavaScripts and CSS
config.assets.compress = true
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = false
# Generate digests for assets URLs
config.assets.digest = true
config.i18n.fallbacks = true
# Send deprecation notices to registered listeners
config.active_support.deprecation = :notify
end
I also removed everything from public/assets so it would precompile. Here's application.rb:
require File.expand_path('../boot', __FILE__)
require 'rails/all'
if defined?(Bundler)
# If you precompile assets before deploying to production, use this line
Bundler.require(*Rails.groups(:assets => %w(development test)))
# If you want your assets lazily compiled in production, use this line
# Bundler.require(:default, :assets, Rails.env)
end
module BrainDb
class Application < Rails::Application
# Configure the default encoding used in templates for Ruby 1.9.
config.encoding = "utf-8"
# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password]
# Enable escaping HTML in JSON.
config.active_support.escape_html_entities_in_json = true
config.active_record.whitelist_attributes = true
config.assets.initialize_on_precompile = false
# Enable the asset pipeline
config.assets.enabled = true
config.cache_store = :dalli_store
# Version of your assets, change this if you want to expire all your assets
config.assets.version = '1.0'
end
end
UPDATE
Application.js:
//
//= require jquery
//= require jquery_ujs
Add
//= require_tree . at last and precompile
in your application.js.

Rails assets still being served in single file in development

In my development.rb I have
config.assets.debug = true
config.assets.compress = false
However my assets are being served in single files"
images/application.js
javascripts/application.css
I have deleted the cache files from tmp/cache & restarted the server but assets are still served in a single file (not compressed by the way).
I'm running Rails 3.2.13.
Has anyone got any ideas?

Categories