Completed
Push — master ( 603564...3d1dbb )
by Michael
03:27
created

Image_Transform_Driver_Imagick3::save()   C

Complexity

Conditions 8
Paths 28

Size

Total Lines 34
Code Lines 20

Duplication

Lines 34
Ratio 100 %

Importance

Changes 0
Metric Value
cc 8
eloc 20
nc 28
nop 3
dl 34
loc 34
rs 5.3846
c 0
b 0
f 0
1
<?php
0 ignored issues
show
Coding Style Compatibility introduced by
For compatibility and reusability of your code, PSR1 recommends that a file should introduce either new symbols (like classes, functions, etc.) or have side-effects (like outputting something, or including other files), but not both at the same time. The first symbol is defined on line 46 and the first side effect is on line 26.

The PSR-1: Basic Coding Standard recommends that a file should either introduce new symbols, that is classes, functions, constants or similar, or have side effects. Side effects are anything that executes logic, like for example printing output, changing ini settings or writing to a file.

The idea behind this recommendation is that merely auto-loading a class should not change the state of an application. It also promotes a cleaner style of programming and makes your code less prone to errors, because the logic is not spread out all over the place.

To learn more about the PSR-1, please see the PHP-FIG site on the PSR-1.

Loading history...
2
3
/* vim: set expandtab tabstop=4 shiftwidth=4: */
4
5
/**
6
 * imagick PECL extension implementation for Image_Transform package
7
 *
8
 * PHP version 5
9
 *
10
 * LICENSE: This source file is subject to version 3.0 of the PHP license
11
 * that is available through the world-wide-web at the following URI:
12
 * http://www.php.net/license/3_0.txt.  If you did not receive a copy of
13
 * the PHP License and are unable to obtain it through the web, please
14
 * send a note to [email protected] so we can mail you a copy immediately.
15
 *
16
 * @category   Image
17
 * @package    Image_Transform
18
 * @subpackage Image_Transform_Driver_Imagick3
19
 * @author     Philippe Jausions <[email protected]>
20
 * @copyright  2007 The PHP Group
21
 * @license    http://www.php.net/license/3_0.txt  PHP License 3.0
22
 * @version    CVS: $Id: Imagick3.php 266908 2008-10-01 21:11:07Z dufuz $
23
 * @link       http://pear.php.net/package/Image_Transform
24
 */
25
26
require_once 'Image/Transform.php';
27
28
/**
29
 * imagick PECL extension implementation for Image_Transform package
30
 *
31
 * For use of version 2+ of the extension. For version 0.9.* use Imagick2 driver
32
 * instead
33
 *
34
 * @category   Image
35
 * @package    Image_Transform
36
 * @subpackage Image_Transform_Driver_Imagick3
37
 * @author     Philippe Jausions <[email protected]>
38
 * @copyright  2007 The PHP Group
39
 * @license    http://www.php.net/license/3_0.txt  PHP License 3.0
40
 * @version    Release: @package_version@
41
 * @link       http://pear.php.net/package/Image_Transform
42
 * @since      0.9.2
43
 * @since      PHP 5.1.3
44
 * @since      PECL Imagick 2.0.0a1
45
 */
46
class Image_Transform_Driver_Imagick3 extends Image_Transform
0 ignored issues
show
Coding Style Compatibility introduced by
PSR1 recommends that each class must be in a namespace of at least one level to avoid collisions.

You can fix this by adding a namespace to your class:

namespace YourVendor;

class YourClass { }

When choosing a vendor namespace, try to pick something that is not too generic to avoid conflicts with other libraries.

