diff options
Diffstat (limited to 'railties')
5 files changed, 62 insertions, 19 deletions
diff --git a/railties/guides/source/3_2_release_notes.textile b/railties/guides/source/3_2_release_notes.textile index d669a7fdfa..0f8fea2bf6 100644 --- a/railties/guides/source/3_2_release_notes.textile +++ b/railties/guides/source/3_2_release_notes.textile @@ -49,6 +49,18 @@ The <tt>mass_assignment_sanitizer</tt> config also needs to be added in <tt>conf config.active_record.mass_assignment_sanitizer = :strict </ruby> +h4. What to update in your engines + +Replace the code beneath the comment in <tt>script/rails</tt> with the following content: + +<ruby> +ENGINE_ROOT = File.expand_path('../..', __FILE__) +ENGINE_PATH = File.expand_path('../../lib/your_engine_name/engine', __FILE__) + +require 'rails/all' +require 'rails/engine/commands' +</ruby> + h3. Creating a Rails 3.2 application <shell> diff --git a/railties/guides/source/action_view_overview.textile b/railties/guides/source/action_view_overview.textile index 2c0b81121f..f007629207 100644 --- a/railties/guides/source/action_view_overview.textile +++ b/railties/guides/source/action_view_overview.textile @@ -535,10 +535,10 @@ h4. AssetTagHelper This module provides methods for generating HTML that links views to assets such as images, JavaScript files, stylesheets, and feeds. -By default, Rails links to these assets on the current host in the public folder, but you can direct Rails to link to assets from a dedicated assets server by setting +ActionController::Base.asset_host+ in the application configuration, typically in +config/environments/production.rb+. For example, let's say your asset host is +assets.example.com+: +By default, Rails links to these assets on the current host in the public folder, but you can direct Rails to link to assets from a dedicated assets server by setting +config.action_controller.asset_host+ in the application configuration, typically in +config/environments/production.rb+. For example, let's say your asset host is +assets.example.com+: <ruby> -ActionController::Base.asset_host = "assets.example.com" +config.action_controller.asset_host = "assets.example.com" image_tag("rails.png") # => <img src="http://assets.example.com/images/rails.png" alt="Rails" /> </ruby> diff --git a/railties/guides/source/asset_pipeline.textile b/railties/guides/source/asset_pipeline.textile index ff2bd08602..a061c1fc16 100644 --- a/railties/guides/source/asset_pipeline.textile +++ b/railties/guides/source/asset_pipeline.textile @@ -423,12 +423,14 @@ It is important that this folder is shared between deployments so that remotely NOTE. If you are precompiling your assets locally, you can use +bundle install --without assets+ on the server to avoid installing the assets gems (the gems in the assets group in the Gemfile). -The default matcher for compiling files includes +application.js+, +application.css+ and all non-JS/CSS files (i.e., +.coffee+ and +.scss+ files are *not* automatically included as they compile to JS/CSS): +The default matcher for compiling files includes +application.js+, +application.css+ and all non-JS/CSS files (this will include all image assets automatically): <ruby> [ Proc.new{ |path| !File.extname(path).in?(['.js', '.css']) }, /application.(css|js)$/ ] </ruby> +NOTE. The matcher (and other members of the precompile array; see below) is applied to final compiled file names. This means that anything that compiles to JS/CSS is excluded, as well as raw JS/CSS files; for example, +.coffee+ and +.scss+ files are *not* automatically included as they compile to JS/CSS. + If you have other manifests or individual stylesheets and JavaScript files to include, you can add them to the +precompile+ array: <erb> @@ -456,7 +458,7 @@ config.assets.manifest = '/path/to/some/other/location' NOTE: If there are missing precompiled files in production you will get an <tt>Sprockets::Helpers::RailsHelper::AssetPaths::AssetNotPrecompiledError</tt> exception indicating the name of the missing file(s). -h5. Server Configuration +h5. Far-future Expires header Precompiled assets exist on the filesystem and are served directly by your web server. They do not have far-future headers by default, so to get the benefit of fingerprinting you'll have to update your server configuration to add them. @@ -464,6 +466,7 @@ For Apache: <plain> <LocationMatch "^/assets/.*$"> + # Use of ETag is discouraged when Last-Modified is present Header unset ETag FileETag None # RFC says only cache for 1 year @@ -484,6 +487,8 @@ location ~ ^/assets/ { } </plain> +h5. GZip compression + When files are precompiled, Sprockets also creates a "gzipped":http://en.wikipedia.org/wiki/Gzip (.gz) version of your assets. Web servers are typically configured to use a moderate compression ratio as a compromise, but since precompilation happens once, Sprockets uses the maximum compression ratio, thus reducing the size of the data transfer to the minimum. On the other hand, web servers can be configured to serve compressed content directly from disk, rather than deflating non-compressed files themselves. Nginx is able to do this automatically enabling +gzip_static+: diff --git a/railties/guides/source/upgrading_ruby_on_rails.textile b/railties/guides/source/upgrading_ruby_on_rails.textile index 3588a67196..6e84b7fe40 100644 --- a/railties/guides/source/upgrading_ruby_on_rails.textile +++ b/railties/guides/source/upgrading_ruby_on_rails.textile @@ -4,15 +4,39 @@ This guide provides steps to be followed when you upgrade your applications to a endprologue. -h3. Rails Upgrades +h3. General Advice -When you're upgrading an existing application, it's always a great idea to have good test coverage before going in. Rails 3 and above requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been dropped officially and you should upgrade as early as possible. Rails 3.2.x will be the last branch to support 1.8.7 and Rails 4 (current edge) will support only Ruby 1.9.3. +Before attempting to upgrade an existing application, you should be sure you have a good reason to upgrade. You need to balance out several factors: the need for new features, the increasing difficulty of finding support for old code, and your available time and skills, to name a few. -TIP: Note that Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails. Ruby Enterprise Edition has these fixed since the release of 1.8.7-2010.02. On the 1.9 front, Ruby 1.9.1 is not usable because it outright segfaults, so if you want to use 1.9.x, jump on to 1.9.2 or 1.9.3 for smooth sailing. +h4(#general_testing). Test Coverage + +The best way to be sure that your application still works after upgrading is to have good test coverage before you start the process. If you don't have automated tests that exercise the bulk of your application, you'll need to spend time manually exercising all the parts that have changed. In the case of a Rails upgrade, that will mean every single piece of functionality in the application. Do yourself a favor and make sure your test coverage is good _before_ you start an upgrade. + +h4(#general_ruby). Ruby Versions + +Rails generally stays close to the latest released Ruby version when it's released: + +* Rails 3 and above requires Ruby 1.8.7 or higher. Support for all of the previous Ruby versions has been dropped officially and you should upgrade as early as possible. +* Rails 3.2.x will be the last branch to support Ruby 1.8.7. +* Rails 4 will support only Ruby 1.9.3. + +TIP: Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails. Ruby Enterprise Edition has these fixed since the release of 1.8.7-2010.02. On the 1.9 front, Ruby 1.9.1 is not usable because it outright segfaults, so if you want to use 1.9.x, jump on to 1.9.2 or 1.9.3 for smooth sailing. + +h3. Upgrading from Rails 3.2 to Rails 4.0 + +NOTE: This section is a work in progress. + +If your application is currently on any version of Rails older than 3.2.x, you should upgrade to Rails 3.2 before attempting an update to Rails 4.0. + +The following changes are meant for upgrading your application to Rails 4.0. + +h4(#plugins4_0). vendor/plugins + +Rails 4.0 no longer supports loading plugins from <tt>vendor/plugins</tt>. You must replace any plugins by extracting them to gems and adding them to your Gemfile. If you choose not to make them gems, you can move them into, say, <tt>lib/my_plugin/*</tt> and add an appropriate initializer in <tt>config/initializers/my_plugin.rb</tt>. h3. Upgrading from Rails 3.1 to Rails 3.2 -We recommend that you first upgrade to Rails 3.1 in case you haven't and make sure your application still runs as expected before attempting an update to Rails 3.2. +If your application is currently on any version of Rails older than 3.1.x, you should upgrade to Rails 3.1 before attempting an update to Rails 3.2. The following changes are meant for upgrading your application to Rails 3.2.1, the latest 3.2.x version of Rails. @@ -32,7 +56,7 @@ end h4(#config_dev3_2). config/environments/development.rb -* There are a couple of new configuration changes you'd want to add: +There are a couple of new configuration settings that you should add to your development environment: <ruby> # Raise exception on mass assignment protection for Active Record models @@ -45,7 +69,7 @@ config.active_record.auto_explain_threshold_in_seconds = 0.5 h4(#config_test3_2). config/environments/test.rb -The <tt>mass_assignment_sanitizer</tt> config also needs to be added in <tt>config/environments/test.rb</tt>: +The <tt>mass_assignment_sanitizer</tt> configuration setting should also be be added to <tt>config/environments/test.rb</tt>: <ruby> # Raise exception on mass assignment protection for Active Record models @@ -54,11 +78,11 @@ config.active_record.mass_assignment_sanitizer = :strict h4(#plugins3_2). vendor/plugins -* Rails 3.2 deprecates <tt>vendor/plugins</tt> and Rails 4.0 will remove them completely. You can start replacing these plugins by extracting them as gems and adding them in your Gemfile. If you choose not to make them gems, you can move them into, say, <tt>lib/my_plugin/*</tt> and add an appropriate initializer in <tt>config/initializers/my_plugin.rb</tt>. +Rails 3.2 deprecates <tt>vendor/plugins</tt> and Rails 4.0 will remove them completely. While it's not strictly necessary as part of a Rails 3.2 upgrade, you can start replacing any plugins by extracting them to gems and adding them to your Gemfile. If you choose not to make them gems, you can move them into, say, <tt>lib/my_plugin/*</tt> and add an appropriate initializer in <tt>config/initializers/my_plugin.rb</tt>. h3. Upgrading from Rails 3.0 to Rails 3.1 -We recommend that you first upgrade to Rails 3.0 in case you haven't and make sure your application still runs as expected before attempting an update to Rails 3.1. +If your application is currently on any version of Rails older than 3.0.x, you should upgrade to Rails 3.0 before attempting an update to Rails 3.1. The following changes are meant for upgrading your application to Rails 3.1.3, the latest 3.1.x version of Rails. @@ -83,14 +107,14 @@ gem 'jquery-rails' h4(#config_app3_1). config/application.rb -* The asset pipeline requires the following additions: +The asset pipeline requires the following additions: <ruby> config.assets.enabled = true config.assets.version = '1.0' </ruby> -* If your application is using the "/assets" route for a resource you may want change the prefix used for assets to avoid conflicts: +If your application is using an "/assets" route for a resource you may want change the prefix used for assets to avoid conflicts: <ruby> # Defaults to '/assets' @@ -99,9 +123,9 @@ config.assets.prefix = '/asset-files' h4(#config_dev3_1). config/environments/development.rb -* Remove the RJS setting <tt>config.action_view.debug_rjs = true</tt>. +Remove the RJS setting <tt>config.action_view.debug_rjs = true</tt>. -* Add the following, if you enable the asset pipeline. +Add these settings if you enable the asset pipeline: <ruby> # Do not compress assets @@ -113,7 +137,7 @@ config.assets.debug = true h4(#config_prod3_1). config/environments/production.rb -* Again, most of the changes below are for the asset pipeline. You can read more about these in the "Asset Pipeline":asset_pipeline.html guide. +Again, most of the changes below are for the asset pipeline. You can read more about these in the "Asset Pipeline":asset_pipeline.html guide. <ruby> # Compress JavaScripts and CSS @@ -137,6 +161,8 @@ config.assets.digest = true h4(#config_test3_1). config/environments/test.rb +You can help test performance with these additions to your test environment: + <ruby> # Configure static asset server for tests with Cache-Control for performance config.serve_static_assets = true @@ -145,7 +171,7 @@ config.static_cache_control = "public, max-age=3600" h4(#config_wp3_1). config/initializers/wrap_parameters.rb -* Add this file with the following contents, if you wish to wrap parameters into a nested hash. This is on by default in new applications. +Add this file with the following contents, if you wish to wrap parameters into a nested hash. This is on by default in new applications. <ruby> # Be sure to restart your server when you modify this file. diff --git a/railties/lib/rails/application/route_inspector.rb b/railties/lib/rails/application/route_inspector.rb index 2ca0c68243..1e5ce67a58 100644 --- a/railties/lib/rails/application/route_inspector.rb +++ b/railties/lib/rails/application/route_inspector.rb @@ -64,7 +64,7 @@ module Rails # executes `rake routes`. People should not use this class. class RouteInspector # :nodoc: def initialize - @engines = ActiveSupport::OrderedHash.new + @engines = Hash.new end def format all_routes, filter = nil |