Moved all filter classes to namespace yii\filters

docs/guide/authorization.md

@@ -7,7 +7,7 @@ of controlling it.
 Access control basics
 ---------------------
 
-Basic access control is very simple to implement using [[yii\web\AccessControl]]:
+Basic access control is very simple to implement using [[yii\filters\AccessControl]]:
 
 ```php
 class SiteController extends Controller
@@ -16,7 +16,7 @@ class SiteController extends Controller
     {
         return [
             'access' => [
-                'class' => \yii\web\AccessControl::className(),
+                'class' => \yii\filters\AccessControl::className(),
                 'only' => ['login', 'logout', 'signup'],
                 'rules' => [
                     [
@@ -38,7 +38,7 @@ class SiteController extends Controller
 
 In the code above we're attaching access control behavior to a controller. Since there's `only` option specified, it
 will be applied to 'login', 'logout' and 'signup' actions only. A set of rules that are basically options for
-[[yii\web\AccessRule]] reads as follows:
+[[yii\filters\AccessRule]] reads as follows:
 
 - Allow all guest (not yet authenticated) users to access 'login' and 'signup' actions.
 - Allow authenticated users to access 'logout' action.
@@ -46,7 +46,7 @@ will be applied to 'login', 'logout' and 'signup' actions only. A set of rules t
 Rules are checked one by one from top to bottom. If rule matches, action takes place immediately. If not, next rule is
 checked. If no rules matched access is denied.
 
-[[yii\web\AccessRule]] is quite flexible and allows additionally to what was demonstrated checking IPs and request method
+[[yii\filters\AccessRule]] is quite flexible and allows additionally to what was demonstrated checking IPs and request method
 (i.e. POST, GET). If it's not enough you can specify your own check via anonymous function:
 
 ```php
@@ -56,7 +56,7 @@ class SiteController extends Controller
     {
         return [
             'access' => [
-                'class' => \yii\web\AccessControl::className(),
+                'class' => \yii\filters\AccessControl::className(),
                 'only' => ['special-callback'],
                 'rules' => [
                     [
@@ -219,7 +219,7 @@ public function behaviors()
 {
     return [
         'access' => [
-            'class' => 'yii\web\AccessControl',
+            'class' => 'yii\filters\AccessControl',
             'except' => ['something'],
             'rules' => [
                 [

docs/guide/controller.md

@@ -199,7 +199,7 @@ public function behaviors()
 {
     return [
         'httpCache' => [
-            'class' => \yii\web\HttpCache::className(),
+            'class' => \yii\filters\HttpCache::className(),
             'only' => ['index'],
             'lastModified' => function ($action, $params) {
                 $q = new \yii\db\Query();
@@ -225,8 +225,8 @@ The return value of [[yii\base\ActionFilter::beforeAction()|beforeAction()]] det
 an action should be executed or not. If `beforeAction()` of a filter returns false, the filters after this one
 will be skipped and the action will not be executed.
 
-The [authorization](authorization.md) section of this guide shows how to use the [[yii\web\AccessControl]] filter,
-and the [caching](caching.md) section gives more details about the [[yii\web\PageCache]] and [[yii\web\HttpCache]] filters.
+The [authorization](authorization.md) section of this guide shows how to use the [[yii\filters\AccessControl]] filter,
+and the [caching](caching.md) section gives more details about the [[yii\filters\PageCache]] and [[yii\filters\HttpCache]] filters.
 These built-in filters are also good references when you learn to create your own filters.
 
 

docs/guide/performance.md

@@ -137,7 +137,7 @@ sending either `ETag` or `Last-Modified` header in your application response. If
 HTTP specification (most browsers are), content will be fetched only if it is different from what it was prevously.
 
 Forming proper headers is time consuming task so Yii provides a shortcut in form of controller filter
-[[yii\web\HttpCache]]. Using it is very easy. In a controller you need to implement `behaviors` method like
+[[yii\filters\HttpCache]]. Using it is very easy. In a controller you need to implement `behaviors` method like
 the following:
 
 ```php
@@ -145,7 +145,7 @@ public function behaviors()
 {
     return [
         'httpCache' => [
-            'class' => \yii\web\HttpCache::className(),
+            'class' => \yii\filters\HttpCache::className(),
             'only' => ['list'],
             'lastModified' => function ($action, $params) {
                 $q = new Query();

docs/guide/rest.md

@@ -13,7 +13,7 @@ In particular, Yii provides support for the following aspects regarding RESTful
 * Authentication;
 * Authorization;
 * Support for HATEOAS;
-* Caching via `yii\web\HttpCache`;
+* Caching via `yii\filters\HttpCache`;
 * Rate limiting;
 * Searching and filtering: TBD
 * Testing: TBD
@@ -783,7 +783,7 @@ Accept: application/vnd.company.myapp-v1+json
 ```
 
 Both methods have pros and cons, and there are a lot of debates about them. Below we describe a practical strategy
-of API versioning that is a kind of mix of these two methods:
+of API versioning that is kind of a mix of these two methods:
 
 * Put each major version of API implementation in a separate module whose ID is the major version number (e.g. `v1`, `v2`).
   Naturally, the API URLs will contain major version numbers.
@@ -793,7 +793,9 @@ of API versioning that is a kind of mix of these two methods:
 For each module serving a major version, it should include the resource classes and the controller classes
 serving for that specific version. To better separate code responsibility, you may keep a common set of
 base resource and controller classes, and subclass them in each individual version module. Within the subclasses,
-implement the concrete code such as `Model::fields()`. As a result, your code may be organized like the following:
+implement the concrete code such as `Model::fields()`.
+
+Your code may be organized like the following:
 
 ```
 api/

docs/guide/upgrade-from-v1.md

@@ -318,7 +318,7 @@ Action Filters
 
 Action filters are implemented via behaviors now. You should extend from [[yii\base\ActionFilter]] to
 define a new filter. To use a filter, you should attach the filter class to the controller
-as a behavior. For example, to use the [[yii\web\AccessControl]] filter, you should have the following
+as a behavior. For example, to use the [[yii\filters\AccessControl]] filter, you should have the following
 code in a controller:
 
 ```php
@@ -326,7 +326,7 @@ public function behaviors()
 {
     return [
         'access' => [
-            'class' => 'yii\web\AccessControl',
+            'class' => 'yii\filters\AccessControl',
             'rules' => [
                 ['allow' => true, 'actions' => ['admin'], 'roles' => ['@']],
             ],

docs/guide/url.md

@@ -232,7 +232,7 @@ return [
 ### Handling REST requests
 
 TBD:
-- RESTful routing: [[yii\web\VerbFilter]], [[yii\web\UrlManager::$rules]]
+- RESTful routing: [[yii\filters\VerbFilter]], [[yii\filters\UrlManager::$rules]]
 - Json API:
   - response: [[yii\web\Response::format]]
   - request: [[yii\web\Request::$parsers]], [[yii\web\JsonParser]]