Loading history...
47
{
48
    /**
49
     * Instance of imagick
50
     * @var Imagick
51
     */
52
    var $imagick = null;
0 ignored issues
show
Coding Style introduced by
The visibility should be declared for property $imagick.

The PSR-2 coding standard requires that all properties in a class have their visibility explicitly declared. If you declare a property using

class A {
    var $property;
}

the property is implicitly global.

To learn more about the PSR-2, please see the PHP-FIG site on the PSR-2.

Loading history...
53
54
    /**
55
     * Handler of the image resource before
56
     * the last transformation
57
     * @var array
58
     */
59
    var $oldImage;
0 ignored issues
show
Coding Style introduced by
The visibility should be declared for property $oldImage.

The PSR-2 coding standard requires that all properties in a class have their visibility explicitly declared. If you declare a property using

class A {
    var $property;
}

the property is implicitly global.

To learn more about the PSR-2, please see the PHP-FIG site on the PSR-2.

Loading history...
60
61
    /**
62
     * @see __construct()
63
     */
64
    function Image_Transform_Driver_Imagick3()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
65
    {
66
        $this->__construct();
67
    }
68
69
    /**
70
     * @see http://www.imagemagick.org/www/formats.html
71
     */
72
    function __construct()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
73
    {
74
        if (PEAR::loadExtension('imagick')) {
75
            include 'Image/Transform/Driver/Imagick/ImageTypes.php';
76
        } else {
77
            $this->isError(PEAR::raiseError('Could not find the imagick extension.',
0 ignored issues
show
Bug introduced by
The method raiseError() does not exist on PEAR. Did you maybe mean _raiseError()?

This check marks calls to methods that do not seem to exist on an object.

This is most likely the result of a method being renamed without all references to it being renamed likewise.

Loading history...
78
                IMAGE_TRANSFORM_ERROR_UNSUPPORTED));
79
        }
80
    }
81
82
    /**
83
     * Loads an image
84
     *
85
     * @param string $image filename
86
     *
87
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
88
     * @access public
89
     */
90
    function load($image)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
91
    {
92
        $this->free();
93
        $this->imagick = new Imagick();
94
        try {
95
            $this->imagick->readImage($image);
96
97
        } catch (ImagickException $e) {
98
            $this->free();
99
            return $this->raiseError('Could not load image:'.$e->getMessage(),
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...GE_TRANSFORM_ERROR_IO); (PEAR) is incompatible with the return type documented by Image_Transform_Driver_Imagick3::load of type boolean|PEAR_Error.

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...
100
                IMAGE_TRANSFORM_ERROR_IO);
101
        }
102
103
        $this->image = $image;
104
        $result = $this->_get_image_details($image);
105
        if (PEAR::isError($result)) {
106
            return $result;
107
        }
108
109
        return true;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return true; (boolean) is incompatible with the return type of the parent method Image_Transform::load of type PEAR_Error.

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...
110
    }
111
112
    /**
113
     * Resizes the image
114
     *
115
     * @param integer $new_x   New width
116
     * @param integer $new_y   New height
117
     * @param mixed $options Optional parameters
118
     * <ul>
119
     *  <li>'scaleMethod': "pixel" or "smooth"</li>
120
     * </ul>
121
     *
122
     * @return bool|PEAR_Error TRUE or PEAR_Error object on error
0 ignored issues
show
Documentation introduced by
Should the return type not be PEAR|boolean?

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...
123
     * @access protected
124
     */
125
    function _resize($new_x, $new_y, $options = null)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
126
    {
127
        try {
128
            $scaleMethod = $this->_getOption('scaleMethod', $options, 'smooth');
129
            $blur = ($scaleMethod == 'pixel') ? 0 : 1;
130
            $this->imagick->resizeImage($new_x, $new_y,
131
                                        imagick::FILTER_UNDEFINED, $blur);
132
133
        } catch (ImagickException $e) {
134
            return $this->raiseError('Could not resize image.',
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...RANSFORM_ERROR_FAILED); (PEAR) is incompatible with the return type of the parent method Image_Transform::_resize of type PEAR_Error.

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...
135
                IMAGE_TRANSFORM_ERROR_FAILED);
136
        }
137
138
        $this->new_x = $new_x;
139
        $this->new_y = $new_y;
140
        return true;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return true; (boolean) is incompatible with the return type of the parent method Image_Transform::_resize of type PEAR_Error.

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...
141
142
    } // End resize
143
144
    /**
145
     * Rotates the current image
146
     *
147
     * @param float $angle Rotation angle in degree
148
     * @param array $options Supported options:
0 ignored issues
show
Documentation introduced by
Should the type for parameter $options not be array|null?

This check looks for @param annotations where the type inferred by our type inference engine differs from the declared type.

It makes a suggestion as to what type it considers more descriptive.

Most often this is a case of a parameter that can be null in addition to its declared types.

Loading history...
149
     * <ul>
150
     *  <li>'canvasColor' : array(r ,g, b), named color or #rrggbb</li>
151
     * </ul>
152
     *
153
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
0 ignored issues
show
Documentation introduced by
Should the return type not be boolean|PEAR?

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...
154
     * @access public
155
     */
