More at Overview | Download | Deploy | Code | Screencasts | Documentation | Ecosystem | Community | Blog

Configuring Rails Applications

This guide covers the configuration and initialization features available to Rails applications. By referring to this guide, you will be able to:

1 Locations for Initialization Code

Rails offers (at least) five good spots to place initialization code:

  • Preinitializers
  • environment.rb
  • Environment-specific Configuration Files
  • Initializers (load_application_initializers)
  • After-Initializers

2 Using a Preinitializer

Rails allows you to use a preinitializer to run code before the framework itself is loaded. If you save code in RAILS_ROOT/config/preinitializer.rb, that code will be the first thing loaded, before any of the framework components (Active Record, Action Pack, and so on.) If you want to change the behavior of one of the classes that is used in the initialization process, you can do so in this file.

3 Configuring Rails Components

In general, the work of configuring Rails means configuring the components of Rails, as well as configuring Rails itself. The environment.rb and environment-specific configuration files (such as config/environments/production.rb) allow you to specify the various settings that you want to pass down to all of the components. For example, the default Rails 2.3 environment.rb file includes one setting:

config.time_zone = 'UTC'

This is a setting for Rails itself. If you want to pass settings to individual Rails components, you can do so via the same config object:

config.active_record.colorize_logging = false

Rails will use that particular setting to configure Active Record.

3.1 Configuring Active Record

ActiveRecord::Base includes a variety of configuration options:

  • logger accepts a logger conforming to the interface of Log4r or the default Ruby 1.8.x Logger class, which is then passed on to any new database connections made. You can retrieve this logger by calling logger on either an ActiveRecord model class or an ActiveRecord model instance. Set to nil to disable logging.
  • primary_key_prefix_type lets you adjust the naming for primary key columns. By default, Rails assumes that primary key columns are named id (and this configuration option doesn’t need to be set.) There are two other choices:
    • :table_name would make the primary key for the Customer class customerid
    • :table_name_with_underscore would make the primary key for the Customer class customer_id
  • table_name_prefix lets you set a global string to be prepended to table names. If you set this to northwest_, then the Customer class will look for northwest_customers as its table. The default is an empty string.
  • table_name_suffix lets you set a global string to be appended to table names. If you set this to _northwest, then the Customer class will look for customers_northwest as its table. The default is an empty string.
  • pluralize_table_names specifies whether Rails will look for singular or plural table names in the database. If set to true (the default), then the Customer class will use the customers table. If set to false, then the Customers class will use the customer table.
  • colorize_logging (true by default) specifies whether or not to use ANSI color codes when logging information from ActiveRecord.
  • default_timezone determines whether to use Time.local (if set to :local) or Time.utc (if set to :utc) when pulling dates and times from the database. The default is :local.
  • schema_format controls the format for dumping the database schema to a file. The options are :ruby (the default) for a database-independent version that depends on migrations, or :sql for a set of (potentially database-dependent) SQL statements.
  • timestamped_migrations controls whether migrations are numbered with serial integers or with timestamps. The default is true, to use timestamps, which are preferred if there are multiple developers working on the same application.
  • lock_optimistically controls whether ActiveRecord will use optimistic locking. By default this is true.

The MySQL adapter adds one additional configuration option:

  • ActiveRecord::ConnectionAdapters::MysqlAdapter.emulate_booleans controls whether ActiveRecord will consider all tinyint(1) columns in a MySQL database to be booleans. By default this is true.

The schema dumper adds one additional configuration option:

  • ActiveRecord::SchemaDumper.ignore_tables accepts an array of tables that should not be included in any generated schema file. This setting is ignored unless ActiveRecord::Base.schema_format == :ruby.

3.2 Configuring Action Controller

ActionController::Base includes a number of configuration settings:

  • asset_host provides a string that is prepended to all of the URL-generating helpers in AssetHelper. This is designed to allow moving all javascript, CSS, and image files to a separate asset host.
  • consider_all_requests_local is generally set to true during development and false during production; if it is set to true, then any error will cause detailed debugging information to be dumped in the HTTP response. For finer-grained control, set this to false and implement local_request? to specify which requests should provide debugging information on errors.
  • allow_concurrency should be set to true to allow concurrent (threadsafe) action processing. Set to false by default. You probably don’t want to call this one directly, though, because a series of other adjustments need to be made for threadsafe mode to work properly. Instead, you should simply call config.threadsafe! inside your production.rb file, which makes all the necessary adjustments.

Threadsafe operation in incompatible with the normal workings of development mode Rails. In particular, automatic dependency loading and class reloading are automatically disabled when you call config.threadsafe!.

  • param_parsers provides an array of handlers that can extract information from incoming HTTP requests and add it to the params hash. By default, parsers for multipart forms, URL-encoded forms, XML, and JSON are active.
  • default_charset specifies the default character set for all renders. The default is “utf-8”.
  • logger accepts a logger conforming to the interface of Log4r or the default Ruby 1.8+ Logger class, which is then used to log information from Action Controller. Set to nil to disable logging.
  • resource_action_separator gives the token to be used between resources and actions when building or interpreting RESTful URLs. By default, this is “/”.
  • resource_path_names is a hash of default names for several RESTful actions. By default, the new action is named new and the edit action is named edit.
  • request_forgery_protection_token sets the token parameter name for RequestForgery. Calling protect_from_forgery sets it to :authenticity_token by default.
  • optimise_named_routes turns on some optimizations in generating the routing table. It is set to true by default.
  • use_accept_header sets the rules for determining the response format. If this is set to true (the default) then respond_to and Request#format will take the Accept header into account. If it is set to false then the request format will be determined solely by examining params[:format]. If there is no format parameter, then the response format will be either HTML or Javascript depending on whether the request is an AJAX request.
  • allow_forgery_protection enables or disables CSRF protection. By default this is false in test mode and true in all other modes.
  • relative_url_root can be used to tell Rails that you are deploying to a subdirectory. The default is ENV['RAILS_RELATIVE_URL_ROOT'].

The caching code adds two additional settings:

  • ActionController::Caching::Pages.page_cache_directory sets the directory where Rails will create cached pages for your web server. The default is Rails.public_path (which is usually set to RAILS_ROOT “/public”+).
  • ActionController::Caching::Pages.page_cache_extension sets the extension to be used when generating pages for the cache (this is ignored if the incoming request already has an extension). The default is .html.

The dispatcher includes one setting:

  • ActionController::Dispatcher.error_file_path gives the path where Rails will look for error files such as 404.html. The default is Rails.public_path.

The Active Record session store can also be configured:

  • CGI::Session::ActiveRecordStore::Session.data_column_name sets the name of the column to use to store session data. By default it is ‘data’

3.3 Configuring Action View

There are only a few configuration options for Action View, starting with four on ActionView::Base:

  • debug_rjs specifies whether RJS responses should be wrapped in a try/catch block that alert()s the caught exception (and then re-raises it). The default is false.
  • warn_cache_misses tells Rails to display a warning whenever an action results in a cache miss on your view paths. The default is false.
  • field_error_proc provides an HTML generator for displaying errors that come from Active Record. The default is{ |html_tag, instance| “”fieldWithErrors\“>#{html_tag}
” }

The ERB template handler supplies one additional option:

3.4 Configuring Action Mailer

There are a number of settings available on ActionMailer::Base:

3.5 Configuring Active Resource

There is a single configuration setting available on ActiveResource::Base:

logger accepts a logger conforming to the interface of Log4r or the default Ruby 1.8+ Logger class, which is then used to log information from Active Resource. Set to nil to disable logging.

3.6 Configuring Active Support

There are a few configuration options available in Active Support:

3.7 Configuring Active Model

Active Model currently has a single configuration setting:

4 Using Initializers

After it loads the framework plus any gems and plugins in your application, Rails turns to loading initializers. An initializer is any file of ruby code stored under /config/initializers in your application. You can use initializers to hold configuration settings that should be made after all of the frameworks and plugins are loaded.

You can use subfolders to organize your initializers if you like, because Rails will look into the whole file hierarchy from the initializers folder on down.

If you have any ordering dependency in your initializers, you can control the load order by naming. For example, 01_critical.rb will be loaded before 02_normal.rb.

5 Using an After-Initializer

After-initializers are run (as you might guess) after any initializers are loaded. You can supply an after_initialize block (or an array of such blocks) by setting up config.after_initialize in any of the Rails configuration files:

config.after_initialize do SomeClass.init end

Some parts of your application, notably observers and routing, are not yet set up at the point where the after_initialize block is called.

6 Rails Environment Settings

Some parts of Rails can also be configured externally by supplying environment variables. The following environment variables are recognized by various parts of Rails:

7 Changelog

Lighthouse ticket