We have heard your feedback and have decided to revamp the way we organize resources in Mautic. Our main objective is to make it easier for users like you to quickly find and collate resources related to a specific context — such as a project or a marketing campaign.

Our existing tagging interface and categorizing system have served us well, but we acknowledge that there is room for improvement. That’s why we are taking a fresh look at our categorization system to truly cater to your needs.

What’s Changing?

Over the next few months, we will undertake a transformative project that will introduce some key changes to the Mautic platform:

1. Global-Based Categories: We are moving away from entity-based categories (for instance, categories exclusive to emails, or pages) to incorporate global-based categories. This shift to a more inclusive categorizing system will provide you with greater flexibility and control over your resources (and hopefully be less confusing!)
    
2. Multiple Categories Per Entity: With this feature enhancement, you will be able to assign more than one category to a resource. This enhancement will increase the system’s versatility and allow you to better manage crossover resources – like assets which belong to multiple projects or marketing campaigns, for example.
    
3. Category Nesting: This feature will give you the power to nest categories within each other, further enhancing the tool’s organization capabilities.
    
4. Front-End View: Finally, we will introduce a new front-end view that displays the entities and sub-categories within a category in a user-friendly, intuitive layout.

We are also considering adding features in future updates, such as an archived state to remove and unpublish resources – helping to reduce server load – and offering rolled-up reporting by category.

This initiative will evolve iteratively over several months. You can track the progress at our project’s roadmap page.

Participate in Mautic’s Evolution

For those interested, we have laid out the upcoming changes in the project brief where you can also quickly find any meeting notes relating to this project. 

Issues will be created on Github in the coming weeks for developers to work on. We have also initiated a bounty fund currently sitting at $1000 for the whole initiative. You can contribute to this cause here. If you are a developer and interested in contributing, you can learn more about contributing to Mautic here, and working with the bounty programme here.

We Want to Hear from You

Your insights and feedback are what drives Mautic’s growth. As we embark on this exciting new initiative, we value your thoughts, ideas, and solutions. Please share them with us at each stage of the process, as they could potentially influence our development roadmap.

Finally, thank you for being part of the Mautic community! With your continued support and contributions, we strongly believe we can make Mautic an even better, more intuitive, and efficient platform for all users.

Over the last year the Install and Upgrade Initiative team have been working closely with the Product Team on investigating how to bring more stability to the installation and upgrade process of Mautic. We are now beginning to introduce some changes with the ultimate goal of having a rock-solid, stable install and upgrade workflow for Mautic which works as well for single Mautic instances as for managing Mautic at scale.

Coming soon

Deprecating current installation and upgrade methods

Since Mautic 2.0 we have been advising Mautic users to update at the command line, now we are going to make it a requirement.

With the 4.2.0 release of Mautic, you will start to see warnings if you are using the update feature within Mautic itself (often referred to as ‘in the user interface’ [UI]), telling you that this has been deprecated and will be completely removed in Mautic 5. 

The reason for this will be evident to anybody who has tried to use the update feature within Mautic with anything other than a test installation – during the update process, a lot of intensive tasks have to be executed which can take quite some time with a large number of contacts. This will often cause the process running on the server to be terminated due to the hosting environment being incapable of completing the tasks with the available resources. This is the number one issue where updates fail and cause Mautic to crash, leaving users extremely frustrated.

From Mautic 5, you will no longer be able to update Mautic from within the user interface, and will have to update following specific commands at the command line.

We do appreciate that for some users of Mautic, this adds an extra layer of complexity, however we believe that the benefits outweigh the many difficulties that users of Mautic experience when attempting updating within the user interface.

Improving in-app guidance to users on how to update

While we will be removing the ability to update in the user interface, we will still be alerting users when a new version of Mautic is available. There will be detailed information provided if their environment doesn’t support updating (for example if a higher version of PHP is required or plugins need to be updated), and a clear overview of what is included in the new version of Mautic.

We will be providing easy to follow, step-by-step instructions for users to follow at the command line in order to update their Mautic instance.

Composer as the supported method for installing and updating Mautic and third party plugins

