Much work has been happening since we released Mautic 4 just over a year ago, to prepare for our next major update.

What follows is an update on how we’re getting on with that process, and what you can expect as a Mautic user as regards timelines and new features.

tl;dr

Mandatory upgrades

Symfony 5 support

Mautic uses several different tools ‘under the hood’ which we have to keep up to date, and the biggest of these is Symfony, the framework that underpins Mautic. Symfony has a regular release schedule just like Mautic, and as a result we have to keep up with that and implement support for new releases in Mautic.

Image

Mautic 5 will ship with Symfony 5 support, and we are very nearly complete with the work that needs to be done in this area, which we are tracking under https://mautic.atlassian.net/browse/TPROD-248. 

We recently crowdfunded $4,000 to support a contractor working through a large part of the outstanding tasks where we could not find community contributors to work on. This work has just been started and is expected to be concluded by the end of October.

As soon as this work is completed we will be able to test Mautic with Symfony 5, and fix any outstanding issues.

We aim to have this completed by the end of November, with a view to making a testable alpha release at that point. We are aiming for a Release Candidate in December, with General Availability in January 2023 assuming the support from the community with testing and reviewing.

If the work proceeds faster than expected (which you can help with, by joining us on Fridays to help with testing!) we may also consider whether we can jump two versions, and include support for Symfony 6 with Mautic 5.

The revised release schedule can be found below, and is always available on the Releases page.

PHP 8.1 support

We were not able to implement support for version 8.1 until Mautic 5, because it requires some changes which break backwards compatibility. The work to introduce support for 8.1 will necessarily mean that we no longer support the outdated version, 7.4, as we only support the latest two minor versions of PHP. 

This work will commence as soon as we have completed the work for Symfony 5 support, because it is dependent on several aspects of that work.

We aim to have PHP 8.1 support included in the alpha release at the end of November.

New features

Mautic 5 will ship with some new features:

Contacts

• Allow exporting of stage with contact exports
• Show contact’s engagement statistics on their profile (Total sent, Open rate (OR), Click-through rate (CTR), Click-to-open rate (CTOR))
• Show contact created and modified date on profile

Campaigns

• Use stages as a condition in Campaign Builder

Segments

• Showing a segment dependency tree to identify optimization opportunities in your segmentation
• Several substantial performance optimizations for building segments

Emails

• Replace Swiftmailer with Symfony Mailer (3x faster message sending, and no more cron jobs for sending messages!)
• Prevent duplicate sending of segment emails when a send is already in action
• Addition of dropdown in editor for inserting Mautic tokens into the GrapesJS builder

Forms

• Allow formatting of help messages on Forms with HTML

Landing pages

• Configure a success message when preference center options are updated

Reports

• Filtering reports by tags
• Reports based on devices used

Webhooks

• Several substantial performance optimisations relating to the processing of the Webhooks queue

Potential features

More features may be added over the coming months, if we have help to test them. Some examples of features waiting for review include:

• Ability to anonymise exported data https://github.com/mautic/mautic/pull/11535
• Additional configuration of web push notifications to include image, badge and icon settings https://github.com/mautic/mautic/pull/11395
• Allow cc, bcc and attachments on direct emails to Contacts https://github.com/mautic/mautic/pull/11297
• Add token support for SMS https://github.com/mautic/mautic/pull/10779
• Add support for SMS callback with read and received notifications https://github.com/mautic/mautic/pull/9952
• Management of multi-companies https://github.com/mautic/mautic/pull/10817
• Improvements to the Preference Center https://github.com/mautic/mautic/pull/10579
• Segment membership change webhook https://github.com/mautic/mautic/pull/10511

Anybody who uses Mautic can help with testing these features, and developers can help with doing code review. Read more in our Community Handbook, and if you can join us on Fridays that is the best time, as we have a community contribution event every week - just head to Slack (get an invite at https://mautic.org/slack) and join #t-product.

A note for developers

As we have been working with the release process since Mautic 3, we have been refining our workflows. We have made a change to help with improving the stability of releases and prevent bugs slipping in as a result of merging changes from one branch to another.

The basic principles:

Assuming a = current major release, b = current minor release, c = upcoming major release

At the present time, a.b = 4.4, c.x = 5.x

• Features and bug fixes should always made against the c.x branch in the first instance - for example 5.x
   
• Bug fixes that need to be released into a minor or patch release should ALSO be made against the current minor release branch a.b - for example 4.4, in addition to being made on the c.x branch
  • This means creating a duplicate PR - we know it is an extra step, but:
     
    • This helps to prevent bugs with complex merges of minor to feature branch (often having over 100 conflicts to be resolved)
       
    • This means that the correct environments for the unit tests with the appropriate PHP and MySQL versions can be run at the point where you create the PR, and you can address any issues right away
       
    • This means that your bug fix will be tested in both versions, not just one and hoping it works in the other (which has led to several bugs recently).
       
    • This means we should be able to merge your PRs much faster and with greater confidence.

We know that this is an extra step, however doing this when you create the PR significantly reduces the possibility of bugs and helps us to move faster with making releases.