GitHub Access Token became invalid

It seems like the GitHub access token used for retrieving details about this repository from GitHub became invalid. This might prevent certain types of inspections from being run (in particular, everything related to pull requests).
Please ask an admin of your repository to re-new the access token on this website.
Test Setup Failed
Push — action_getCatTree_order ( 77944b )
by
unknown
23:56
created

ManageController   F

Complexity

Total Complexity 86

Size/Duplication

Total Lines 687
Duplicated Lines 29.69 %

Coupling/Cohesion

Components 1
Dependencies 20

Importance

Changes 1
Bugs 1 Features 0
Metric Value
wmc 86
lcom 1
cbo 20
dl 204
loc 687
rs 1.3042
c 1
b 1
f 0

26 Methods

Rating   Name   Duplication   Size   Complexity  
A actionIndex() 0 4 1
A actionFlushMetaCache() 0 4 1
A actionFlushCounterCache() 0 4 1
A actionGenerateRedirectFile() 0 4 1
A actionDeleteRedirectFile() 0 4 1
B behaviors() 0 34 1
A actionGetRobots() 0 9 1
A actionMeta() 12 12 1
C actionUpdateMeta() 48 48 7
B actionCreateMeta() 0 36 5
A actionDeleteMeta() 0 5 1
A actionDeleteMetas() 0 13 2
A actionCounter() 0 13 1
C actionUpdateCounter() 49 49 7
B actionCreateCounter() 0 26 5
A actionDeleteCounter() 0 5 1
A actionDeleteCounters() 0 13 2
B actionRobots() 0 16 5
A actionRedirect() 12 12 1
B actionCreateRedirect() 0 36 5
C actionCreateRedirects() 36 70 12
C actionUpdateRedirect() 47 47 7
A actionDeleteRedirect() 0 5 1
A actionDeleteRedirects() 0 13 2
B actionEcommerce() 0 32 6
C renderEcommerceCounters() 0 40 8

How to fix   Duplicated Code    Complexity   

Duplicated Code

Duplicate code is one of the most pungent code smells. A rule that is often used is to re-structure code once it is duplicated in three or more places.

Common duplication problems, and corresponding solutions are:

Complex Class

 Tip:   Before tackling complexity, make sure that you eliminate any duplication first. This often can reduce the size of classes significantly.

Complex classes like ManageController often do a lot of different things. To break such a class down, we need to identify a cohesive component within that class. A common approach to find such a component is to look for fields/methods that share the same prefixes, or suffixes. You can also have a look at the cohesion graph to spot any un-connected, or weakly-connected components.

Once you have determined the fields that belong together, you can apply the Extract Class refactoring. If the component makes sense as a sub-class, Extract Subclass is also a candidate, and is often faster.

While breaking up the class, it is a good idea to analyze how other classes use ManageController, and based on these observations, apply Extract Interface, too.