Since Mautic 4.0 it has been possible to fully manage Mautic with Composer thanks to the work of the Composer Initiative, which brings Mautic in line with many other PHP applications who already use this technology for installing and updating software.

With the introduction of Composer 2, the process is even more efficient and robust, and many Mautic users have reported great success in using Composer to manage their Mautic installations.

With the removal of the UI-based upgrade in Mautic 5, we will also be switching to using Composer as the official way to install and update Mautic. This also has the added benefit of unlocking the ability to manage plugins within the Mautic Marketplace, which is dependent on Composer.

From Mautic 4.2 there is a new setting which you can enable to tell Mautic that you are managing it through Composer, which will disable the built-in updating system, and enable you to manage plugins within the Marketplace.  With this setting enabled, users will see a message warning them that they are not able to update in the user interface.

Improving documentation

With the changes above we recognize the need to improve the documentation we have available, both within the application (as mentioned above) but also in the end-user and developer documentation.

The end-user and developer documentation are currently undergoing a review, update and re-platform to Read the Docs which will enable us to maintain versioned documentation related to different Mautic versions, and to translate the documentation into other languages using Transifex. We would welcome contributors who would like to help with this task, even if you only have a small amount of time – we have lots of small tasks that need to be done. Please join us in #t-education on Slack if you would like to get involved!

We will also be greatly extending the articles we have in our Knowledgebase and moving to a more effective platform, which will enable community members to submit new articles for review, and also provide a much more intuitive experience. We hope that this will include regularly updated tutorials on how to install Mautic on all the popular hosting platforms, and the development of one-click installers.

Future plans

Automatic updates

With the changes above, we are planning in the future to enable automatic updates as a feature which can be enabled by an administrator. Bug fix releases are generally safe to update automatically as they do not include any major changes, new features or significant variations of existing features.

This will not be an option until at least Mautic 5.0, and even then, will require a Composer-managed installation due to the underlying functionality required.

Decoupling plugins and enabling selection during installation

With the changes we are making and the introduction of the Mautic Marketplace, we are planning to fully decouple plugins and integrations from the core of Mautic.

This means that when you install Mautic, you will start with the absolute basics which are required for Mautic to operate – making Mautic installations very streamlined by only including the features that you specifically need for your instance.

During the installation process, the user will be given the opportunity to select other features, functionality or integrations that might be helpful, and to install them. For example, you might want to install the plugin to integrate with your CRM system, or to use a specific third party email provider.

We have started the work on this already by separating the individual plugins out into their own repositories as part of the Composer Initiative, which are currently acting as read-only ‘mirror’ repositories.

The next steps will be to fully isolate each plugin by removing any inter-dependencies, and then to develop the experience within the installation process to include core plugins which are required, and enable the user to select from the marketplace any third party plugins they might need.

Conclusion

I’m pleased to see that we’re starting to make some headway in addressing some of the fundamental problems that people experience when they are installing and updating Mautic, and am looking forward to hearing your thoughts on our future plans for Mautic. Please do reply in the companion forum thread if you have any comments!

One of our biggest challenges currently is the large backlog of bug fixes and features which need to be tested, reviewed and approved before they can be made available in a release of Mautic.

At the moment of writing we have 247 of these, waiting to be reviewed.

Our Product Team is doing a great job working toward our target of having all new bug fixes and features reviewed and released within 30 days of being created, but we need a much more substantial effort to work through our backlog.

Open Source Friday Community Initiative

Last week, seven Mautic agencies made the commitment to sponsor members of their team to dedicate their time on a Friday to a regular weekly product team sprint, which will specifically focus on getting these older features and bug fixes ready to be released. 

These team members include developers and marketers – you don’t have to be a developer to help with testing. This Community Initiative is being led by John Linhart, Technical Community Lead.

The Open Source Friday Initiative is open to any other agencies or companies that would also like to sponsor team members to join us. Just drop us a message in #t-product if you will be joining us. If you are not yet on Slack, you can get an invitation at https://mautic.org/slack.

Every Friday we will be working together in #t-product on Slack – we are opening it as an all-day event as there are people from all timezones joining us. 

