update guides to use _action callbacks [ci skip]

guides/source/action_controller_overview.md

@@ -434,7 +434,7 @@ Filters are inherited, so if you set a filter on `ApplicationController`, it wil
 
 ```ruby
 class ApplicationController < ActionController::Base
-  before_filter :require_login
+  before_action :require_login
 
   private
 
@@ -458,11 +458,11 @@ end
 
 The method simply stores an error message in the flash and redirects to the login form if the user is not logged in. If a "before" filter renders or redirects, the action will not run. If there are additional filters scheduled to run after that filter, they are also cancelled.
 
-In this example the filter is added to `ApplicationController` and thus all controllers in the application inherit it. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with `skip_before_filter`:
+In this example the filter is added to `ApplicationController` and thus all controllers in the application inherit it. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with `skip_before_action`:
 
 ```ruby
 class LoginsController < ApplicationController
-  skip_before_filter :require_login, only: [:new, :create]
+  skip_before_action :require_login, only: [:new, :create]
 end
 ```
 
@@ -480,7 +480,7 @@ For example, in a website where changes have an approval workflow an administrat
 
 ```ruby
 class ChangesController < ActionController::Base
-  around_filter :wrap_in_transaction, only: :show
+  around_action :wrap_in_transaction, only: :show
 
   private
 
@@ -502,13 +502,13 @@ You can choose not to yield and build the response yourself, in which case the a
 
 ### Other Ways to Use Filters
 
-While the most common way to use filters is by creating private methods and using *_filter to add them, there are two other ways to do the same thing.
+While the most common way to use filters is by creating private methods and using *_action to add them, there are two other ways to do the same thing.
 
-The first is to use a block directly with the *_filter methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritten to use a block:
+The first is to use a block directly with the *_action methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritten to use a block:
 
 ```ruby
 class ApplicationController < ActionController::Base
-  before_filter do |controller|
+  before_action do |controller|
     redirect_to new_login_url unless controller.send(:logged_in?)
   end
 end
@@ -520,7 +520,7 @@ The second way is to use a class (actually, any object that responds to the righ
 
 ```ruby
 class ApplicationController < ActionController::Base
-  before_filter LoginFilter
+  before_action LoginFilter
 end
 
 class LoginFilter
@@ -648,7 +648,7 @@ HTTP digest authentication is superior to the basic authentication as it does no
 class AdminController < ApplicationController
   USERS = { "lifo" => "world" }
 
-  before_filter :authenticate
+  before_action :authenticate
 
   private
 
@@ -828,7 +828,7 @@ end
 
 class ClientsController < ApplicationController
   # Check that the user has the right authorization to access clients.
-  before_filter :check_authorization
+  before_action :check_authorization
 
   # Note how the actions don't have to worry about all the auth stuff.
   def edit

guides/source/action_mailer_basics.md

@@ -447,17 +447,17 @@ end
 Action Mailer Callbacks
 ---------------------------
 
-Action Mailer allows for you to specify a `before_filter`, `after_filter` and 'around_filter'.
+Action Mailer allows for you to specify a `before_action`, `after_action` and 'around_action'.
 
 * Filters can be specified with a block or a symbol to a method in the mailer class similar to controllers.
 
-* You could use a `before_filter` to prepopulate the mail object with defaults, delivery_method_options or insert default headers and attachments.
+* You could use a `before_action` to prepopulate the mail object with defaults, delivery_method_options or insert default headers and attachments.
 
-* You could use an `after_filter` to do similar setup as a `before_filter` but using instance variables set in your mailer action.
+* You could use an `after_action` to do similar setup as a `before_action` but using instance variables set in your mailer action.
 
 ```ruby
 class UserMailer < ActionMailer::Base
-  after_filter :set_delivery_options, :prevent_delivery_to_guests, :set_business_headers
+  after_action :set_delivery_options, :prevent_delivery_to_guests, :set_business_headers
 
   def feedback_message(business, user)
     @business = business

guides/source/action_view_overview.md

@@ -1486,7 +1486,7 @@ You can use the same technique to localize the rescue files in your public direc
 Since Rails doesn't restrict the symbols that you use to set I18n.locale, you can leverage this system to display different content depending on anything you like. For example, suppose you have some "expert" users that should see different pages from "normal" users. You could add the following to `app/controllers/application.rb`:
 
 ```ruby
-before_filter :set_expert_locale
+before_action :set_expert_locale
 
 def set_expert_locale
   I18n.locale = :expert if current_user.expert?

guides/source/caching_with_rails.md

@@ -104,7 +104,7 @@ Let's say you only wanted authenticated users to call actions on `ProductsContro
 ```ruby
 class ProductsController < ActionController
 
-  before_filter :authenticate
+  before_action :authenticate
   caches_action :index
 
   def index

guides/source/i18n.md

@@ -134,10 +134,10 @@ However, you would probably like to **provide support for more locales** in your
 
 WARNING: You may be tempted to store the chosen locale in a _session_ or a <em>cookie</em>, however **do not do this**. The locale should be transparent and a part of the URL. This way you won't break people's basic assumptions about the web itself: if you send a URL to a friend, they should see the same page and content as you. A fancy word for this would be that you're being [<em>RESTful</em>](http://en.wikipedia.org/wiki/Representational_State_Transfer. Read more about the RESTful approach in [Stefan Tilkov's articles](http://www.infoq.com/articles/rest-introduction). Sometimes there are exceptions to this rule and those are discussed below.
 
-The _setting part_ is easy. You can set the locale in a `before_filter` in the `ApplicationController` like this:
+The _setting part_ is easy. You can set the locale in a `before_action` in the `ApplicationController` like this:
 
 ```ruby
-before_filter :set_locale
+before_action :set_locale
 
 def set_locale
   I18n.locale = params[:locale] || I18n.default_locale
@@ -160,7 +160,7 @@ One option you have is to set the locale from the domain name where your applica
 You can implement it like this in your `ApplicationController`:
 
 ```ruby
-before_filter :set_locale
+before_action :set_locale
 
 def set_locale
   I18n.locale = extract_locale_from_tld || I18n.default_locale
@@ -203,7 +203,7 @@ This solution has aforementioned advantages, however, you may not be able or may
 
 ### Setting the Locale from the URL Params
 
-The most usual way of setting (and passing) the locale would be to include it in URL params, as we did in the `I18n.locale = params[:locale]` _before_filter_ in the first example. We would like to have URLs like `www.example.com/books?locale=ja` or `www.example.com/ja/books` in this case.
+The most usual way of setting (and passing) the locale would be to include it in URL params, as we did in the `I18n.locale = params[:locale]` _before_action_ in the first example. We would like to have URLs like `www.example.com/books?locale=ja` or `www.example.com/ja/books` in this case.
 
 This approach has almost the same set of advantages as setting the locale from the domain name: namely that it's RESTful and in accord with the rest of the World Wide Web. It does require a little bit more work to implement, though.
 

guides/source/security.md

@@ -688,7 +688,7 @@ NOTE: _When sanitizing, protecting or verifying something, whitelists over black
 
 A blacklist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a whitelist which lists the good e-mail addresses, public actions, good HTML tags and so on. Although sometimes it is not possible to create a whitelist (in a SPAM filter, for example), _prefer to use whitelist approaches_:
 
-* Use before_filter only: [...] instead of except: [...]. This way you don't forget to turn it off for newly added actions.
+* Use before_action only: [...] instead of except: [...]. This way you don't forget to turn it off for newly added actions.
 * Use attr_accessible instead of attr_protected. See the mass-assignment section for details
 * Allow <strong> instead of removing <script> against Cross-Site Scripting (XSS). See below for details.
 * Don't try to correct user input by blacklists: