CheckMail_plugin::hasSession()   A
last analyzed

Complexity

Conditions 1
Paths 1

Size

Total Lines 3
Code Lines 2

Duplication

Lines 0
Ratio 0 %

Importance

Changes 1
Bugs 0 Features 0
Metric Value
c 1
b 0
f 0
dl 0
loc 3
rs 10
cc 1
eloc 2
nc 1
nop 0
1
<?php
2
3
namespace JarvisPHP\Plugins\CheckMail_plugin;
4
5
use JarvisPHP\Core\JarvisSession;
6
use JarvisPHP\Core\JarvisPHP;
7
use JarvisPHP\Core\JarvisLanguage;
8
use JarvisPHP\Core\JarvisTTS;
9
10
/**
11
 * CheckMail plugin - check an imap mailbox for unread emails
12
 * @author Stefano Bianchini
13
 * @website http://www.stefanobianchini.net
14
 */
15
class CheckMail_plugin implements \JarvisPHP\Core\JarvisPluginInterface{
16
    /**
17
     * Priority of plugin
18
     * @var int  
19
     */
20
    var $priority = 5;
0 ignored issues
show
Coding Style introduced by
The visibility should be declared for property $priority.

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...
21
    
22
    /**
23
     * the behaviour of plugin
24
     * @param string $command
25
     */
26
    function answer($command) {
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...
27
        $answer = '';
28
        
29
        //Load credentials from json config
30
        if(file_exists('Plugins/CheckMail_plugin/credentials.json')) {
31
            $json_config = json_decode(file_get_contents('Plugins/CheckMail_plugin/credentials.json'));
32
        }
33
34
        if($json_config) {
35
36
            $mbox = imap_open($json_config->connection_string, $json_config->user, $json_config->password, OP_READONLY);
0 ignored issues
show
Bug introduced by
The variable $json_config does not seem to be defined for all execution paths leading up to this point.

If you define a variable conditionally, it can happen that it is not defined for all execution paths.

Let’s take a look at an example:

function myFunction($a) {
    switch ($a) {
        case 'foo':
            $x = 1;
            break;

        case 'bar':
            $x = 2;
            break;
    }

    // $x is potentially undefined here.
    echo $x;
}

In the above example, the variable $x is defined if you pass “foo” or “bar” as argument for $a. However, since the switch statement has no default case statement, if you pass any other value, the variable $x would be undefined.

Available Fixes

  1. Check for existence of the variable explicitly:

    function myFunction($a) {
        switch ($a) {
            case 'foo':
                $x = 1;
                break;
    
            case 'bar':
                $x = 2;
                break;
        }
    
        if (isset($x)) { // Make sure it's always set.
            echo $x;
        }
    }
    
  2. Define a default value for the variable:

    function myFunction($a) {
        $x = ''; // Set a default which gets overridden for certain paths.
        switch ($a) {
            case 'foo':
                $x = 1;
                break;
    
            case 'bar':
                $x = 2;
                break;
        }
    
        echo $x;
    }
    
  3. Add a value for the missing path:

    function myFunction($a) {
        switch ($a) {
            case 'foo':
                $x = 1;
                break;
    
            case 'bar':
                $x = 2;
                break;
    
            // We add support for the missing case.
            default:
                $x = '';
                break;
        }
    
        echo $x;
    }
    
Loading history...
37
38
            $uids   = imap_search($mbox, 'UNSEEN', SE_UID);
39
            
40
            if(is_array($uids)) {
41
                $answer = sprintf(JarvisLanguage::translate('you_have_new_messages',get_called_class()), count($uids));
42
            } else {
43
                $answer = JarvisLanguage::translate('no_messages',get_called_class());
44
            }
45
46
            if(preg_match(JarvisLanguage::translate('preg_match_read',get_called_class()), $command) && is_array($uids)) {
47
                //Read last message
48
                $result = imap_fetch_overview($mbox, end($uids), FT_UID);
49
                $mail = end($result);
50
                $answer = JarvisLanguage::translate('from',get_called_class()).': '.$mail->from.'. '.JarvisLanguage::translate('subject',get_called_class()).': '.imap_utf8($mail->subject);
51
                JarvisSession::terminate();
52
            }
53
            imap_close($mbox);
54
        }
55
56
        JarvisTTS::speak($answer);
57
        $response = new \JarvisPHP\Core\JarvisResponse($answer, JarvisPHP::getRealClassName(get_called_class()), true);
58
        $response->send();
59
    }
60
    /**
61
     * Get plugin's priority
62
     * @return int
63
     */
64
    function getPriority() {
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
        return $this->priority;
66
    }
67
    
68
    /**
69
     * Is it the right plugin for the command?
70
     * @param string $command
71
     * @return boolean
72
     */
73
    function isLikely($command) {
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...
74
        return preg_match(JarvisLanguage::translate('preg_match_activate_plugin',get_called_class()), $command);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return preg_match(\Jarvi...ed_class()), $command); (integer) is incompatible with the return type declared by the interface JarvisPHP\Core\JarvisPluginInterface::isLikely 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...
75
    }
76
    
77
    /**
78
     * Does the plugin need a session?
79
     * @return boolean
80
     */
81
    function hasSession() {
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...
82
        return true;
83
    }
84
}
85