8 files changed, 102 insertions, 25 deletions
diff --git a/guides/source/active_record_querying.md b/guides/source/active_record_querying.md
index 69070eea21..84fc254207 100644
--- a/guides/source/active_record_querying.md
+++ b/guides/source/active_record_querying.md
@@ -1202,6 +1202,7 @@ class User < ActiveRecord::Base
   scope :active, -> { where state: 'active' }
   scope :inactive, -> { where state: 'inactive' }
 end
+```
 
 ```ruby
 User.active.inactive
diff --git a/guides/source/active_record_validations.md b/guides/source/active_record_validations.md
index 12be7c1dec..37790c62b1 100644
--- a/guides/source/active_record_validations.md
+++ b/guides/source/active_record_validations.md
@@ -357,7 +357,7 @@ given regular expression, which is specified using the `:with` option.
 ```ruby
 class Product < ActiveRecord::Base
   validates :legacy_code, format: { with: /\A[a-zA-Z]+\z/,
-    message: "Only letters allowed" }
+    message: "only allows letters" }
 end
 ```
 
diff --git a/guides/source/asset_pipeline.md b/guides/source/asset_pipeline.md
index b86c7bfc4e..3b3707d9e5 100644
--- a/guides/source/asset_pipeline.md
+++ b/guides/source/asset_pipeline.md
@@ -815,18 +815,16 @@ end
 If you use the `assets` group with Bundler, please make sure that your `config/application.rb` has the following Bundler require statement:
 
 ```ruby
-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
+# 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)
 ```
 
-Instead of the old Rails 3.0 version:
+Instead of the generated version:
 
 ```ruby
-# If you have a Gemfile, require the gems listed there, including any gems
+# Require the gems listed in Gemfile, including any gems
 # you've limited to :test, :development, or :production.
-Bundler.require(:default, Rails.env) if defined?(Bundler)
+Bundler.require(:default, Rails.env)
 ```
diff --git a/guides/source/contributing_to_ruby_on_rails.md b/guides/source/contributing_to_ruby_on_rails.md
index 0be9bb1ced..0bfa646b81 100644
--- a/guides/source/contributing_to_ruby_on_rails.md
+++ b/guides/source/contributing_to_ruby_on_rails.md
@@ -182,9 +182,9 @@ Contributing to the Rails Documentation
 
 Ruby on Rails has two main sets of documentation: the guides help you in learning about Ruby on Rails, and the API is a reference.
 
