Bugs and questions

Lakjin

Active Member
Just updated to v1.4.1 a few things:

a) The ElasticEmail {unsubscribe} insert is bugged. It only works in test emails, not when actual campaign is sent. Further, ElasticEmail is now requiring users to insert their company name and address in emails... this should probably be integrated into MailWizz too.

b) Last year I raised a concern about when new subscribers are added while a campaign is running; instead of only emailing existing subscribers when a campaign was a started, MailWizz continues to update the campaign receipts as new ones are added... potentially never ending a campaign. Was this fixed?

c) Any idea why my extension is not working?

Code:
<?php defined('MW_PATH') || exit('No direct script access allowed');

/**
 * Example Extension
 *
 * @package MailWizz EMA
 * @subpackage Example
 * @author Serban George Cristian <cristian.serban@mailwizz.com>
 * @link http://www.mailwizz.com/
 * @copyright 2013-2015 MailWizz EMA (http://www.mailwizz.com)
 * @license http://www.mailwizz.com/license/
 */

class ExampleExt extends ExtensionInit
{
    // name of the extension as shown in the backend panel
    public $name = 'Example';

    // description of the extension as shown in backend panel
    public $description = 'This is an example extension';

    // current version of this extension
    public $version = '1.0';

    // minimum app version
    public $minAppVersion = '1.3.6.2';

    // the author name
    public $author = 'Your name';

    // author website
    public $website = 'http://www.domain.com/';

    // contact email address
    public $email = 'dev@domain.com';

    /**
     * in which apps this extension is allowed to run
     * '*' means all apps
     * available apps: customer, backend, frontend, api, console
     * so you can use any variation,
     * like: array('backend', 'customer'); or array('frontend');
     */
    public $allowedApps = array('*');

    /**
     * This is the reverse of the above
     * Instead of writing:
     * public $allowedApps = array('frontend', 'customer', 'api', 'console');
     * you could say:
     * public $notAllowedApps = array('backend');
     */
    public $notAllowedApps = array();

    // cli enabled
    // since cli is a special case, we need to explicitly enable it
    // do it only if you need to hook inside console hooks
    public $cliEnabled = true;

    // can this extension be deleted? this only applies to core extensions.
    protected $_canBeDeleted = false;

    // can this extension be disabled? this only applies to core extensions.
    protected $_canBeDisabled = false;

    /**
     * The run method is the entry point of the extension.
     * This method is called by mailwizz at the right time to run the extension.
     */
    public function run()
    {
        Yii::app()->hooks->applyFilters('campaigns_get_common_tags_search_replace', function($searchReplace) {
            $searchReplace['[xyz]'] = ' ';
            return $searchReplace;
        });
    }
}
 
@Lakjin -
#1 - I'll have a look at this today and see what's going on. As far as i know, the {unsub} is inserted in all emails regardless of the fact they are tests or actual campaigns.
#2 - If you remember, we had this do like you have asked and that caused some issues and we reverted the changes.
Now this can be avoided with this: https://kb.mailwizz.com/articles/enable-use-temporary-queue-tables-sending-campaigns/
#3 - Try uppercase letters. Also try it in a real test campaign maybe, just to be sure.

Thanks.
 
@Lakjin -
#1 - I'll have a look at this today and see what's going on. As far as i know, the {unsub} is inserted in all emails regardless of the fact they are tests or actual campaigns.
#2 - If you remember, we had this do like you have asked and that caused some issues and we reverted the changes.
Now this can be avoided with this: https://kb.mailwizz.com/articles/enable-use-temporary-queue-tables-sending-campaigns/
#3 - Try uppercase letters. Also try it in a real test campaign maybe, just to be sure.

Thanks.
#1 - For some reason, it doesn't happen. I don't know why.
#2 - When will this feature be stable enough to use in production? What's the issue with simply doing something like this:

