I read the GitHub issue comment about the deprecation of the border-radius mixin. With Bourbon 3.0 you should use the standard CSS border-radius: 6px;.
codenapse-team: I'm sorry if this sounds too obvious, but the code you posted still had the comment characters ('//') on each line. If you'd like to change the color, the line should look like this: $topbar-bg-color: #9c1;
Is there a reason the personal view uses form_for @user while the social view uses form_for current_user? Since the controller sets @user to current_user, I suspect the views got created at different times and there's no real difference in this case. Though it seems like @user would be the better choice, since the controller can … control that value.
You mention (@7:10) that if you're not using Heroku, you don't use environment variables.
Wouldn't the CONFIG hash solution work on Heroku also? If Heroku itself were looking for a setting in the environment variables, that would be a reason to use environment variables. In all of the screencast examples (auth & mail settings), we have control of both the definition and usage of the configuration method.
There's quite a bit of discussion of sass in the GitHub issues.
I'm not yet running 3.1, but I got around a similar sass problem in 3.0 by generating the assets locally, then putting this in an initializer: Sass::Plugin.options[:never_update] = true
I read the GitHub issue comment about the deprecation of the
border-radius
mixin. With Bourbon 3.0 you should use the standard CSSborder-radius: 6px;
.codenapse-team: I'm sorry if this sounds too obvious, but the code you posted still had the comment characters ('//') on each line. If you'd like to change the color, the line should look like this:
$topbar-bg-color: #9c1;
Is there a reason the personal view uses
form_for @user
while the social view usesform_for current_user
? Since the controller sets @user to current_user, I suspect the views got created at different times and there's no real difference in this case. Though it seems like @user would be the better choice, since the controller can … control that value.You mention (@7:10) that if you're not using Heroku, you don't use environment variables.
Wouldn't the CONFIG hash solution work on Heroku also? If Heroku itself were looking for a setting in the environment variables, that would be a reason to use environment variables. In all of the screencast examples (auth & mail settings), we have control of both the definition and usage of the configuration method.
Check out https://github.com/harvesthq/chosen/pull/166
Thanks for the hint -- exactly what I needed for my "legacy" app.
A nice enhancement in version 0.3.2, you can turn your site title into a link. For instance to get out of admin mode and back to your regular site:
config.site_title_link = :root
Put your custom css in a separate file and tell ActiveAdmin to load it: https://github.com/gregbell/active_admin/issues/261
There's quite a bit of discussion of sass in the GitHub issues.
I'm not yet running 3.1, but I got around a similar sass problem in 3.0 by generating the assets locally, then putting this in an initializer:
Sass::Plugin.options[:never_update] = true
Try this (note the quotes around the condition):
validates_presence_of :company_id, :if => "new_company_name.blank?"