At key times during the day members of the core team will be online for help with testing or chatting through any problems which arise, these are:

• 0900-1000 UTC
• 1200-1300 UTC
• 1500-1600 UTC

We recommend using everytimezone.com to check the time in your local timezone.

Initial sponsors

Thank you to the initial sponsors for making this Community Initiative happen. These are:

• Acquia
• Webmecanik
• Friendly
• Leuchtfeuer Digital Marketing
• Aivie
• QED42
• Steer Campaign

What does this mean for Mautic users?

This means that we will be delivering more bug fixes more quickly, and also making sure that new features are tested and released in a timely manner. More bug fixes, more features and enhancements, more often.

For developers, this means that all those old PRs will finally be getting merged. Also, when you submit a pull request, we are committed to reviewing, testing and merging it within 30 days. No more endless rebasing, bumping from release to release, or having to unearth months-old contributions when we’re ready to test and merge them. It will take us time to work through the backlog and we do acknowledge that it will be a bit painful in the interim, but please do try to work with us through this process!

We have learned a lot and as a result, we are implementing a new approach to how we manage bringing new features into Mautic. Some aspects of this are based on the model used by the OBS open source project.

What are we implementing?

We are creating a workflow where community members can propose and discuss new features they would like to see in Mautic and have those ideas reviewed by the Product Team, proposed as a project to be incorporated into the roadmap, funded (where required), and eventually be released as a new feature.

This process will not impact developers who create new features and share them through a pull request for consideration by the community – that is still very much welcomed!

What is the new process?

If you have an idea for how to improve Mautic, the first step is to share your idea in the Ideas & Feature Requests forum category. Please use the post template to fully explain what the idea or feature is, who it would benefit, and why you think it should be considered. Please also state if you’re willing to help working on it.

We use the forums because this is a place where users of Mautic tend to frequently visit, in addition to business owners and developers. Having these discussions in a place which is accessible to all stakeholders is important – everybody needs to have the opportunity to get involved!

Once ideas have been discussed on the forums and accrued enough votes (suggesting community support for the particular feature being proposed), they will be considered by the Product Team during quarterly meetings with the Project Lead, and where appropriate, accepted to be included on the roadmap. This may be as a feature, but sometimes features proposed by the community may also be considered for becoming Strategic Initiatives.

The Product Team will work with the originator of the idea to put together a Request for Proposals (RFP). The Product Team will determine how much of their budget will be allocated to the project and whether any further funds will need to be raised in order to compensate contributors for their time working on the project.

Once the RFP has been finalised, it will be published on the GitHub project under the Discussions section.

If the funds have been secured it will be immediately set to the status of Accepting Proposals with the label of ‘Bounty’ to indicate that it is a funded project, if additional funding needs to be raised this will be achieved through a project on the Mautic Open Collective and the RFP will be set to Fundraising. See an example below of this in action:

Proposals can be made either by individuals or teams of developers working together or as a company, but the final payout will be made to only one stakeholder who would distribute the funds if more than one person contributes toward delivering the project. All individuals and organisations will remain responsible for managing their own tax concerns in their locality and this does not constitute a contract of employment.

See an example of an RFP in progress with the OBS project here: https://github.com/obsproject/obs-studio/discussions/5078.

Sometimes it may be necessary after opening the RFP to raise more funds if a proposal favoured by the Product Team requires in excess of the funds that are currently available – this will be done through a tier on the Open Collective and the RFP will be set to Fundraising until the full amount has been raised.

The Product Team may also decide to use an RFP for particularly large bug fixes or problems which need to be addressed promptly but need to have a detailed interaction with the developer proposing to address the issue, allowing them to clearly outline what is required in the project. Examples of this include fixing and updating the Twitter integration.

As with bounties, there is no compromise on quality – pull requests for new features must meet all the usual requirements of code coverage, review by the Core Team and testing in the community before they will be considered as delivered and ready to be incorporated into the next feature release of Mautic.

The full workflow of how an idea becomes an RFP and eventually a new feature in Mautic can be found in the Community Handbook. We will continue to review and refine this process as we start to include more projects, and look forward to welcoming developers to work on these projects.