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 Failed
Push — master ( 8bca22...568bf9 )
by Gabriel
13:02 queued 05:02
created

Model::getImageSize()   A

Complexity

Conditions 2
Paths 2

Size

Total Lines 12
Code Lines 7

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 0
CRAP Score 6

Importance

Changes 0
Metric Value
dl 0
loc 12
ccs 0
cts 6
cp 0
rs 9.4285
c 0
b 0
f 0
cc 2
eloc 7
nc 2
nop 1
crap 6
1
<?php
2
3
namespace ByTIC\Common\Records\Media\Images;
4
5
use Nip\Filesystem\Image;
6
7
/**
8
 * Class Model
9
 * @package ByTIC\Common\Records\Media\Images
10
 */
11
class Model extends Image
12
{
13
    use \ByTIC\Common\Records\Media\Traits\HasModels;
14
    use \ByTIC\Common\Records\Media\Traits\HydrateCollection;
15
16
    public $basePath;
17
    public $baseURL;
18
    public $cropWidth;
19
    public $cropHeight;
20
21
    protected $_type;
22
    protected $mediaCollection = 'images';
23
24
    /**
25
     * @return Model
26
     */
27
    public function getSmall()
28
    {
29
        return $this->getImageSize("small");
30
    }
31
32
    /**
33
     * @param $type
34
     * @return $this
35
     */
36
    public function getImageSize($type)
37
    {
38
        if ($type == $this->_type) {
39
            return $this;
40
        } else {
41
            $image = $this->_model->getNewImage($type);
0 ignored issues
show
Bug introduced by
The property _model does not seem to exist. Did you mean model?

An attempt at access to an undefined property has been detected. This may either be a typographical error or the property has been renamed but there are still references to its old name.

If you really want to allow access to undefined properties, you can define magic methods to allow access. See the php core documentation on Overloading.

Loading history...
42
43
            $image->setName($this->name);
44
45
            return $image;
46
        }
47
    }
48
49
    /**
50
     * @return Model
51
     */
52
    public function getMedium()
53
    {
54
        return $this->getImageSize("medium");
55
    }
56
57
    /**
58
     * @return Model
59
     */
60
    public function getLarge()
61
    {
62
        return $this->getImageSize("large");
63
    }
64
65
    /**
66
     * @return Model
67
     */
68
    public function getFull()
69
    {
70
        return $this->getImageSize("full");
71
    }
72
73
    /**
74
     * @param string $path
75
     * @return bool
76
     */
77
    public function setResourceFromFile($path)
78
    {
79
        parent::setResourceFromFile($path);
80
        $this->setName(pathinfo($path, PATHINFO_BASENAME));
81
82
        return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (ByTIC\Common\Records\Media\Images\Model) is incompatible with the return type of the parent method Nip\Filesystem\Image::setResourceFromFile of type boolean.

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...
83
    }
84
85
//    /**
0 ignored issues
show
Unused Code Comprehensibility introduced by
49% of this comment could be valid code. Did you maybe forget this after debugging?

Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.

The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.

This check looks for comments that seem to be mostly valid code and reports them.

Loading history...
86
//     * @param string $name
87
//     */
88
//    public function setName($name)
89
//    {
90
//        parent::setName($name);
91
//        $this->url = $this->getModel()->getImageURL($this->_type, $this->name);
92
//        $this->path = $this->getModel()->getImagePath($this->_type, $this->name);
93
//    }
94
95
    /**
96
     * @param Image $image
97
     * @return $this
98
     */
99
    public function copyResource($image)
100
    {
101
        parent::copyResource($image);
102
        $this->setName($image->name);
103
104
        return $this;
105
    }
106
107
    /**
108
     * @return mixed
109
     */
110
    public function getDefaultWidth()
111
    {
112
        $option = "images_" . $this->getModel()->getManager()->getTable() . "_" . $this->_type . "_width";
113
        return Options::instance()->$option;
114
    }
115
116
    /**
117
     * @return mixed
118
     */
119
    public function getDefaultHeight()
120
    {
121
        $option = "images_" . $this->getManager()->getTable() . "_" . $this->_type . "_height";
0 ignored issues
show
Documentation Bug introduced by
The method getManager does not exist on object<ByTIC\Common\Records\Media\Images\Model>? Since you implemented __call, maybe consider adding a @method annotation.

If you implement __call and you know which methods are available, you can improve IDE auto-completion and static analysis by adding a @method annotation to the class.

This is often the case, when __call is implemented by a parent class and only the child class knows which methods exist:

class ParentClass {
    private $data = array();

    public function __call($method, array $args) {
        if (0 === strpos($method, 'get')) {
            return $this->data[strtolower(substr($method, 3))];
        }

        throw new \LogicException(sprintf('Unsupported method: %s', $method));
    }
}

/**
 * If this class knows which fields exist, you can specify the methods here:
 *
 * @method string getName()
 */
class SomeClass extends ParentClass { }
Loading history...
122
        return Options::instance()->$option;
123
    }
124
125
    /**
126
     * @return mixed
127
     */
128
    public function getImageType()
129
    {
130
        return $this->_type;
131
    }
132
133
    /**
134
     * @return bool
135
     */
136
    public function save()
137
    {
138
        $this->path = $this->path ? $this->path : $this->basePath . $this->name;
139
        parent::save();
140
141
        return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (ByTIC\Common\Records\Media\Images\Model) is incompatible with the return type of the parent method Nip\Filesystem\Image::save of type boolean.

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...
142
    }
143
144
    /**
145
     * @param bool $bubble
146
     * @return $this
147
     */
148
    public function delete($bubble = false)
149
    {
150
        if ($bubble) {
151
            return parent::delete();
0 ignored issues
show
Bug Best Practice introduced by
The return type of return parent::delete(); (boolean) is incompatible with the return type documented by ByTIC\Common\Records\Media\Images\Model::delete of type ByTIC\Common\Records\Media\Images\Model.

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...
152
        } else {
153
            return $this->getModel()->deleteImage($this->name);
154
        }
155
    }
156
}
157