156
    function rotate($angle, $options = null)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
157
    {
158
        if (($angle % 360) == 0) {
159
            return true;
160
        }
161
        $color = $this->_getColor('canvasColor', $options, array(255, 255, 255));
0 ignored issues
show
Bug introduced by
It seems like $options defined by parameter $options on line 156 can also be of type null; however, Image_Transform::_getColor() does only seem to accept array, maybe add an additional type check?

This check looks at variables that have been passed in as parameters and are passed out again to other methods.

If the outgoing method call has stricter type requirements than the method itself, an issue is raised.

An additional type check may prevent trouble.

Loading history...
162
        if (is_array($color)) {
163
            $color = $this->colorarray2colorhex($color);
164
        }
165
        $pixel = new ImagickPixel($color);
166
        try {
167
            $this->imagick->rotateImage($pixel, $angle);
168
169
        } catch (ImagickException $e) {
170
            return $this->raiseError('Cannot create a new imagick image for the rotation: '.$e->getMessage(),
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...RANSFORM_ERROR_FAILED); (PEAR) is incompatible with the return type of the parent method Image_Transform::rotate of type boolean|PEAR_Error.

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...
171
                IMAGE_TRANSFORM_ERROR_FAILED);
172
        }
173
        $info = $this->imagick->getImageGeometry();
174
        $this->new_x = $info['width'];
175
        $this->new_y = $info['height'];
176
        return true;
177
178
    } // End rotate
179
180
    /**
181
     * Adds text to the image
182
     *
183
     * @param   array   $params Array contains options:
184
     * <ul>
185
     *  <li>'text' (string) The string to draw</li>
186
     *  <li>'x'    (integer) Horizontal position</li>
187
     *  <li>'y'    (integer) Vertical Position</li>
188
     *  <li>'Color' (mixed) Font color</li>
189
     *  <li>'font' (string) Font to be used</li>
190
     *  <li>'size' (integer) Size of the fonts in pixel</li>
191
     * </ul>
192
     *
193
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
0 ignored issues
show
Documentation introduced by
Should the return type not be PEAR|boolean?

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...
194
     * @access public
195
     */
196
    function addText($params)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
197
    {
198
        $this->oldImage = clone $this->imagick;
0 ignored issues
show
Documentation Bug introduced by
It seems like clone $this->imagick of type object<Imagick> is incompatible with the declared type array of property $oldImage.

Our type inference engine has found an assignment to a property that is incompatible with the declared type of that property.

Either this assignment is in error or the assigned type should be added to the documentation/type hint for that property..

Loading history...
199
        $params = array_merge($this->_get_default_text_params(), $params);
200
201 View Code Duplication
        if (is_array($params['color'])) {
0 ignored issues
show
Duplication introduced by
This code seems to be duplicated across your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
202
            $params['color'] = $this->colorarray2colorhex($params['color']);
203
        } else {
204
            $params['color'] = strtolower($params['color']);
205
        }
206
207
        static $cmds = array(
208
            'setFillColor' => 'color',
209
            'setFontSize'  => 'size',
210
            'setFontFace'  => 'font'
211
        );
212
        $this->imagick->beginDraw();
213
214
        foreach ($cmds as $cmd => $v) {
215
            if (!$this->imagick->$cmd($params[$v])) {
216
                return $this->raiseError("Problem with adding Text::{$v} = {$params[$v]}",
217
                    IMAGE_TRANSFORM_ERROR_FAILED);
218
            }
219
        }
220
        if (!$this->imagick->drawAnnotation($params['x'], $params['y'], $params['text'])) {
221
            return $this->raiseError('Problem with adding Text',
222
                IMAGE_TRANSFORM_ERROR_FAILED);
223
        }
224
225
        return true;
226
227
    } // End addText
228
229
230
    /**
231
     * Saves the image to a file
232
     *
233
     * @param $filename string the name of the file to write to
234
     *
235
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
0 ignored issues
show
Documentation introduced by
Should the return type not be PEAR|boolean?

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...
236
     * @access public
237
     */
238 View Code Duplication
    function save($filename, $type = '', $quality = null)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Duplication introduced by
This method seems to be duplicated in your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
239
    {
240
        $options = (is_array($quality)) ? $quality : array();
241
        if (is_numeric($quality)) {
242
            $options['quality'] = $quality;
243
        }
244
        $quality = $this->_getOption('quality', $options, 75);
245
        $this->imagick->setImageCompression($quality);
246
247
        if ($type && strcasecmp($type, $this->type)) {
248
            try {
249
                $this->imagick->setImageFormat($type);
250
251
            } catch (ImagickException $e) {
252
                return $this->raiseError('Could not save image to file (conversion failed).',
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...RANSFORM_ERROR_FAILED); (PEAR) is incompatible with the return type of the parent method Image_Transform::save of type PEAR_Error.

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...
253
                IMAGE_TRANSFORM_ERROR_FAILED);
254
            }
255
        }
256
257
        try {
258
            $this->imagick->writeImage($filename);
259
260
        } catch (ImagickException $e) {
261
            return $this->raiseError('Could not save image to file: '.$e->getMessage(),
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...GE_TRANSFORM_ERROR_IO); (PEAR) is incompatible with the return type of the parent method Image_Transform::save of type PEAR_Error.

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...
262
                IMAGE_TRANSFORM_ERROR_IO);
263
        }
264
265
        if (!$this->keep_settings_on_save) {
266
            $this->free();
267
        }
268
269
        return true;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return true; (boolean) is incompatible with the return type of the parent method Image_Transform::save of type PEAR_Error.

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...
270
271
    } // End save
272
273
    /**
274
     * Displays image without saving and lose changes
275
     *
276
     * This method adds the Content-type HTTP header
277
     *
278
     * @param string type (JPG,PNG...);
279
     * @param int quality 75
280
     *
281
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
0 ignored issues
show
Documentation introduced by
Should the return type not be PEAR|boolean?

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...
282
     * @access public
283
     */
284 View Code Duplication
    function display($type = '', $quality = null)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Duplication introduced by
This method seems to be duplicated in your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
285
    {
286
        $options = (is_array($quality)) ? $quality : array();
287
        if (is_numeric($quality)) {
288
            $options['quality'] = $quality;
289
        }
290
        $quality = $this->_getOption('quality', $options, 75);
291
        $this->imagick->setImageCompression($quality);
292
293
        if ($type && strcasecmp($type, $this->type)) {
294
            try {
295
                $this->imagick->setImageFormat($type);
296
297
            } catch (ImagickException $e) {
298
                return $this->raiseError('Could not save image to file (conversion failed).',
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...RANSFORM_ERROR_FAILED); (PEAR) is incompatible with the return type of the parent method Image_Transform::display of type PEAR_Error.

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...
299
                IMAGE_TRANSFORM_ERROR_FAILED);
300
            }
301
        }
302
        try {
303
            $image = $this->imagick->getImageBlob();
304
305
        } catch (ImagickException $e) {
306
            return $this->raiseError('Could not display image.',
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...GE_TRANSFORM_ERROR_IO); (PEAR) is incompatible with the return type of the parent method Image_Transform::display of type PEAR_Error.

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...
307
                IMAGE_TRANSFORM_ERROR_IO);
308
        }
309
        header('Content-type: ' . $this->getMimeType($type));
310
        echo $image;
311
        $this->free();
312
        return true;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return true; (boolean) is incompatible with the return type of the parent method Image_Transform::display of type PEAR_Error.

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...
313
    }
314
315
    /**
316
     * Adjusts the image gamma
317
     *
318
     * @param float $outputgamma
319
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
320
     * @access public
321
     */
322
    function gamma($outputgamma = 1.0) {
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
323
        if ($outputgamma != 1.0) {
324
            $this->imagick->setImageGamma($outputgamma);
325
        }
326
        return true;
327
    }
328
329
    /**
330
     * Crops the image
331
     *
332
     * @param integer $width Cropped image width
333
     * @param integer $height Cropped image height
334
     * @param integer $x X-coordinate to crop at
335
     * @param integer $y Y-coordinate to crop at
336
     *
337
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
338
     * @access public
339
     */
340 View Code Duplication
    function crop($width, $height, $x = 0, $y = 0)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Duplication introduced by