-You can help improve the Rails guides by making them more coherent, consistent or readable, adding missing information, correcting factual errors, fixing typos, or bringing it up to date with the latest edge Rails. To get involved in the translation of Rails guides, please see [Translating Rails Guides](https://wiki.github.com/lifo/docrails/translating-rails-guides).
+You can help improve the Rails guides by making them more coherent, consistent or readable, adding missing information, correcting factual errors, fixing typos, or bringing it up to date with the latest edge Rails. To get involved in the translation of Rails guides, please see [Translating Rails Guides](https://wiki.github.com/rails/docrails/translating-rails-guides).
 
-If you're confident about your changes, you can push them directly yourself via [docrails](https://github.com/lifo/docrails). Docrails is a branch with an **open commit policy** and public write access. Commits to docrails are still reviewed, but this happens after they are pushed. Docrails is merged with master regularly, so you are effectively editing the Ruby on Rails documentation.
+If you're confident about your changes, you can push them directly yourself via [docrails](https://github.com/rails/docrails). Docrails is a branch with an **open commit policy** and public write access. Commits to docrails are still reviewed, but this happens after they are pushed. Docrails is merged with master regularly, so you are effectively editing the Ruby on Rails documentation.
 
 If you are unsure of the documentation changes, you can create an issue in the [Rails](https://github.com/rails/rails/issues) issues tracker on GitHub.
 
diff --git a/guides/source/engines.md b/guides/source/engines.md
index 663e59b5c3..bc66ed256e 100644
--- a/guides/source/engines.md
+++ b/guides/source/engines.md
@@ -719,6 +719,32 @@ Engine model and controller classes can be extended by open classing them in the
 
 For simple class modifications use `Class#class_eval`, and for complex class modifications, consider using `ActiveSupport::Concern`.
 
+#### A note on Decorators and loading code
+
+Because these decorators are not referenced by your Rails application itself,
+Rails' autoloading system will not kick in and load your decorators. This
+means that you need to require them yourself.
+
+Here is some sample code to do this:
+
+```ruby
+# lib/blorgh/engine.rb
+module Blorgh
+  class Engine < ::Rails::Engine
+    isolate_namespace Blorgh
+
+    config.to_prepare do
+      Dir.glob(Rails.root + "app/decorators/**/*_decorator*.rb").each do |c|
+        require_dependency(c)
+      end
+    end
+  end
+end
+```
+
+This doesn't apply to just Decorators, but anything that you add in an engine
+that isn't referenced by your main application.
+
 #### Implementing Decorator Pattern Using Class#class_eval
 
 **Adding** `Post#time_since_created`,
diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md
index beb51c7161..2fb0cd7c72 100644
--- a/guides/source/getting_started.md
+++ b/guides/source/getting_started.md
@@ -64,7 +64,7 @@ Creating a New Rails Project
 The best way to use this guide is to follow each step as it happens, no code or
 step needed to make this example application has been left out, so you can
 literally follow along step by step. You can get the complete code
-[here](https://github.com/lifo/docrails/tree/master/guides/code/getting_started).
+[here](https://github.com/rails/docrails/tree/master/guides/code/getting_started).
 
 By following along with this guide, you'll create a Rails project called
 `blog`, a
@@ -531,21 +531,28 @@ and change the `create` action to look like this:
 
 ```ruby
 def create
-  @post = Post.new(params[:post])
-
+  @post = Post.new(post_params)
+ 
   @post.save
   redirect_to @post
 end
+
+private
+  def post_params
+    params.require(:post).permit(:title, :text)
+  end
 ```
 
 Here's what's going on: every Rails model can be initialized with its
 respective attributes, which are automatically mapped to the respective
 database columns. In the first line we do just that (remember that
-`params[:post]` contains the attributes we're interested in). Then,
+`post_params` contains the attributes we're interested in). Then,
 `@post.save` is responsible for saving the model in the database.
 Finally, we redirect the user to the `show` action,
 which we'll define later.
 
+TIP: Note that `def post_params` is private. This new approach prevents an attacker from setting the model's attributes by manipulating the hash passed to the model. For more information, refer to [this blog post about Strong Parameters](http://weblog.rubyonrails.org/2012/3/21/strong-parameters/).
+
 TIP: As we'll see later, `@post.save` returns a boolean indicating
 whether the model was saved or not.
 
diff --git a/guides/source/layout.html.erb b/guides/source/layout.html.erb
index 397dd62638..ef2bdf0753 100644
--- a/guides/source/layout.html.erb
+++ b/guides/source/layout.html.erb
@@ -102,10 +102,10 @@
         </p>
         <p>
           If you see any typos or factual errors you are confident to
-          patch, please clone <%= link_to 'docrails', 'https://github.com/lifo/docrails' %>
+          patch, please clone <%= link_to 'docrails', 'https://github.com/rails/docrails' %>
           and push the change yourself. That branch of Rails has public write access.
           Commits are still reviewed, but that happens after you've submitted your
-          contribution. <%= link_to 'docrails', 'https://github.com/lifo/docrails' %> is
+          contribution. <%= link_to 'docrails', 'https://github.com/rails/docrails' %> is
           cross-merged with master periodically.
         </p>
         <p>
diff --git a/guides/source/upgrading_ruby_on_rails.md b/guides/source/upgrading_ruby_on_rails.md
index 3d9c2b8318..35a9617b80 100644
--- a/guides/source/upgrading_ruby_on_rails.md
+++ b/guides/source/upgrading_ruby_on_rails.md
@@ -24,29 +24,74 @@ TIP: Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails. Ruby Enterp
 
 ### HTTP PATCH
 
-Rails 4 now uses `PATCH` as the primary HTTP verb for updates. When a resource
-is declared in `config/routes.rb`:
+Rails 4 now uses `PATCH` as the primary HTTP verb for updates when a RESTful
+resource is declared in `config/routes.rb`. The `update` action is still used,
+and `PUT` requests will continue to be routed to the `update` action as well.
+So, if you're using only the standard RESTful routes, no changes need to be made:
 
 ```ruby
 resources :users
 ```
 
-the action in `UsersController` to update a user is still `update`.
+```erb
+<%= form_for @user do |f| %>
+```
+
+```ruby
+class UsersController < ApplicationController
+  def update
+    # No change needed; PATCH will be preferred, and PUT will still work.
+  end
+end
+```
+
+However, you will need to make a change if you are using `form_for` to update
+a resource in conjunction with a custom route using the `PUT` HTTP method:
+
+```ruby
+resources :users, do
+  put :update_name, on: :member
+end
+```
+
+```erb
+<%= form_for [ :update_name, @user ] do |f| %>
+```
+
+```ruby
+class UsersController < ApplicationController
+  def update_name
+    # Change needed; form_for will try to use a non-existant PATCH route.
+  end
+end
+```
+
+If the action is not being used in a public API and you are free to change the
+HTTP method, you can update your route to use `patch` instead of `put`:
 
 `PUT` requests to `/users/:id` in Rails 4 get routed to `update` as they are
 today. So, if you have an API that gets real PUT requests it is going to work.
 The router also routes `PATCH` requests to `/users/:id` to the `update` action.
 
-So, in Rails 4 both `PUT` and `PATCH` are routed to update. We recommend
-switching to `PATCH` as part of your upgrade process if possible, as it's more
-likely what you want.
+```ruby
+resources :users do
+  patch :update_name, on: :member
+end
+```
+
+If the action is being used in a public API and you can't change to HTTP method
+being used, you can update your form to use the `PUT` method instead:
+
+```erb
+<%= form_for [ :update_name, @user ], method: :put do |f| %>
+```
 
 For more on PATCH and why this change was made, see [this post](http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/)
 on the Rails blog.
 
 #### A note about media types
 
-The erratta for the `PATCH` verb [specifies that a 'diff' media type should be
+The errata for the `PATCH` verb [specifies that a 'diff' media type should be
 used with `PATCH`](http://www.rfc-editor.org/errata_search.php?rfc=5789). One
 such format is [JSON Patch](http://tools.ietf.org/html/rfc6902). While Rails
 does not support JSON Patch natively, it's easy enough to add support: