Worker::validateJobParams()   B
last analyzed

Complexity

Conditions 6
Paths 6

Size

Total Lines 23
Code Lines 11

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 12
CRAP Score 6

Importance

Changes 2
Bugs 0 Features 0
Metric Value
c 2
b 0
f 0
dl 0
loc 23
ccs 12
cts 12
cp 1
rs 8.5907
cc 6
eloc 11
nc 6
nop 1
crap 6
1
<?php
2
3
namespace Messenger\Mail;
4
5
use Cronario\AbstractJob;
6
use Cronario\AbstractWorker;
7
8
class Worker extends AbstractWorker
9
{
10
11
    protected static $config
12
        = [
13
            'client' => [
14
//                "Mailer" => 'smtp',                               // Set mailer to use SMTP
0 ignored issues
show
Unused Code Comprehensibility introduced by
55% 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...
15
//                "Host" => 'smtp1.example.com;smtp2.example.com',  // Specify main and backup SMTP servers
16
//                "SMTPAuth" => true,                               // Enable SMTP authentication
17
//                "Username" => '[email protected]',                 // SMTP username
18
//                "Password" => 'secret',                           // SMTP password
19
//                "SMTPSecure" => 'tls',                            // Enable TLS encryption, `ssl` also accepted
20
//                "Port" => 587,                                    // TCP port to connect to
21
            ]
22
        ];
23
24
    // region VALIDATE ********************************************************
25
26
    /**
27
     * @param Job $job
28
     *
29
     * @throws ResultException
30
     */
31 2
    protected function validateJobParams(Job $job)
32
    {
33 2
        if (empty($job->getFromMail())) {
34 1
            throw new ResultException(ResultException::ERROR_PARAM_FROM_MAIL);
35
        }
36
37 2
        if (empty($job->getFromName())) {
38 1
            throw new ResultException(ResultException::ERROR_PARAM_FROM_NAME);
39
        }
40
41 2
        if (empty($job->getToMail())) {
42 1
            throw new ResultException(ResultException::ERROR_PARAM_TO_MAIL);
43
        }
44
45 2
        if (empty($job->getSubject())) {
46 1
            throw new ResultException(ResultException::ERROR_PARAM_SUBJECT);
47
        }
48
49 2
        if (empty($job->getBody())) {
50 1
            throw new ResultException(ResultException::ERROR_PARAM_BODY);
51
        }
52
53 1
    }
54
55
    // endregion *************************************************************
56
57
    /**
58
     * @return \PHPMailer
59
     */
60
    public function getMail()
61
    {
62
        $mail = new \PHPMailer();
63
64
        $clientConfig = static::getConfig('client');
65
        if(is_array($clientConfig) && count($clientConfig) > 0){
66
            foreach($clientConfig as $key => $value){
67
                $mail->{$key} = $value;
68
            }
69
        }
70
71
        return $mail;
72
    }
73
74
    /**
75
     * @param Job $job
76
     *
77
     * @return array
78
     */
79 1
    protected function sendMail(Job $job)
80
    {
81
82 1
        $mail = $this->getMail();
83
84 1
        $mail->isHTML(true);
85 1
        $mail->setFrom($job->getFromMail(), $job->getFromName());
86 1
        $mail->addAddress($job->getToMail());
87
88 1
        $mail->Subject = $job->getSubject();
0 ignored issues
show
Documentation Bug introduced by
It seems like $job->getSubject() can also be of type integer. However, the property $Subject is declared as type string. Maybe add an additional type check?

Our type inference engine has found a suspicous assignment of a value to a property. This check raises an issue when a value that can be of a mixed type is assigned to a property that is type hinted more strictly.

For example, imagine you have a variable $accountId that can either hold an Id object or false (if there is no account id yet). Your code now assigns that value to the id property of an instance of the Account class. This class holds a proper account, so the id value must no longer be false.

Either this assignment is in error or a type check should be added for that assignment.

class Id
{
    public $id;

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

}

class Account
{
    /** @var  Id $id */
    public $id;
}

$account_id = false;

if (starsAreRight()) {
    $account_id = new Id(42);
}

$account = new Account();
if ($account instanceof Id)
{
    $account->id = $account_id;
}
Loading history...
89 1
        $mail->Body    = $job->getBody();
0 ignored issues
show
Documentation Bug introduced by
It seems like $job->getBody() can also be of type integer. However, the property $Body is declared as type string. Maybe add an additional type check?

Our type inference engine has found a suspicous assignment of a value to a property. This check raises an issue when a value that can be of a mixed type is assigned to a property that is type hinted more strictly.

For example, imagine you have a variable $accountId that can either hold an Id object or false (if there is no account id yet). Your code now assigns that value to the id property of an instance of the Account class. This class holds a proper account, so the id value must no longer be false.

Either this assignment is in error or a type check should be added for that assignment.

class Id
{
    public $id;

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

}

class Account
{
    /** @var  Id $id */
    public $id;
}

$account_id = false;

if (starsAreRight()) {
    $account_id = new Id(42);
}

$account = new Account();
if ($account instanceof Id)
{
    $account->id = $account_id;
}
Loading history...
90 1
        $mail->AltBody = strip_tags($job->getBody());
91
92 1
        $attachments = $job->getAttachment();
93 1
        if (!empty($attachments) && is_array($attachments) && count($attachments) > 0) {
94 1
            foreach ($attachments as $key => $attach) {
95 1
                if(isset($attach[Job::P_PARAM_ATTACHMENT__NAME])){
96 1
                    $mail->addAttachment($attach[Job::P_PARAM_ATTACHMENT__PATH] , $attach[Job::P_PARAM_ATTACHMENT__NAME]);
97 1
                } else {
98
                    $mail->addAttachment($attach[Job::P_PARAM_ATTACHMENT__PATH]);
99
                }
100 1
            }
101 1
        }
102
103 1
        $isSend = $mail->send();
104
105
        return [
106
            'success' => $isSend
107 1
        ];
108
    }
109
110
    /**
111
     * @param AbstractJob|Job $job
112
     *
113
     * @throws ResultException
114
     */
115 2
    protected function doJob(AbstractJob $job)
116
    {
117 2
        $this->validateJobParams($job);
0 ignored issues
show
Compatibility introduced by
$job of type object<Cronario\AbstractJob> is not a sub-type of object<Messenger\Mail\Job>. It seems like you assume a child class of the class Cronario\AbstractJob to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
118
119
        try {
120
121 1
            $response = $this->sendMail($job);
0 ignored issues
show
Compatibility introduced by
$job of type object<Cronario\AbstractJob> is not a sub-type of object<Messenger\Mail\Job>. It seems like you assume a child class of the class Cronario\AbstractJob to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
122 1
            $resultData['response'] = $response;
0 ignored issues
show
Coding Style Comprehensibility introduced by
$resultData was never initialized. Although not strictly required by PHP, it is generally a good practice to add $resultData = array(); before regardless.

Adding an explicit array definition is generally preferable to implicit array definition as it guarantees a stable state of the code.

Let’s take a look at an example:

foreach ($collection as $item) {
    $myArray['foo'] = $item->getFoo();

    if ($item->hasBar()) {
        $myArray['bar'] = $item->getBar();
    }

    // do something with $myArray
}

As you can see in this example, the array $myArray is initialized the first time when the foreach loop is entered. You can also see that the value of the bar key is only written conditionally; thus, its value might result from a previous iteration.

This might or might not be intended. To make your intention clear, your code more readible and to avoid accidental bugs, we recommend to add an explicit initialization $myArray = array() either outside or inside the foreach loop.

Loading history...
123
124 1
        } catch (\Exception $ex) {
125
            throw new ResultException(ResultException::RETRY_TRANSPORT_ERROR);
126
        }
127
128 1
        if(!$resultData['response']['success']){
129
            throw new ResultException(ResultException::R_FAILURE, $resultData);
130
        }
131
132 1
        throw new ResultException(ResultException::R_SUCCESS, $resultData);
133
    }
134
}
135