This method seems to be duplicated in your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
341
    {
342
        // Sanity check
343
        if (!$this->intersects($width, $height, $x, $y)) {
344
            return PEAR::raiseError('Nothing to crop', IMAGE_TRANSFORM_ERROR_OUTOFBOUND);
0 ignored issues
show
Bug introduced by
The method raiseError() does not exist on PEAR. Did you maybe mean _raiseError()?

This check marks calls to methods that do not seem to exist on an object.

This is most likely the result of a method being renamed without all references to it being renamed likewise.

Loading history...
345
        }
346
        try {
347
            $this->imagick->cropImage($width, $height, $x, $y);
348
349
        } catch (ImagickException $e) {
350
            return $this->raiseError('Could not crop image',
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...RANSFORM_ERROR_FAILED); (PEAR) is incompatible with the return type documented by Image_Transform_Driver_Imagick3::crop of type boolean|PEAR_Error.

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...
351
                IMAGE_TRANSFORM_ERROR_FAILED);
352
        }
353
354
        // I think that setting img_x/y is wrong, but scaleByLength() & friends
355
        // mess up the aspect after a crop otherwise.
356
        $this->new_x = $width;
357
        $this->new_y = $height;
358
359
        return true;
360
    }
361
362
    /**
363
     * Converts the image to greyscale
364
     *
365
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
366
     * @access public
367
     */
368
    function greyscale() {
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
369
        $this->imagick->setImageType(Imagick::IMGTYPE_GRAYSCALE);
370
        /*$this->imagick->setImageColorSpace(Imagick::COLORSPACE_GRAY);
0 ignored issues
show
Unused Code Comprehensibility introduced by
63% 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...
371
        $this->imagick->setImageDepth(8);
372
        $this->imagick->separateImageChannel(Imagick::CHANNEL_GRAY);
373
        $this->imagick->setImageChannelDepth(Imagick::CHANNEL_GRAY, 8);*/
374
        return true;
375
    }
376
377
    /**
378
     * Horizontal mirroring
379
     *
380
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
0 ignored issues
show
Documentation introduced by
Should the return type not be PEAR|boolean?

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...
381
     * @access public
382
     */
383
    function mirror()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
384
    {
385
        try {
386
            $this->imagick->flopImage();
387
        } catch (ImagickException $e) {
388
            return $this->raiseError('Could not mirror the image.',
389
                IMAGE_TRANSFORM_ERROR_FAILED);
390
        }
391
        return true;
392
    }
393
394
    /**
395
     * Vertical mirroring
396
     *
397
     * @return bool|PEAR_Error TRUE or a PEAR_Error object on error
0 ignored issues
show
Documentation introduced by
Should the return type not be PEAR|boolean?

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...
398
     * @access public
399
     */
400
    function flip()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
401
    {
402
        try {
403
            $this->imagick->flipImage();
404
405
        } catch (ImagickException $e) {
406
            return $this->raiseError('Could not flip the image.',
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->raiseError...RANSFORM_ERROR_FAILED); (PEAR) is incompatible with the return type of the parent method Image_Transform::flip of type TRUE.

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...
407
                IMAGE_TRANSFORM_ERROR_FAILED);
408
        }
409
        return true;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return true; (boolean) is incompatible with the return type of the parent method Image_Transform::flip of type TRUE.

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...
410
    }
411
412
    /**
413
     * Destroy image handle
414
     *
415
     * @access public
416
     */
417
    function free()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
418
    {
419
        if (isset($this->imagick)) {
420
            $this->imagick->destroy();
421
            $this->imagick = null;
422
        }
423
    }
424
425
    /**
426
     * RaiseError Method - shows imagick Raw errors.
427
     *
428
     * @param string $message message = prefixed message..
429
     * @param int    $code error code
430
     * @return PEAR error object
431
     * @access protected
432
     */
433
    function raiseError($message, $code = 0)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
434
    {
435
        return PEAR::raiseError($message, $code);
0 ignored issues
show
Bug introduced by
The method raiseError() does not exist on PEAR. Did you maybe mean _raiseError()?

This check marks calls to methods that do not seem to exist on an object.

This is most likely the result of a method being renamed without all references to it being renamed likewise.

Loading history...
436
    }
437
}