Fix documentation of new controller filters api [ci skip]

The api for filters with classes change and the guides weren't updated.
Now the class must respond for methods with the same name as the filter,
so the `before_action` calls a `before` method, and so on.

The method `#filter` has been deprecated in 4.0.0 and has been removed
in 4.1.0: #7560

2 files changed, 5 insertions, 2 deletions

diff --git a/guides/source/4_1_release_notes.md b/guides/source/4_1_release_notes.md
index 477268f4bc..7399bfb5de 100644
--- a/guides/source/4_1_release_notes.md
+++ b/guides/source/4_1_release_notes.md
@@ -567,6 +567,9 @@ for detailed changes.
 * Removed deprecated `assert_present` and `assert_blank` methods, use `assert
   object.blank?` and `assert object.present?` instead.
 
+* Remove deprecated `#filter` method for filter objects, use the corresponding
+  method instead (e.g. `#before` for a before filter).
+
 ### Deprecations
 
 * Deprecated `Numeric#{ago,until,since,from_now}`, the user is expected to
diff --git a/guides/source/action_controller_overview.md b/guides/source/action_controller_overview.md
index 0234120b45..6c82375ea1 100644
--- a/guides/source/action_controller_overview.md
+++ b/guides/source/action_controller_overview.md
@@ -709,7 +709,7 @@ class ApplicationController < ActionController::Base
 end
 
 class LoginFilter
-  def self.filter(controller)
+  def self.before(controller)
     unless controller.send(:logged_in?)
       controller.flash[:error] = "You must be logged in to access this section"
       controller.redirect_to controller.new_login_url
@@ -718,7 +718,7 @@ class LoginFilter
 end
 ```
 
-Again, this is not an ideal example for this filter, because it's not run in the scope of the controller but gets the controller passed as an argument. The filter class has a class method `filter` which gets run before or after the action, depending on if it's a before or after filter. Classes used as around filters can also use the same `filter` method, which will get run in the same way. The method must `yield` to execute the action. Alternatively, it can have both a `before` and an `after` method that are run before and after the action.
+Again, this is not an ideal example for this filter, because it's not run in the scope of the controller but gets the controller passed as an argument. The filter class must implement a method with the same name as the filter, so for the `before_action` filter the class must implement a `before` method, and so on. The `around` method must `yield` to execute the action.
 
 Request Forgery Protection
 --------------------------