1
<?php
2
3
namespace app\modules\seo\controllers;
4
5
use app\backend\components\BackendController;
6
use app\modules\shop\models\Category;
7
use app\modules\shop\models\OrderTransaction;
8
use app\modules\shop\models\Product;
9
use app\modules\seo\models\Config;
10
use app\modules\seo\models\Counter;
11
use app\modules\seo\models\Meta;
12
use app\modules\seo\models\Redirect;
13
use app\modules\seo\models\Robots;
14
use devgroup\ace\AceHelper;
15
use devgroup\TagDependencyHelper\ActiveRecordHelper;
16
use yii\base\Event;
17
use yii\filters\AccessControl;
18
use yii\helpers\Json;
19
use yii\web\NotFoundHttpException;
20
use yii\helpers\Url;
21
use Yii;
22
23
class ManageController extends BackendController
24
{
25
    public function behaviors()
26
    {
27
        return [
28
            'access' => [
29
                'class' => AccessControl::className(),
30
                'rules' => [
31
                    [
32
                        'allow' => true,
33
                        'actions' => ['get-robots'],
34
                        'roles' => ['?']
35
                    ],
36
                    [
37
                        'allow' => true,
38
                        'actions' => ['flush-meta-cache', 'flush-counter-cache', 'flush-robots-cache'],
39
                        'roles' => ['cache manage'],
40
                    ],
41
                    [
42
                        'allow' => false,
43
                        'actions' => ['flush-meta-cache', 'flush-counter-cache', 'flush-robots-cache'],
44
                    ],
45
                    [
46
                        'allow' => true,
47
                        'roles' => ['seo manage'],
48
                    ],
49
                ],
50
            ],
51
            [
52
              'class' => 'yii\filters\PageCache',
53
              'only' => ['GetRobots'],
54
              'duration' => 24 * 60 * 60,
55
              'dependency' => ActiveRecordHelper::getCommonTag(Config::className()),
56
            ]
57
        ];
58
    }
59
60
    /**
61
     * Index page
62
     * @return string
63
     */
64
    public function actionIndex()
65
    {
66
        return $this->render('index');
67
    }
68
69
    /**
70
     * return robots.txt
71
     */
72
    public function actionGetRobots()
73
    {
74
        $robots = Robots::getRobots();
75
        $response = \Yii::$app->response;
76
        $response->headers->set('Content-Type', 'text/plain');
77
        $response->format = \yii\web\Response::FORMAT_RAW;
78
        $response->data = $robots;
79
        \Yii::$app->end();
80
    }
81
82
    /**
83
     * Show list of Meta tag models
84
     * @return string
85
     */
86 View Code Duplication
    public function actionMeta()
0 ignored issues
show
Coding Style introduced by
actionMeta uses the super-global variable $_GET which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
87
    {
88
        $searchModel = new Meta();
89
        $dataProvider = $searchModel->search($_GET);
90
        return $this->render(
91
            'meta',
92
            [
93
                'dataProvider' => $dataProvider,
94
                'searchModel' => $searchModel,
95
            ]
96
        );
97
    }
98
99
    /**
100
     * Updates an existing Meta model.
101
     * If update is successful, the browser will be redirected to the 'meta' page.
102
     * @param $id
103
     * @return string
104
     * @throws \yii\web\NotFoundHttpException
105
     */
106 View Code Duplication
    public function actionUpdateMeta($id)
0 ignored issues
show
Coding Style introduced by
actionUpdateMeta uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
107
    {
108
        /* @var $model Meta */
109
        $model = Meta::find()->where(
110
            [
111
                'key' => $id,
112
            ]
113
        )->one();
114
        if ($model !== null) {
115
            if ($model->load($_POST) && $model->validate()) {
116
                if ($model->save()) {
117
                    Yii::$app->session->setFlash('success', Yii::t('app', 'Record has been saved'));
118
                    $returnUrl = Yii::$app->request->get('returnUrl', ['meta']);
119
                    switch (Yii::$app->request->post('action', 'save')) {
120
                        case 'next':
121
                            return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(a...rnUrl' => $returnUrl)); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...oller::actionUpdateMeta of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
122
                                [
123
                                    'create-meta',
124
                                    'returnUrl' => $returnUrl,
125
                                ]
126
                            );
127
                        case 'back':
128
                            return $this->redirect($returnUrl);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect($returnUrl); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...oller::actionUpdateMeta of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
129
                        default:
130
                            return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(\...nUrl' => $returnUrl))); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...oller::actionUpdateMeta of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
131
                                Url::toRoute(
132
                                    [
133
                                        'update-meta',
134
                                        'id' => $model->getPrimaryKey(),
135
                                        'returnUrl' => $returnUrl,
136
                                    ]
137
                                )
138
                            );
139
                    }
140
                }
141
142
            } else {
143
                return $this->render(
144
                    'updateMeta',
145
                    [
146
                        'model' => $model,
147
                    ]
148
                );
149
            }
150
        } else {
151
            throw new NotFoundHttpException('Meta tag '.$id.' not found');
152
        }
153
    }
154
155
    /**
156
     * Creates a new Meta model.
157
     * If creation is successful, the browser will be redirected to the 'meta' page.
158
     * @return string|\yii\web\Response
159
     */
160
    public function actionCreateMeta()
0 ignored issues
show
Coding Style introduced by
actionCreateMeta uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
161
    {
162
        $model = new Meta();
163
        if ($model->load($_POST) && $model->save()) {
164
            Yii::$app->session->setFlash('success', Yii::t('app', 'Record has been saved'));
165
            $returnUrl = Yii::$app->request->get('returnUrl', ['meta']);
166
            switch (Yii::$app->request->post('action', 'save')) {
167
                case 'next':
168
                    return $this->redirect(
169
                        [
170
                            'create-meta',
171
                            'returnUrl' => $returnUrl,
172
                        ]
173
                    );
174
                case 'back':
175
                    return $this->redirect($returnUrl);
176
                default:
177
                    return $this->redirect(
178
                        Url::toRoute(
179
                            [
180
                                'update-meta',
181
                                'id' => $model->key,
182
                                'returnUrl' => $returnUrl,
183
                            ]
184
                        )
185
                    );
186
            }
187
        } else {
188
            return $this->render(
189
                'createMeta',
190
                [
191
                    'model' => $model,
192
                ]
193
            );
194
        }
195
    }
196
197
    /**
198
     * Deletes an existing Meta model.
199
     * If deletion is successful, the browser will be redirected to the 'meta' page.
200
     * @param $id
201
     * @return \yii\web\Response
202
     */
203
    public function actionDeleteMeta($id)
204
    {
205
        Meta::deleteAll('`key` = :id', [':id' => $id]);
206
        return $this->redirect(['meta']);
207
    }
208
209
    /**
210
     * Deletes an existing Meta models.
211
     * If deletion is successful, the browser will be redirected to the 'index' page.
212
     * @return \yii\web\Response
0 ignored issues
show
Documentation introduced by
Should the return type not be integer|false?

This check compares the return type specified in the @return annotation of a function or method doc comment with the types returned by the function and raises an issue if they mismatch.

Loading history...
213
     */
214
    public function actionDeleteMetas()
0 ignored issues
show
Coding Style introduced by
actionDeleteMetas uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
215
    {
216
        if (isset($_POST['metas'])) {
217
            return Meta::deleteAll(
218
                [
219
                    'in',
220
                    'key',
221
                    $_POST['metas'],
222
                ]
223
            );
224
        }
225
        return false;
226
    }
227
228
    /**
229
     * Deletes meta value from cache
230
     * @return bool if no error happens during deletion
231
     */
232
    public function actionFlushMetaCache()
233
    {
234
        return \Yii::$app->getCache()->delete(\Yii::$app->getModule('seo')->cacheConfig['metaCache']['name']);
235
    }
236
237
    /**
238
     * Show list of Counter models
239
     * @return string
240
     */
241
    public function actionCounter()
0 ignored issues
show
Coding Style introduced by
actionCounter uses the super-global variable $_GET which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
242
    {
243
        $searchModel = new Counter();
244
        $dataProvider = $searchModel->search($_GET);
245
        AceHelper::setAceScript($this);
246
        return $this->render(
247
            'counter',
248
            [
249
                'dataProvider' => $dataProvider,
250
                'searchModel' => $searchModel,
251
            ]
252
        );
253
    }
254
255
    /**
256
     * Updates an existing Counter model.
257
     * If update is successful, the browser will be redirected to the 'meta' page.
258
     * @param $id
259
     * @return string
260
     * @throws \yii\web\NotFoundHttpException
261
     */
262 View Code Duplication
    public function actionUpdateCounter($id)
0 ignored issues
show
Coding Style introduced by
actionUpdateCounter uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
263
    {
264
        /* @var $model Counter */
265
        $model = Counter::find()->where(
266
            [
267
                'id' => $id,
268
            ]
269
        )->one();
270
        AceHelper::setAceScript($this);
271
        if ($model !== null) {
272
            if ($model->load($_POST) && $model->validate()) {
273
                if ($model->save()) {
274
                    Yii::$app->session->setFlash('success', Yii::t('app', 'Record has been saved'));
275
                    $returnUrl = Yii::$app->request->get('returnUrl', ['counter']);
276
                    switch (Yii::$app->request->post('action', 'save')) {
277
                        case 'next':
278
                            return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(a...rnUrl' => $returnUrl)); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...er::actionUpdateCounter of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
279
                                [
280
                                    'create-counter',
281
                                    'returnUrl' => $returnUrl,
282
                                ]
283
                            );
284
                        case 'back':
285
                            return $this->redirect($returnUrl);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect($returnUrl); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...er::actionUpdateCounter of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
286
                        default:
287
                            return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(\...nUrl' => $returnUrl))); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...er::actionUpdateCounter of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
288
                                Url::toRoute(
289
                                    [
290
                                        'update-counter',
291
                                        'id' => $model->id,
292
                                        'returnUrl' => $returnUrl
293
                                    ]
294
                                )
295
                            );
296
                    }
297
                }
298
299
            } else {
300
                return $this->render(
301
                    'updateCounter',
302
                    [
303
                        'model' => $model,
304
                    ]
305
                );
306
            }
307
        } else {
308
            throw new NotFoundHttpException('counter #'.$id.' not found');
309
        }
310
    }
311
312
    /**
313
     * Creates a new Counter model.
314
     * If creation is successful, the browser will be redirected to the 'counter' page.
315
     * @return string|\yii\web\Response
316
     */
317
    public function actionCreateCounter()
0 ignored issues
show
Coding Style introduced by
actionCreateCounter uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
318
    {
319
        $model = new Counter();
320
        AceHelper::setAceScript($this);
321
        if ($model->load($_POST) && $model->save()) {
322
            Yii::$app->session->setFlash('success', Yii::t('app', 'Record has been saved'));
323
            $returnUrl = Yii::$app->request->get('returnUrl', ['counter']);
324
            if (Yii::$app->request->post('action', 'back') == 'next') {
325
                $route = ['create-counter', 'returnUrl' => $returnUrl];
326
                if (!is_null(Yii::$app->request->get('parent_id', null))) {
327
                    $route['parent_id'] = Yii::$app->request->get('parent_id');
328
                }
329
                return $this->redirect($route);
330
            } else {
331
                return $this->redirect($returnUrl);
332
            }
333
334
        } else {
335
            return $this->render(
336
                'createCounter',
337
                [
338
                    'model' => $model,
339
                ]
340
            );
341
        }
342
    }
343
344
    /**
345
     * Deletes an existing Meta model.
346
     * If deletion is successful, the browser will be redirected to the 'counter' page.
347
     * @param $id
348
     * @return \yii\web\Response
349
     */
350
    public function actionDeleteCounter($id)
351
    {
352
        Counter::deleteAll('`id` = :id', [':id' => $id]);
353
        return $this->redirect(['counter']);
354
    }
355
356
    /**
357
     * Deletes an existing Counter models.
358
     * If deletion is successful, the browser will be redirected to the 'counter' page.
359
     * @return \yii\web\Response
0 ignored issues
show
Documentation introduced by
Should the return type not be integer|false?

This check compares the return type specified in the @return annotation of a function or method doc comment with the types returned by the function and raises an issue if they mismatch.

Loading history...
360
     */
361
    public function actionDeleteCounters()
0 ignored issues
show
Coding Style introduced by
actionDeleteCounters uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
362
    {
363
        if (isset($_POST['counters'])) {
364
            return Counter::deleteAll(
365
                [
366
                    'in',
367
                    'id',
368
                    $_POST['counters'],
369
                ]
370
            );
371
        }
372
        return false;
373
    }
374
375
    /**
376
     * Deletes counter value from cache
377
     * @return bool if no error happens during deletion
378
     */
379
    public function actionFlushCounterCache()
380
    {
381
        return \Yii::$app->getCache()->delete(\Yii::$app->getModule('seo')->cacheConfig['counterCache']['name']);
382
    }
383
384
    /**
385
     * Update robots.txt
386
     * @return string|\yii\web\Response
387
     * @throws \yii\web\NotFoundHttpException
388
     */
389
    public function actionRobots()
390
    {
391
        $model = Robots::getModel();
392
        if ($model === null) {
393
            $model = new Robots();
394
        }
395
396
        if (Yii::$app->request->isPost) {
397
            if ($model->load(Yii::$app->request->post()) && $model->validate()) {
398
                $model->save();
399
                return $this->refresh();
400
            }
401
        }
402
403
        return $this->render('robots', ['model' => $model]);
404
    }
405
406
    /**
407
     * Show list of Redirect models
408
     * @return string
409
     */
410 View Code Duplication
    public function actionRedirect()
0 ignored issues
show
Coding Style introduced by
actionRedirect uses the super-global variable $_GET which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
411
    {
412
        $searchModel = new Redirect(['scenario' => 'search']);
413
        $dataProvider = $searchModel->search($_GET);
414
        return $this->render(
415
            'redirect',
416
            [
417
                'dataProvider' => $dataProvider,
418
                'searchModel' => $searchModel,
419
            ]
420
        );
421
    }
422
423
    /**
424
     * Creates a new Redirect model.
425
     * If creation is successful, the browser will be redirected to the 'redirect' page.
426
     * @return string|\yii\web\Response
427
     */
428
    public function actionCreateRedirect()
0 ignored issues
show
Coding Style introduced by
actionCreateRedirect uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
429
    {
430
        $model = new Redirect(['active' => true]);
431
        if ($model->load($_POST) && $model->save()) {
432
            $action = Yii::$app->request->post('action', 'save');
433
            $returnUrl = Yii::$app->request->get('returnUrl', ['index']);
434
            switch ($action) {
435
                case 'next':
436
                    return $this->redirect(
437
                        [
438
                            'create-redirect',
439
                            'returnUrl' => $returnUrl,
440
                        ]
441
                    );
442
                case 'back':
443
                    return $this->redirect($returnUrl);
444
                default:
445
                    return $this->redirect(
446
                        Url::toRoute(
447
                            [
448
                                'update-redirect',
449
                                'id' => $model->id,
450
                                'returnUrl' => $returnUrl,
451
                            ]
452
                        )
453
                    );
454
            }
455
        } else {
456
            return $this->render(
457
                'createRedirect',
458
                [
459
                    'model' => $model,
460
                ]
461
            );
462
        }
463
    }
464
465
    /**
466
     * Creates a new Redirect models.
467
     * @return string
468
     */
469
    public function actionCreateRedirects()
0 ignored issues
show
Coding Style introduced by
actionCreateRedirects uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
470
    {
471
        if (isset($_POST['redirects'])) {
472
            $all = 0;
473
            $added = 0;
474 View Code Duplication
            if (isset($_POST['redirects']['static']) && !empty($_POST['redirects']['static'])) {
475
                $static = explode("\n", $_POST['redirects']['static']);
476
                foreach ($static as $redirectStr) {
477
                    $all++;
478
                    $r = explode("\t", $redirectStr);
479
                    $redirect = new Redirect(
480
                        [
481
                            'type' => Redirect::TYPE_STATIC,
482
                            'from' => trim($r[0]),
483
                            'to' => trim($r[1]),
484
                            'active' => true,
485
                        ]
486
                    );
487
                    if ($redirect->save()) {
488
                        $added++;
489
                    }
490
                }
491
            }
492 View Code Duplication
            if (isset($_POST['redirects']['regular']) && !empty($_POST['redirects']['regular'])) {
493
                $regular = explode("\n", $_POST['redirects']['regular']);
494
                foreach ($regular as $redirectStr) {
495
                    $all++;
496
                    $r = explode("\t", $redirectStr);
497
                    $redirect = new Redirect(
498
                        [
499
                            'type' => Redirect::TYPE_PREG,
500
                            'from' => trim($r[0]),
501
                            'to' => trim($r[1]),
502
                            'active' => true,
503
                        ]
504
                    );
505
                    if ($redirect->save()) {
506
                        $added++;
507
                    }
508
                }
509
            }
510
511
            Yii::$app->session->setFlash('success', Yii::t('app', 'Records has been saved'));
512
            $returnUrl = Yii::$app->request->get('returnUrl', ['/redirect']);
513
            switch (Yii::$app->request->post('action', 'save')) {
514
                case 'next':
515
                    return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(a...rnUrl' => $returnUrl)); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...::actionCreateRedirects of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
516
                        [
517
                            'create-redirects',
518
                            'returnUrl' => $returnUrl,
519
                        ]
520
                    );
521
                case 'back':
522
                    return $this->redirect($returnUrl);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect($returnUrl); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...::actionCreateRedirects of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
523
                default:
524
                    return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(\...nUrl' => $returnUrl))); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...::actionCreateRedirects of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
525
                        Url::toRoute(
526
                            [
527
                                'redirects',
528
                                'returnUrl' => $returnUrl,
529
                            ]
530
                        )
531
                    );
532
            }
533
534
        } else {
535
            return $this->render('createRedirects');
536
        }
537
538
    }
539
540
    /**
541
     * Updates an existing Redirect model.
542
     * If update is successful, the browser will be redirected to the 'redirect' page.
543
     * @param $id
544
     * @return string
545
     * @throws \yii\web\NotFoundHttpException
546
     */
547 View Code Duplication
    public function actionUpdateRedirect($id)
0 ignored issues
show
Coding Style introduced by
actionUpdateRedirect uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
548
    {
549
        /* @var $model Redirect */
550
        $model = Redirect::find()->where(
551
            [
552
                'id' => $id,
553
            ]
554
        )->one();
555
        if ($model !== null) {
556
            if ($model->load($_POST) && $model->validate()) {
557
                if ($model->save()) {
558
                    Yii::$app->session->setFlash('success', Yii::t('app', 'Records has been saved'));
559
                    $returnUrl = Yii::$app->request->get('returnUrl', ['redirect']);
560
                    switch (Yii::$app->request->post('action', 'save')) {
561
                        case 'next':
562
                            return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(a...rnUrl' => $returnUrl)); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...r::actionUpdateRedirect of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
563
                                [
564
                                    'create-redirect',
565
                                    'returnUrl' => $returnUrl,
566
                                ]
567
                            );
568
                        case 'back':
569
                            return $this->redirect($returnUrl);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect($returnUrl); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...r::actionUpdateRedirect of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
570
                        default:
571
                            return $this->redirect(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->redirect(\...nUrl' => $returnUrl))); (yii\web\Response) is incompatible with the return type documented by app\modules\seo\controll...r::actionUpdateRedirect of type string.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
572
                                Url::toRoute(
573
                                    [
574
                                        'update-redirect',
575
                                        'id' => $model->id,
576
                                        'returnUrl' => $returnUrl,
577
                                    ]
578
                                )
579
                            );
580
                    }
581
                }
582
            } else {
583
                return $this->render(
584
                    'updateRedirect',
585
                    [
586
                        'model' => $model,
587
                    ]
588
                );
589
            }
590
        } else {
591
            throw new NotFoundHttpException('redirect #'.$id.' not found');
592
        }
593
    }
594
595
    /**
596
     * Deletes an existing Redirect model.
597
     * If deletion is successful, the browser will be redirected to the 'redirect' page.
598
     * @param $id
599
     * @return \yii\web\Response
600
     */
601
    public function actionDeleteRedirect($id)
602
    {
603
        Redirect::deleteAll('`id` = :id', [':id' => $id]);
604
        return $this->redirect(['redirect']);
605
    }
606
607
    /**
608
     * Deletes an existing Redirect models.
609
     * If deletion is successful, the browser will be redirected to the 'redirect' page.
610
     * @return \yii\web\Response
0 ignored issues
show
Documentation introduced by
Should the return type not be integer|false?

This check compares the return type specified in the @return annotation of a function or method doc comment with the types returned by the function and raises an issue if they mismatch.

Loading history...
611
     */
612
    public function actionDeleteRedirects()
0 ignored issues
show
Coding Style introduced by
actionDeleteRedirects uses the super-global variable $_POST which is generally not recommended.

Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable:

// Bad
class Router
{
    public function generate($path)
    {
        return $_SERVER['HOST'].$path;
    }
}

// Better
class Router
{
    private $host;

    public function __construct($host)
    {
        $this->host = $host;
    }

    public function generate($path)
    {
        return $this->host.$path;
    }
}

class Controller
{
    public function myAction(Request $request)
    {
        // Instead of
        $page = isset($_GET['page']) ? intval($_GET['page']) : 1;

        // Better (assuming you use the Symfony2 request)
        $page = $request->query->get('page', 1);
    }
}
Loading history...
613
    {
614
        if (isset($_POST['redirects'])) {
615
            return Redirect::deleteAll(
616
                [
617
                    'in',
618
                    'id',
619
                    $_POST['redirects'],
620
                ]
621
            );
622
        }
623
        return false;
624
    }
625
626
    public function actionGenerateRedirectFile()
627
    {
628
        echo Redirect::generateRedirectFile();
629
    }
630
631
    public function actionDeleteRedirectFile()
632
    {
633
        echo (int)Redirect::deleteRedirectFile();
634
    }
635
636
    public function actionEcommerce()
0 ignored issues
show
Documentation introduced by
The return type could not be reliably inferred; please add a @return annotation.

Our type inference engine in quite powerful, but sometimes the code does not provide enough clues to go by. In these cases we request you to add a @return annotation as described here.

Loading history...
637
    {
638
        $yaCounter = $gaCounter = ['id' => '', 'active' => 0];
639
640
        if (Yii::$app->request->isPost) {
641
            $gaCounter = array_merge($gaCounter, Yii::$app->request->post('GoogleCounter', []));
642
            $yaCounter = array_merge($yaCounter, Yii::$app->request->post('YandexCounter', []));
643
644
            $model = Config::getModelByKey('ecommerceCounters');
645
            if (empty($model)) {
646
                $model = new Config();
647
                $model->key = 'ecommerceCounters';
648
            }
649
            $model->value = Json::encode(['google' => $gaCounter, 'yandex' => $yaCounter]);
650
            $model->save();
651
        }
652
653
        $counters = Config::getModelByKey('ecommerceCounters');
654
        if (!empty($counters)) {
655
            $counters = Json::decode($counters->value);
656
            $gaCounter = !empty($counters['google']) ? $counters['google'] : $gaCounter;
657
            $yaCounter = !empty($counters['yandex']) ? $counters['yandex'] : $yaCounter;
658
        }
659
660
        return $this->render(
661
            'ecommerce-counters',
662
            [
663
                'gaCounter' => $gaCounter,
664
                'yaCounter' => $yaCounter
665
            ]
666
        );
667
    }
668
669
    public static function renderEcommerceCounters(Event $event)
670
    {
671
        /** @var OrderTransaction $orderTransaction */
672
        $orderTransaction = OrderTransaction::findOne($event->data['transactionId']);
673
        $config = Config::getModelByKey('ecommerceCounters');
674
        if (empty($event->data['transactionId']) || empty($config) || !isset($orderTransaction->order)) {
675
            return ;
676
        }
677
678
        if (!empty($orderTransaction->order->items)) {
679
            $products = [];
680
            foreach ($orderTransaction->order->items as $item) {
681
                $product = Product::findById($item->product_id, null, null);
0 ignored issues
show
Unused Code introduced by
The call to Product::findById() has too many arguments starting with null.

This check compares calls to functions or methods with their respective definitions. If the call has more arguments than are defined, it raises an issue.

If a function is defined several times with a different number of parameters, the check may pick up the wrong definition and report false positives. One codebase where this has been known to happen is Wordpress.

In this case you can add the @ignore PhpDoc annotation to the duplicate definition and it will be ignored.

Loading history...
682
                if (empty($product)) {
683
                    continue;
684
                }
685
                $category = Category::findById($product->main_category_id);
686
                $category = empty($category) ? 'Магазин' : str_replace('\'', '', $category->name);
687
688
                $products[] = [
689
                    'id' => $product->id,
690
                    'name' => str_replace('\'', '', $product->name),
691
                    'price' => number_format($product->price, 2, '.', ''),
692
                    'category' => $category,
693
                    'qnt' => $item->quantity
694
                ];
695
            }
696
697
            $order = [
698
                'id' => $orderTransaction->order->id,
699
                'total' => number_format($orderTransaction->order->total_price, 2, '.', ''),
700
            ];
701
702
            echo Yii::$app->view->renderFile(Yii::getAlias('@app/modules/seo/views/manage/_ecommerceCounters.php'), [
703
                'order' => $order,
704
                'products' => $products,
705
                'config' => Json::decode($config->value)
706
            ]);
707
        }
708
    }
709
}
710