CSS files are loaded for ALL the views (only trying in dev env). Quite annoying and will override your styles. To fix just move the app/assets/stylesheets/active_admin.css.scss to vendor/assets/stylesheets/active_admin.css.scss – It is only loaded when required then.
source:
http://robertomurray.co.uk/blog/2011/rails-fix-activeadmin-css-over-riding-problem/
yeah, that's kind of irritating.
Yeah, I had this issue as well. Thanks for the quick fix!
I tried this: http://mrdanadams.com/2011/exclude-active-admin-js-css-rails/
But I think it's outdated, and actually causes more issues than it solves...
+1
Don't forget to move the active_admin.js file from your assets to vendor/assets.
I submitted a PR to fix this issue awhile back but I don't think it ever got merged because of concerns about upgrading.
The reason you're seeing this problem is because you're probably doing something like require_tree .
in your application.css file. There are a number of ways to fix this, one of them is obviously just to move the active_admin.js/css to vendor/assets. Basically the short answer is that the reason it's requiring them everywhere is because you're telling sprockets to require them everywhere.
True, but this is the Rails default nowadays, so I would hope that Active Admin would conform to it!
I concur that this is a really annoying problem.
I am experiencing the same issue and have not been able to resolve it. I "removed" active_admin.css.css from /app/assets/stylesheets. I already had a copy of the file in /vendor/assets/active_admin. (Same thing for active_admin.js).
I am letting heroku precompile. The precompile process works. But, depending on what options I chose it either blows up when I try to access the /admin section of my site or my main site css gets overridden with active_admin.css
In production.rb I have - config.assets.precompile += %w[ 'active_admin.css.scss', 'active_admin.js' ].
Is there another fix to segregate active_admin.css from the main app?
@rodleg production.rb is not loaded as part of the asset precompile process. You need to put heroku-specific asset config in application.rb.
@latortuga thanks for the info. it turns out I did have -
config.assets.precompile += %w[ 'active_admin.css.scss', 'active_admin.js' ]
@rodleg yes that's what I meant by heroku-specific asset config, the altering of the precompile list. It's hard to say what exactly is happening without looking at your app but I would guess that if your styles are being applied globally, you should move active_admin.js/css to vendor/assets. If it's not being loaded, then I'd have to know more about where and how you have your asset files configured (e.g. do you have a custom manifest for the admin area? do you have any other js/css files for the admin area? if yes, how are they included? did you alter the active admin initializer to register the assets differently?)
The easiest way to get admin styles only loading in the admin area is to move the active_admin:assets files to vendor/assets and to ensure that they are a part of the precompile list manually:
# application.rb
class Application < Rails::Application
# assets pipeline config to work on Heroku
config.assets.initialize_on_precompile = false
# add active admin assets to precompile list, loaded from vendor/assets
config.assets.precompile += %w( active_admin.js active_admin.css.scss )
end
@latortuga Thanks a bunch for your help.
I was finally able to resolve this issue. I did have the two settings you referenced in application.rb. Also, I was basically running a vanilla version of active_admin.
Hopefully, my experiences will help someone else not have to deal with this.
I decided to try and run my application locally in production with RAILS_ENV=production and was able to duplicate the error.
It turns out that the setting that I was missing in application.rb was to set:
Bundler.require(:default, :assets, Rails.env)
@rodleg ahh good call! Having the :assets group available is essential for precompile so I could see why that would be a problem. Could I venture a guess that you upgraded your app from 3.0 to 3.1? I'm wondering what the particular circumstances are where this wouldn't be in the Bundler require call and I'm guessing it's probably only if you're upgrading to 3.1 or 3.2 because vanilla installs of those should include the :assets group.
@latortuga Actually, I am on 3.2.3 now but I believe that I started this app on 3.1 (and possibly 3.2 ) but I am not positive. Interestingly, I just created a new app on rails 3.2.3 and checked application.rb. It appears that the default setting is:
Bundler.require(*Rails.groups(:assets => %w(development test)))
It does tell you that if you want to lazily deploy your assets in production then you should set the following option:
Bundler.require(:default, :assets, Rails.env)
In addition to setting config.assets.initialize_on_precompile and config.assets.precompile I had to set the Bundler option to the later for this to work on in my production environment (both locally and on Heroku). Do you think that means that the need to set the Bundle.require option should be included in the documentation? I didn't see that it included in the various postings that I saw on the subject on this site or stackoverflow, etc.
+1 Moved my css / js to vendor. Agree with elsurudo that it should comply with Rails asset pipeline.
Closing since this is a year old. If anyone's still having issues, feel free to continue the discussion.
I just came across this problem using rails 4 and the master branch of activeadmin. Putting the assets in vendor fixed it.
@tomgrim1 almost certainly the problem you're running into is caused by you having require_tree .
in your application.css
(#2332), which will be automatically detected and resolved by #2514.
You're absolutely right, thanks for the heads up.
@seanlinsley @tomgrim1 I'm still having this issue and I can't seem to resolve it. I've tried removing the 'require_tree .' & moved active_admin.css.scss & active_admin.js.coffee to vendor/assets folder. Also tried the 'config.assets.precompile' line in the config/application.rb file, but still nothing.
Am I missing something simple?
@jegodwin I have no idea what might be causing that, and I don't have enough information to try and reproduce it. Can you create a test Rails app that reproduces this problem and upload it to Github?
I also ran into this issue on a new project. Moving the relevant files to vendor
fixed the issue for me.
@zachlatta can you provide some way to reproduce this? Without that, there's nothing I can do to help.
Hello,
@seanlinsley I also did run into the same problem( production on heroku). I googled for solution to this and tried probably half a dozen things but nothing seems to work.
The current state:
Still AA overrides my css on the front-end.
My environment is: ruby 2.1.2. Rails 4.1.6
Also uploaded sample project to github:
https://github.com/betasve/sample-aa-app
Please, let me know if you see something wrong there.
Thanks in advance.
Why does production.rb
add AA assets when they've already been added in application.rb
?
More importantly, what's happening here?
Picking from one of the many compiled application.css
files, AA styles are in this one even though the pre-compiled version never loads up AA.
Ok, I've removed the changes from application.rb:
and tried to delete most of the old assets in public. Never the less it still is ok on my local and not ok on Heroku.
Ok, I've figured out the problem. It took me some time to understand what you have meant, sorry :) I've added public/assets/** to my .gitignore file, so now I have my assets precompiled every time I deploy to heroku. It's ok now.
Thanks very much again for your help.
Glad you got it working :-)
Great fix, thanks for this! :)
Most helpful comment
I submitted a PR to fix this issue awhile back but I don't think it ever got merged because of concerns about upgrading.
The reason you're seeing this problem is because you're probably doing something like
require_tree .
in your application.css file. There are a number of ways to fix this, one of them is obviously just to move the active_admin.js/css to vendor/assets. Basically the short answer is that the reason it's requiring them everywhere is because you're telling sprockets to require them everywhere.