Code:
protected function addRegularCriteria(CDbCriteria $criteria)
{
    $criteria->addCondition('t.date_added <= :cdate');
    $criteria->params[':cdate'] = $this->send_at;

This is what I did previously and it worked just fine. (Have not tried this yet in latest version of MailWizz since some of that code has changed.)

#3 - Tried it. Doesn't work. If I put the same code directly into MailWizz files where the filter is, it works.
 
#1 - Will look into it.
#2 - It's most likely very stable for production. I'll do a final review these days and update the article.
#3 - Are you sure the extension is enabled ?
 
@twisted1919 Just tested temporary queue tables on a sample campaign. Temp table is created as intended, subscribers are put in there, and then deleted as intended. Emails are sent just fine. However, the temp table has not been deleted afterwards. Is this intentional or is it supposed to be deleted?
 
@twisted1919 Does enabling this feature only allow one campaign to be sent at a time? Cause that is what looks like is happening.
Okay, I see what is happening. When temporary queue tables enabled, MailWizz only processes one campaign into a temporary queue table at a time. While a campaign is being processed into temporary queue table, PCTNL is in use and thus no other campaigns can be processed or sent. Plus, it takes a *very* long time to save subscribers into temporary queue table (since MailWizz is doing 500 at a time and only one process is being used).

I'm sure there is a way to improve this.
 
@twisted1919 Just tested temporary queue tables on a sample campaign. Temp table is created as intended, subscribers are put in there, and then deleted as intended. Emails are sent just fine. However, the temp table has not been deleted afterwards. Is this intentional or is it supposed to be deleted?
Nevermind on this. I see what you did. You leave the temp tables and clean them up daily via CRON.
 
Most likely we can have a setting for a higher number, for now you can manually increase it to see what fits better for your case ;)
How to increase more than 500 at time and more than one process at a time doing it? Otherwise, it takes a few hours to put hundreds of thousands of subscribers into temp queue tables (all the meanwhile no other campaigns can be run), which almost invalidates the speed increases of this new method.

BTW, I dont know what is wrong with this forum but my support package status won't update.
 
@Lakjin - For once, try to edit /apps/common/components/db/behaviors/CampaignQueueTableBehavior.php and look for 500 and replace it with a higher number.
more than one process at a time doing it?
For now we won't be doing this, increasing the number should help enough.

BTW, I dont know what is wrong with this forum but my support package status won't update.
It takes 24 hours to update your support pack status. Make sure you have the right license key in your account.
 
@Lakjin - For once, try to edit /apps/common/components/db/behaviors/CampaignQueueTableBehavior.php and look for 500 and replace it with a higher number.

Can I increase this as high as I want, without stability issues?

For now we won't be doing this, increasing the number should help enough.
Fair enough. As long as the time to insert subscribers into temporary tables doesn't take too long, I dont care how many processes are doing it. I can tell you, though, at a rate of 500 subscribers with one process, it takes over an hour when you have hundreds of thousands of subscribers.

It takes 24 hours to update your support pack status. Make sure you have the right license key in your account.
It's been well past 24-hours. The license key is correct in my account but when trying to hit save on my profile, it says the license key is already in use by someone.
 
@Lakjin - For once, try to edit /apps/common/components/db/behaviors/CampaignQueueTableBehavior.php and look for 500 and replace it with a higher number.

For anyone looking to do this, its line 151 as of v1.4.1 -- simply change

Code:
$limit     = 500;
to whatever you want, for example
Code:
$limit     = 5000;
 
@twisted1919 another potential bug or unintended way of working: when temp queue tables are enabled, a new campaign will NOT start while another campaign has PCTNL lock. It looks like temp queue table feature needs PCTNL lock to create temp tables and put subscribers in them, and campaigns are stuck until they can get it.

While I don't mind only one process creating temp tables and putting subscribers in them (since we can speed up that process by changing $limit), I do mind campaigns not being able to run because another campaign is running. Absolutely need the ability to run multiple campaigns at a time.
 
@twisted1919 solved (c). I had applyFilters instead of addFilter in the extension. Now it works. (a) is still a problem, though. Your code...

