<p>I've actually answered the question in the question. Not sure why it's not showing as is, but the solution is updating the plugin file as mentioned above.</p>

CC BY-SA 3.0
2017-04-05T19:13:13.927Z
This worked for me. Can the developer of Charge please add this into the next release. Thanks
Adam Menczykowski
CC BY-SA 3.0
2016-12-23T19:48:01.487Z
2016-12-23T19:48:01.487Z
Natalie
<p>I'm the developer of Charge.</p>

<p>The above issue is caused because you're passing in the <strong>title</strong> of the email, not the <strong>handle</strong>.</p>

<p><strong>We explicitly require the handle to be passed to ensure uniqueness.</strong> While the above patch would bypass the issue and let you define it by title, it's not ideal, and the proper fix is to the simply pass it by the handle in your templates. </p>

<p>From the above example, the handle would be <code>welcome_email</code>. It's directly shown in the email table in your Charge > Settings > Emails. </p>

<p>To help other's who might end up mistakenly passing the title instead of the handle, I've added a patch to the 2.2.1 release which explicitly watches for instances of a passed title instead of a handle, and throws a new message in the logging to notify the developer. </p>

CC BY-SA 3.0
2017-04-10T16:21:20.960Z
FYI I used the JS 'picker' in the admin area of charge plugin to pick the emails to be sent, I did not set up the emails in my templates using the `success` property in the object.
Adam Menczykowski
CC BY-SA 3.0
2017-04-10T16:27:57.977Z
Still getting the same issue Joel. I just updated the plugin to 2.2 locally and tested a purchase in Stripe test mode. The logs state that `Failed to find email with the handle : Welcome Email` and after payment was accepted the front end displayed a Recoverable Error `Object of class Craft\Charge_SubscriptionModel could not be converted to string`
Adam Menczykowski
CC BY-SA 3.0
2017-04-11T09:32:16.660Z
Ah. Thanks, that's a lot clearer. I'll patch that in the next release. From the above, I'd understood the issue as defining the email at the template level. I'll get a patch out shortly.
Joel Bradbury
CC BY-SA 3.0
2017-04-10T08:46:41.407Z
2017-04-10T08:46:41.407Z
Joel Bradbury
<p>So I've actually created a fix for this, but it's a bit complicated. Wanted to share in case anyone else runs into this problem.</p>

<p>Working in Craft 2.6.2954 and Charge Pro 2.18</p>

<p>When creating new subscriptions, the emails were not being sent properly. I checked the charge logs in the charge plugin and it was giving me an error of "Failed to find email with the handle : Welcome Email". I figured out that "Welcome Email" was the correct name of my email, but it wasn't the handle, which is why it wasn't being found. I created a new function in the Charge_EmailService.php file called _getEmailModelByName, you can see it here:</p>

<pre><code>private function _getEmailModelByName($handle = null)
{
    if ($handle) {
        $emailRecord = Charge_EmailRecord::model()-&gt;findByAttributes(
            ['name' =&gt; $handle]);

        if (!$emailRecord) {
            return false;
        }

        $model = Charge_EmailModel::populateModel($emailRecord);

        return $model;
    }

    return false;
}
</code></pre>

<p>I then updated the sendByHandle function to do a few checks on the handle and try to find the email a different way. Here's the new sendByEmail function:</p>

<pre><code>public function sendByHandle($handle, ChargeModel $chargeModel, $extra = [])
{

    if(is_int($handle)){
        $emailModel = $this-&gt;_getEmailModelById($handle);
    } else {
        $emailModel = $this-&gt;_getEmailModelByHandle($handle);
    }

    if($emailModel == false) {
        $emailModel = $this-&gt;_getEmailModelByName($handle);
    }


    if($emailModel == false) {
        craft()-&gt;charge_log-&gt;error('Failed to find email with the handle : '.$handle, ['extra' =&gt; $extra, 'charge' =&gt; $chargeModel]);
        return false;
    }

    $data['charge'] = $chargeModel;
    foreach($extra as $key =&gt; $arr) {
        $data[$key] = $arr;
    }

    $emailModel-&gt;send($data);
}
</code></pre>

<p>Looks like this is now working as it should. Hope it saves someone else some frustration.</p>

CC BY-SA 3.0
2016-12-22T18:27:30.283Z
Can you add your solution as official answer to the original question?  I'd also suggest contact the author of the plugin to look into the original problem in case it's a bug and so you wouldn't have to maintain hacking core plugin files across updates.
Brad Bell
CC BY-SA 3.0
2016-12-23T19:48:46.370Z
Thanks for the suggestions! I am in contact with the author of the plugin, but they have been kinda unresponsive. I also pointed them to this thread so that they can see what changes I made.
Natalie
CC BY-SA 3.0
2017-04-10T08:41:45.183Z
@Natalie I'm the developer of Charge here. Unfortunately, this fix isn't ideal. By design the emails must be passed via the `handle`, not via the email title. Titles aren't checked for uniqueness or validated in other ways, so we can't be sure the email is correct. I've added a new patch into the logging system to watch for the situation and pass a direct message with the appropriate fix - which is to explicitly pass in the `handle`, in this case `welcome_email`
Joel Bradbury
<plugin-charge>
Charge Pro not sending Subscription Emails
# Charge Pro not sending Subscription Emails

(Asked by: username_0 on 2016-12-22)

So I've actually created a fix for this, but it's a bit complicated. Wanted to share in case anyone else runs into this problem.
Working in Craft 2.6.2954 and Charge Pro 2.18
When creating new subscriptions, the emails were not being sent properly. I checked the charge logs in the charge plugin and it was giving me an error of "Failed to find email with the handle : Welcome Email". I figured out that "Welcome Email" was the correct name of my email, but it wasn't the handle, which is why it wasn't being found. I created a new function in the Charge_EmailService.php file called _getEmailModelByName, you can see it here:
private function _getEmailModelByName($handle = null)
{
    if ($handle) {
        $emailRecord = Charge_EmailRecord::model()->findByAttributes(
            ['name' => $handle]);

        if (!$emailRecord) {
            return false;
        }

        $model = Charge_EmailModel::populateModel($emailRecord);

        return $model;
    }

    return false;
}

I then updated the sendByHandle function to do a few checks on the handle and try to find the email a different way. Here's the new sendByEmail function:
public function sendByHandle($handle, ChargeModel $chargeModel, $extra = [])
{

    if(is_int($handle)){
        $emailModel = $this->_getEmailModelById($handle);
    } else {
        $emailModel = $this->_getEmailModelByHandle($handle);
    }

    if($emailModel == false) {
        $emailModel = $this->_getEmailModelByName($handle);
    }


    if($emailModel == false) {
        craft()->charge_log->error('Failed to find email with the handle : '.$handle, ['extra' => $extra, 'charge' => $chargeModel]);
        return false;
    }

    $data['charge'] = $chargeModel;
    foreach($extra as $key => $arr) {
        $data[$key] = $arr;
    }

    $emailModel->send($data);
}

Looks like this is now working as it should. Hope it saves someone else some frustration.

**Tags:** plugin-charge

> **Comments:**
> **username_1**: Can you add your solution as official answer to the original question?  I'd also suggest contact the author of the plugin to look into the original problem in case it's a bug and so you wouldn't have to maintain hacking core plugin files across updates.  
> **username_0**: Thanks for the suggestions! I am in contact with the author of the plugin, but they have been kinda unresponsive. I also pointed them to this thread so that they can see what changes I made.  
> **username_2**: @username_0 I'm the developer of Charge here. Unfortunately, this fix isn't ideal. By design the emails must be passed via the `handle`, not via the email title. Titles aren't checked for uniqueness or validated in other ways, so we can't be sure the email is correct. I've added a new patch into the logging system to watch for the situation and pass a direct message with the appropriate fix - which is to explicitly pass in the `handle`, in this case `welcome_email`  

---

## 2 answers

### Answer by username_0 on 2016-12-23. Score: 2

I've actually answered the question in the question. Not sure why it's not showing as is, but the solution is updating the plugin file as mentioned above.

> **Comments:**
> **username_3**: This worked for me. Can the developer of Charge please add this into the next release. Thanks  

---

### Answer by username_2 on 2017-04-10. Score: 2

I'm the developer of Charge.

The above issue is caused because you're passing in the **title** of the email, not the **handle**.

**We explicitly require the handle to be passed to ensure uniqueness.** While the above patch would bypass the issue and let you define it by title, it's not ideal, and the proper fix is to the simply pass it by the handle in your templates.

From the above example, the handle would be `welcome_email`. It's directly shown in the email table in your Charge > Settings > Emails.

To help other's who might end up mistakenly passing the title instead of the handle, I've added a patch to the 2.2.1 release which explicitly watches for instances of a passed title instead of a handle, and throws a new message in the logging to notify the developer.

> **Comments:**
> **username_3**: FYI I used the JS 'picker' in the admin area of charge plugin to pick the emails to be sent, I did not set up the emails in my templates using the `success` property in the object.  
> **username_3**: Still getting the same issue Joel. I just updated the plugin to 2.2 locally and tested a purchase in Stripe test mode. The logs state that `Failed to find email with the handle : Welcome Email` and after payment was accepted the front end displayed a Recoverable Error `Object of class Craft\Charge_SubscriptionModel could not be converted to string`  
> **username_2**: Ah. Thanks, that's a lot clearer. I'll patch that in the next release. From the above, I'd understood the issue as defining the email at the template level. I'll get a patch out shortly.  

---

