[Work in progress] - MailWizz - 2.0

twisted1919

Administrator
Staff member
Hello everyone,

As announced in the past, we started working on MailWizz 2.0 for a while now.

Our main concern for MailWizz 2.0 is to make it support PHP >= 7.1 only and remove any other code which does not rely on this requirement.

We also will make sure that upgrading from MailWizz 1.x to MailWizz 2.x will be pain free, just like upgrading from any other MailWizz version, in other words all the changes we're doing should be transparent for most of the people.

We will post the progress in this thread so that anyone that extended the application know what to expect for the upcoming big MailWizz release.

Please remember that we will continue to support MailWizz 1.x even after the release of Mailwizz 2.x, so there's no need to worry about this for now.

Here's the current notable changes in MailWizz 2.0 so far:
Code:
We now require PHP >= 7.1.13 for the app to run properly. 


1. Most of the code is now using typed params and return types. 
  Instead of `public function abc($text, $intNum)` you'll see: `public function abc(string $text, int $intNum): string` 
  This means you have to edit any code that extends core functionality and make sure the method declarations are compatible. 
 
2. All extension dependencies were moved in the app main composer.json file, no more specific composer.json
    for each extension which would generally cause issues and conflicts between the libraries.
   
3. We're using composer now, so all libraries are versioned and stored in the `vendor` folder.
    The old `apps/common/vendors` folder is only used for libraries that aren't available via composer.
 
4. We have added a set of shortcut methods for easier access for the app components. 
    Here's a small table: 
    `Yii::app()->` becomes `app()->` 
    `Yii::app()->assetManager->` becomes `assetManager()->` 
    `Yii::app()->hooks->` becomes `hooks()->` 
    `Yii::app()->urlManager->` becomes `urlManager()->` 
    `Yii::app()->request->` becomes `request()->` 
    `Yii::app()->notify->` becomes `notify()->` 
    You can look into `apps/common/components/utils/functions.php` to see all the shortcuts. 
    We recommend using these shortcuts from now on as it makes things easier to read.
   
5. Instead of `Yii::t()` we advise using `t()`. 

6. Generally we used to access the app options via `Yii::app()->options->get('category.key')` even for option categories
    that had model classes, for example, to get the site name, we would `Yii::app()->options->get('system.common.site_name')`. 
    We added getters for most of the option models properties, so we advise
    using things like `(new OptionCommon())->getSiteName()` instead. 
    If the option isn't part of a model, you can access it with `options()->get('category.key')`. 
   
7. Application params used to be accessed via `Yii::app()->params['some.param']`. 
    We advise using the `app_param('some.param', 'defaultValueOptional')` instead. 
    There's also `app_param_set($key, $value)` to set a param and also
    `app_param_unset($key)` to unset a param. 
   
8. Since we're using types params for methods/functions, if a method signature accepts strings,
    make sure you pass strings to it, if it accepts ints, pass it ints, and so on. 
    Use type casting if needed, i.e: `$this->abc((string)$text, (int)$num)` 
   
9. CSV parsing will only be done using `league/csv`, see https://csv.thephpleague.com/ 

10. Generators will be used as much as possible when loading data in batches from database, namely
    methods like `getModels()` which used to be called in a `while` loop.
   
11. We added model collections, see `apps/common/models/collection` which return an
    instance of `\Illuminate\Support\Collection`, see https://laravel.com/docs/6.0/collections 
    Which can be used like: 
    ```php
    CampaignCollection::findAll($criteria)->mapWithKeys(function(Campaign $model) {
        return [$campaign->campaign_id => $campaign->name];
    })->all(); 
    ``` 
    This is the desired way to manipulate arrays. 
   
12. Database charset has been changed to `utf8mb4`. 

13. Handling scripts from controllers will be done via: 
    `Controller::getPageScripts`, `Controller::addPageScript`, `Controller::addPageScripts` 
   
14. Handling styles from controllers will be done via: 
    `Controller::getPageStyles`, `Controller::addPageStyle`, `Controller::addPageStyles` 
   
15. Unit tests were added for most of the code base. 

16. Acceptance tests were added for most used routes. 

17. Use `html_encode($text)` when echoing content. 

18. Use short array syntax (`[1, 2, 3]`) instead of long one(`array(1, 2, 3)`).

19. The `extensionMimes` component, which is an instance of `FileExtensionMimes` now uses `ralouphie/mimey`
    to load much more mimes by default, then we add our mimes over those. 
    The calls to the component remain unchanged: `app()->extensionMimes->get(['png', 'jpg', 'jpeg', 'gif'])->toArray()` 
   
20. Removed all calls to ini_set('max_execution_time', '...') and set_time_limit() and ignore_user_abort()

21. Removed PHPMailer from the app.

22. Remove any attempts related to setting the memory limit of the app.

23. Customer suppression list import/export has been improved and it's about ~300% faster.

24. Email Blacklist import/export has been improved and it's about ~300% faster.

25. Removed `AppInitHelper::makeRemoteRequest`, `AppInitHelper::simpleCurlPut`,
    `AppInitHelper::simpleCurlGet`, `AppInitHelper::simpleCurlPost` 

26. All remote http calls are now made via `GuzzleHttp\Client` 

27. AllListsSubscribersFilters now uses generators and collections to complete the actions

We will add to the above as we progress.

Again, please note that MailWizz 2.0 is not about new features, it is about bumping up the php version and improving the existing code so that we can then easily add more features to the app.
 

OHWO

New Member
I know you probably don't get paid a whole lot for your updates. I really really appreciate you continuing to take care of updating. Mailwizz is so incredible. The more I test it, the more I love it.
 

twisted1919

Administrator
Staff member
Oh...considering PhpMailer is 2.6 times faster than SwiftMailer...this is sad "news" :(
Any options to keep it?
Unfortunately no, the PHPMailer team has taken some weird decisions like the fact we can't force the return path header anymore, etc.
Also, it's complex to maintain two mailers, time consuming to troubleshoot issues, etc.
It will be better with only one.
 

frm.mwz

Well-Known Member
hi, you set up my system for me but it stopped working, can you please email me at bowlingleagueguy1@gmail.com, am a paying customer.
Replied to your PM.
BTW, that must have been a looong time ago, like over a year, maybe two...considering all updates/changes in system, MailWizz, and third party softwares, it is a wonder it did not stop working before...and there is no warranty for such a long time. But if you reply via Skype, I can have a look into it.
 

frm.mwz

Well-Known Member
Unfortunately no, the PHPMailer team has taken some weird decisions like the fact we can't force the return path header anymore, etc.
Also, it's complex to maintain two mailers, time consuming to troubleshoot issues, etc.
It will be better with only one.
Since receiving servers ignore the return path so oft anyway, and there is no RFC that requires them to respect it, it is no wonder the phpmailer team has abandoned the old option. And since PhpMailer is 2.6x faster than SwiftMailer, it is important to keep PhpMailer within MailWizz, and rather get rid of SwiftMailer, which is not RFC compliant. If someone has their system setup that it required a forced return path, then it might be worth rethinking such setup, since it is bound to fail oft.
Plus, I appreciate all efforts re complexity :)
 

twisted1919

Administrator
Staff member

paul_ddm

New Member
Awesome news @twisted1919, and big congrats!

One question about 2.0: is there any further news about changing the way you work with multiple list campaigns? I notice in another post, this was possibly going to be changed in 2.0 to remove the need to merge the lists.

I simply ask because we notice the merge process seems to be quite slow on large lists, and the effect of duplicated subscriber rows is massively increasing the amount of data in the subscriber & field tables, and the duplicated merge lists in the list screen is a little confusing for our marketing staff!

Keep up the good work, the software is great.
 
Top