Code:
        if (!empty($server)) {
            if ($server->type == 'elasticemail-web-api' || preg_match('/smtp(\d+)?\.elasticemail\.com/i', $server->hostname)) {
                $_unsubscribeUrl = sprintf('{unsubscribe:%s}', $unsubscribeUrl);
            }
        }

        // other urls
        if (self::getIsTagUsedInCampaign('UNSUBSCRIBE_', $campaign, $content)) {
            $searchReplace['[UNSUBSCRIBE_URL]']         = $_unsubscribeUrl;
            $searchReplace['[UNSUBSCRIBE_LINK]']        = CHtml::link(Yii::t('campaigns', 'Unsubscribe'), $unsubscribeUrl);
            $searchReplace['[DIRECT_UNSUBSCRIBE_URL]']  = $unsubscribeUrl . (!empty($subscriber) ? '/unsubscribe-direct' : '');
            $searchReplace['[DIRECT_UNSUBSCRIBE_LINK]'] = CHtml::link(Yii::t('campaigns', 'Unsubscribe'), $unsubscribeUrl . (!empty($subscriber) ? '/unsubscribe-direct' : ''));
        }

Seems like it should work, but it doesn't. Is there a difference with how [UNSUBSCRIBE_URL] is replaced when sending test email vs actual campaign? The code works when sending test email, but not when sending actual campaign.

Also, I mentioned this in my OP but to make it more clear -- EE now required address tag, so it would make sense to replace MailWizz address tags with EE tags, if EE is being used. See https://elasticemail.com/support/us...-compliance-merging-profile-physical-address/

EDIT: Also, please note, the EE tags should also be inserted in welcome emails, subscription confirm emails, etc.
 
Last edited:
@twisted1919 solved (c). I had applyFilters instead of addFilter in the extension. Now it works. (a) is still a problem, though. Your code...

Code:
        if (!empty($server)) {
            if ($server->type == 'elasticemail-web-api' || preg_match('/smtp(\d+)?\.elasticemail\.com/i', $server->hostname)) {
                $_unsubscribeUrl = sprintf('{unsubscribe:%s}', $unsubscribeUrl);
            }
        }

        // other urls
        if (self::getIsTagUsedInCampaign('UNSUBSCRIBE_', $campaign, $content)) {
            $searchReplace['[UNSUBSCRIBE_URL]']         = $_unsubscribeUrl;
            $searchReplace['[UNSUBSCRIBE_LINK]']        = CHtml::link(Yii::t('campaigns', 'Unsubscribe'), $unsubscribeUrl);
            $searchReplace['[DIRECT_UNSUBSCRIBE_URL]']  = $unsubscribeUrl . (!empty($subscriber) ? '/unsubscribe-direct' : '');
            $searchReplace['[DIRECT_UNSUBSCRIBE_LINK]'] = CHtml::link(Yii::t('campaigns', 'Unsubscribe'), $unsubscribeUrl . (!empty($subscriber) ? '/unsubscribe-direct' : ''));
        }

Seems like it should work, but it doesn't. Is there a difference with how [UNSUBSCRIBE_URL] is replaced when sending test email vs actual campaign? The code works when sending test email, but not when sending actual campaign.

Also, I mentioned this in my OP but to make it more clear -- EE now required address tag, so it would make sense to replace MailWizz address tags with EE tags, if EE is being used. See https://elasticemail.com/support/us...-compliance-merging-profile-physical-address/

EDIT: Also, please note, the EE tags should also be inserted in welcome emails, subscription confirm emails, etc.
That seems to mean one would have to open a separate account for each customer where EE is used :(
 
That seems to mean one would have to open a separate account for each customer where EE is used :(
Hmm? They allow subaccounts, if you want to run and maintain accounts for your customers. However, that has little to do with MailWizz, though -- all MailWizz has to do is insert the merge tags (e.g., {accountaddress}) in place of MailWizz regular tags.
 
Back
Top