code – Mautic https://mautic.org World's Largest Open Source Marketing Automation Project Wed, 25 Jun 2025 14:46:56 +0000 en-US hourly 1 https://wordpress.org/?v=6.8.1 https://mautic.org/wp-content/uploads/2024/10/iTunesArtwork2x-150x150.png code – Mautic https://mautic.org 32 32 Recognizing Mautic Code Contributors https://mautic.org/blog/recognizing-mautic-code-contributors Wed, 13 Dec 2017 13:58:50 +0000 https://www.mautic.org/recognizing-mautic-code-contributors/ Originally published at dbhurley.com.

Recently I decided to do a little digging into Mautic’s contributor logs to see who was doing big things when it comes to Mautic’s marketing automation code. I also wanted to compare how we compared 2016 to 2017 since we’re fast approaching the end of 2017. It seems hard to believe that we’re almost ready to close the book on another year!

I thought the best thing to do would be to look at a variety of stats first comparing different metrics between last year and this year. One thing that I believe is very important to mention at the beginning before we start looking at specific numbers is how much of Mautic community growth can NOT be measured by a number or a specific number of lines of code. The following metrics simply report on one aspect of the overall community and should in no wise be considered indicative of the community as a whole (good or bad). The code aspect is merely one facet of our community.

Number of Developers

The number of developers contributing code to Mautic can be viewed in several different ways so I’ll share a few of them and let you draw your own conclusions.

2016_2017_code_contributions

This first graph shows the growth of developers and reviewers over the past two years. As you can see we have a steady increase in the number of “contributors” over the past 24 months. This time period covers Mautic versions 1.2 through 2.11 and does not include the month of December of this year, 2017. There are significantly more reviewers than developers but this is expected and both are still considered contributors as Mautic requires reviews to be done before a pull request can be merged. The Mautic company is identified by the dark grey in the chart as well. You can see that although proportionally Mautic the company (MCO) contributes the greatest number of developers than other companies there are increasingly more and more months developers and reviewers from the community.

There is an important side note that should be considered when reviewing the number of contributors and the relationship between MCO engineers and community developers. The amount of code contributed by MCO engineers comprises approximately 82%. This means that although the number of developers in the community is increasing MCO is still the largest single contributor by a significant amount.

But just to give a bit more recognition I’d like to share a specific list of the top 20 individuals who have contributed code to Mautic in the past year. This list isn’t exhaustive; there are many more (as the stats above demonstrate). But these individuals deserve a special specific callout for their work. Here is a list of the top 20 individuals and the number of lines of code they have contributed to Mautic.

 

But code contribution is more than just lines of code. (I’ll be the first to suggest that the number of lines of code may be a terrible metric for judging activity…more on that later). So here is a second list. This list recognizes the top 20 individuals and the number of merged pull requests to the Mautic code. Again, they each deserve recognition for their contributions.

Comments & Pull Requests

The second chart I would like to share with you is in relation to the overall comments and pull requests that the Mautic codebase has received over the previous 24 months.

2016_2017_pull_requests_comments

This chart highlights the pull requests (in red) and the comments (in blue) as they have occurred since January 2016. Here again we see a gradual increase in contributions (trend lines added). As you would expect the amount of discussion surrounding code contributions increases over time and there is a gradual increase in the number of pull requests submitted as well. Peaks typically correspond with the various release dates of the Mautic code.

Code Comment Growth

The next chart demonstrates a comparison between comments on code between last year and this year (again keeping in mind that this year we are not showing data from the month of December).

2016_vs_2017_comments

I share this chart because it signifies the engagement aspect from the community. Again, comments and involvement increases around release times as you would expect, but the overall trend line demonstrates increased discussion occurring around the code over time.

Of course all of these charts above are specifically related to the pull requests submitted and as a result there is a significant portion of the contributor engagement that is not represented by these charts. The reason for this lies in the feature request section of GitHub. Feature requests are ideas generated by the community for future consideration within Mautic. Because they are not associated with a specific pull request they do not show in the above stats.

Current Code Status

Let’s now take a look at our current GitHub status and repositories and draw some conclusions about where we have come and where we are going to go from here. This is also a chance to identify ways we need to improve processes and new areas of focus for 2018.

Currently in GitHub there are 726 issues and 103 pull requests. Breaking the issues down further we have the following stats:

  • 321 issues marked as Bugs
  • 308 issues marked as Feature Requests
  • 171 issues marked as Backlog
  • 98 issues not labeled
  • 20 issues marked as Pending Feedback

There are several conclusions we can draw from this. First, because we use GitHub for our bugs and feature tracking there is a slight skewing of perception when viewing the open issues on Mautic. Instead of there being almost 730 “bugs” in Mautic code, it is better to view this list with the appropriate filter applied. When you do this you’ll find that the relationship of bugs to pull requests is much closer to a reasonable ratio with 1 pull request existing for every 3 bugs.

The second item that is a problem for Mautic is the 98 issues that are currently unlabeled. This means someone has written up an issue but it has not been reviewed by anyone with appropriate permissions for applying a label. This is a problem. There are two possible explanations. Either we don’t have enough active community members monitoring the GitHub repositories to mark new issues with the appropriate labels or we don’t have enough community members with the knowledge to apply the appropriate labels and therefore they don’t add them.

Side Note: There’s also the problem presented by GitHub repositories and permissions that allow or disallow access to label creation and application of those labels. This is something Mautic has not yet solved successfully.

In the future we need to educate community members on reading and assigning labels to issues so that they can be correctly categorize as they are created. We also need to determine the number of community volunteers actively monitoring GitHub repositories. One of the first ways we can determine this number is by looking at the number of reviewers we saw in the charts earlier. This number gives a suitable estimates of those contributors capable of responding to issues and therefore also capable of attaching labels to issues.

There are several advantages to correctly categorizing issues. With proper categorization we can more readily identify which bugs need to be resolved first and which are feature requests instead of actual bugs. This will increase productivity from the developers writing pull requests as well as clarify public understanding of the project’s status.

Lastly, from the list of issue stats we can see that there are a significant amount of feature requests. We can draw a conclusion or two from this metric as well. Feature requests can mean the software is not completely fulfilling everyone’s ideal marketing solution (though this is a more delicate issue as Mautic should never attempt to be all things for all people). More importantly the relationship between number of feature requests submitted and number of pull requests submitted suggests that the community is made up of more end-users (marketers) or implementer types of users rather than coders or developers. In fact, when we take this ratio and compare it to the downloads from Mautic.org of the software we find a fairly similar breakdown of user types. This means the assumption we draw from the feature request submissions is accurate.

Understanding the make-up of our community when it comes to the Mautic code helps us to continue making improvements and growing. I hope that as you have read through this you’ve been able to get a better understanding of how I look at things and what the different metrics you might see or hear actually mean. Once we have a shared understanding of how to look at the Mautic codebase we will have a greater opportunity for moving faster.

]]>
Tracking Visitor Data by Smart URL https://mautic.org/blog/tracking-visitor-data-by-smart-url https://mautic.org/blog/tracking-visitor-data-by-smart-url#comments Thu, 17 Aug 2017 13:49:58 +0000 https://www.mautic.org/tracking-visitor-data-by-smart-url/ We’re excited to continue sharing content developed by the Mautic community.

Have you ever wondered if you could track more than just visits via the Mautic tracking script? I know I did, and in this article I will show you how we can use URL’s to track anything you want.

The Basics

Before we start let’s have a look at these two URL examples. This one is without extra parameter:

https://mydomain.com/page/test/

And here we have the same URL with an extra parameter:

https://mydomain.com/page/test/?email=johndoe@company.com

If you use for example MailChimp or CampaignMonitor to send out marketing emails, consider using this technique. Simply add the email address as a parameter at the end of the URL.

In php one can catch this parameter simply with a:

$email = $_GET[‘email’];

And then proceed to use that parameter for processing. However, there is also a clever way of using the Mautic Javascript to track visitors on your site. Only some slight modifications can make it send off any lead field you want to Mautic.

Get Tracking with Mautic

Here is the default script:

<script>
    (function(w,d,t,u,n,a,m){w&#91;'MauticTrackingObject']=n;
        w&#91;n]=w&#91;n]||function(){(w&#91;n].q=w&#91;n].q||&#91;]).push(arguments)},a=d.createElement(t),
        m=d.getElementsByTagName(t)&#91;0];a.async=1;a.src=u;m.parentNode.insertBefore(a,m)
    })(window,document,'script','https://mydomain.com/mtc.js','mt');

    mt('send', 'pageview');
</script>

In short, what this does is simply pass along the identification parameters such as IP address and device fingerprint, together with the page the user is visiting. Now have a look at the script below.

<script>
	function getUrlParameter(name) {
		name = name.replace(/[[]/, '\[').replace(/[]]/, '\]');
		var regex = new RegExp('[\?&]' + name + '=([^&#]*)');
		var results = regex.exec(location.search);
		return results === null ? '' : decodeURIComponent(results[1].replace(/+/g, ' '));
	};
	
    (function(w,d,t,u,n,a,m){w['MauticTrackingObject']=n;
        w[n]=w[n]||function(){(w[n].q=w[n].q||[]).push(arguments)},a=d.createElement(t),
        m=d.getElementsByTagName(t)[0];a.async=1;a.src=u;m.parentNode.insertBefore(a,m)
    })(window,document,'script','https://domain.com/mtc.js','mt');

	var email  = getUrlParameter('e');

	if(email !== ''){
		mt('send', 'pageview', {email: email});
	} else {
		mt('send', 'pageview');
	}
</script>

The first function is used to extract a custom parameter from the URL. You can use this function for any parameter you want. Just make sure to pass the correct name to the function. In our case the name is ‘email’.

Below that you can see the default part of the Mautic tracking script. This is not relevant for us. It does what it needs to do, no need to concern us with that for now. Below that you will see a new variable is created with the name ‘email’ and the value it will get is the URL parameter for ‘email’. This means that this variable will hold the content of the URL that comes after ‘?email=’, which should be the email address of the user.

Then we have a short if-statement. This statement simply checks if the email parameter is filled or not. If it is not (which is the case for people that visit your website without a newsletter link) it will simply pass along the usual parameters. But if the email parameter is present it will pass along the usual parameters together with the email address.

Sending a Custom Parameter

You can send this along by adding ‘{email: email}’ to the mt method. Keep in mind that the first string identifies the field you want to pass along. In this case we want to pass along the email, but this could also be any other field like firstname or lastname, or even a custom field you have created. The second string or value is the actual value that needs to be passed along. Since we put the value we got from the URL in the ‘email’ parameter we just write ‘email’ to indicated that we want to pass along the string inside this value.

Lastly, make sure you enable public updating for the fields you want to track using this method. If public updating is not enabled Mautic will simply drop the field. You can do this by going to the ‘Custom fields’ section, then selecting the field you want and changing ‘publicly updatable’ from ‘no’ to ‘yes’.

Congratulations! You can now track custom parameters on your website!

The Possibilities Are Endless

Using the Mautic tracking script this way opens up new ways to identify your contacts. Think about the contact points you have and how you can use them to track different data sets.

If you are using mailing tools like Mailchimp or CampaignMonitor it is super easy to add the add extra parameters to your newsletters. Simply append the extra parameter to all the URL’s in your mail and there you go! In fact, you can use any contact network on point you have and use this methods for the parameters at hand.

Security

We should not forget that we are still handing personal data here. If you are appending sensitive data to a URL make sure you think about handling the data safely. What you could do is hash the parameters and de-hash them in your website before you send them off to Mautic. This way anyone who might come across the link cannot read or use the parameters.

Also make sure to use https, also known as SSL if possible. This is simply an extra layer of security added to the request the user will make. Best practice is to use both SSL for your website as well as the connection between your website and Mautic. You will see in the examples above the I have used https in the code, and not http.

And there you go. Now you know how to track custom parameters with the Mautic tracking script. I cannot wait to see what creative ways you all come up with to use this!

]]>
https://mautic.org/blog/tracking-visitor-data-by-smart-url/feed/ 1
How to Create a Mautic Plugin: Step 2 https://mautic.org/blog/how-to-create-a-mautic-plugin-step-2 Tue, 08 Sep 2015 16:12:42 +0000 https://www.mautic.org/how-to-create-a-mautic-plugin-step-2/ In our previous article we began looking at creating your own Mautic plugin to integrate a third party software with your awesome new open source marketing automation software (yes, Mautic). In this lesson we’ll continue to create a Mautic plugin, but first as a very quick review, in our last tutorial we started with a basic introduction to plugin creation. Remember we started with planning a plugin, examining the third party API, and looking at the developer resources provided by Mautic. If you want to read more you can check out the previous article and then come back here when you’re ready.

This second tutorial in creating your Mautic plugin we will start looking at the specifics of some of the files we’re going to write and how we take advantage of both the Mautic API and third party API calls.

Basic Files

There are several basic files we need to write to have our plugin registered within Mautic. We created the files in our last tutorial and this graphic shows them to you again.

 


Create mautic plugin file structure

 

The files we are going to focus on today include the config.php file, the MauticDeskBundle.php, and FormSubscriber.php. These are the quickest of the files and so we can cover them quickly. The other files you see in this screenshot are more specific to this particular integration and they will be covered in the next tutorial. For now let’s look at these first three files in more detail and line by line.

config.php

This first file is the config file which Mautic will use when loading the plugin into the system. In this file we are going to name our plugin, provide a description, version and author. Then we need to define the services we want our plugin to use. Here’s the file:

Services: The services are broken into two types, events and forms. Events are those items which you want to trigger as a result of some action within Mautic. Forms are the functions and calls to run when a form is loaded within Mautic.

e.g. Real-life, the form services will allow your plugin to collect more information from forms within Mautic from the business user (not the site visitor).

The Desk plugin that we are writing will need both an event service and a form service. We’ll dig into each of these services later but notice that the class defined for each of these services is the path to the associated file.

MauticDeskBundle.php

This file is the root file that can be used when extending the Plugin base class. In this plugin we do not need to extend anything so the file below is merely a holding file that routes everything to the Plugin Base parent class.

FormSubscriber.php

This file is associated with the event service we defined earlier in our config.php file. This FormSubscriber is the event that gets triggered based on some action within Mautic. Let’s look at the file and then break it down.

Namespacing and used classes are the first thing you’ll find in the file. Here we define what we’ll be using or referencing later in the file.

This class, FormSubscriber, extends a CommonSubscriber class available for all plugins.

The public function onFormBuild accepts a parameter of the FormBuilderEvent (as you can see type-hinted). Here we define the action for this particular service event. We will create the group, description, label, formType, formTheme, and callback function that we want triggered by this submit action. Lastly we add the submitAction to the event.

In this array of actions we have a few special key-value pairs to mention. First, the formType defines the configuration or parameters your plugin will have as part of the plugin configuration fields. (Don’t worry we’ll return to this later when we look at the form service and the plugin configuration).

The callback defines the location and the function you want to be called when the event is triggered.

Don’t let the formType confuse you, at this point in the process, it’s best to consider this merely a way for your admin configuration settings to be added to your plugin when it’s triggered.

Next Step

The next piece in the plugin tutorial will be to focus on the admin configuration for your plugin (see, it’s coming together) and then explore how the triggered response is pushed to the third party. This plugin may be a short series but will add great functionality. I expect after this tutorial series you will have no problem taking this example and building your own plugins easily to push Mautic data to other systems, the Mautic API is a great way to integrate open source marketing automation with everything else.

]]>
How to Create a Mautic Plugin: Tutorial Series (Introduction) https://mautic.org/blog/how-to-create-a-mautic-plugin-tutorial-series-introduction Wed, 05 Aug 2015 12:26:05 +0000 https://www.mautic.org/how-to-create-a-mautic-plugin-tutorial-series-introduction/ We continue to push the Mautic free marketing automation software to be bigger and better than anything else available. A new feature coming soon to a future release of Mautic is one that we know will be extremely exciting. The Mautic Marketplace will allow everyone to share their plugins, themes, workflows, campaign templates and more. In preparation for this upcoming feature we’ll be creating a series of articles related to the development of a Mautic plugin to help you as you look to create your first Mautic plugin.

I’ll be covering how to create a Mautic plugin from start to finish in a series of posts that I hope will bring clarity and understanding to the entire process and answer any questions that arise during the process. If you get stuck I encourage you to jump into the forum to ask your questions and help others too!

Before we begin let’s look quickly at what a plugin is and why we care about creating them. With this idea of plugins Mautic functions very similar to something like WordPress. Plugins allow you to do a number of things from integrating other software systems and software tools to modifying the functionality of Mautic. Plugins let you extend Mautic however you need. This is one of the greatest benefits of an open source marketing platform like Mautic. You have full access to view the source code, examine existing plugins and improve the core by suggesting additional triggers or listener events.

Want a concrete example? A Mautic plugin might let you push data from a lead to an external CRM system. The plugin will listen for a specific action and when that action occurs will trigger an event that pushes data to some other system. Here’s a second example: A Mautic plugin might modify all your landing page URL’s and other external URL’s to use a link-shortening system (like Bitly) before they are rendered and displayed to the end user.

Ok, so that’s an idea of what a plugin might do and a couple of examples of how they might be used. I think that’s enough background. Let’s start planning what our sample plugin will do that we’re going to create together.

Step 1: Plan Your Plugin

Purpose of the Plugin

I want to create a plugin that pushes some information from Mautic to an external service. I have decided for the purpose of this tutorial series that I want to create a plugin that will let me create a form within Mautic and push the results of that form to Desk.com, a ticketing system.

At a high-level review, I am looking to create a plugin that will let me use Mautic to push support tickets into my support system but use Mautic for form collection and submission. By doing this I will be able to do a few different things. First, this will let me demonstrate how to create a plugin that needs additional configuration fields defined. Second, this plugin will add a new form action to standalone forms that will allow me to push my form submissions to some other system via an API. Third, this plugin will give me the opportunity to write a couple different listeners. And lastly, I can show some advanced techniques for field mapping.

Outline Basic Plugin Structure

Now that we have identified the purpose of our plugin this will help me to outline the basic plugin structure I want to use. Here is my basic plugin structure:

Create mautic plugin file structure

Don’t panic we’re going to look in-depth at each folder and file here through the course of this tutorial but for now we’ll just glance briefly at just a few highlights that are important to note.

Form Folder: Because I am creating a plugin that will provide additional features (fields) on a form within Mautic I will need to create a form folder and a FormFieldsType.php file which will define each of those fields. (The FormFields part of the name must match the class name but can be anything you want, and the Type part of the file name is necessary so Mautic will find and autoload this file).

FormSubscriber.php: Again, this file is named related to the class name it contains so that it will be automatically loaded by the system. I have called this one FormSubscriber to help me remember that this is a subscribed event for forms.

As with most parts of the system you will want to ensure that your naming is consistent throughout your plugin. Specifically the classname and namespace of your files as they relate to your config.php file. Don’t worry too much about this for right now as we’ll get into this in more detail in the next post.

Prepare 3rd Party API

I’m going to list this as part of the initial setup because it’s important to have this ready early on in your plugin development process. You will need to find and prepare your 3rd party API. This might involve creating an account, retrieving an API ID and API Key or similar. Basically you want to make sure when you’re ready to make an API call (later in this series) you will have everything ready to go and already setup.

For this tutorial I discovered that Desk.com uses Basic Authentication for handling interaction with their API and I simply needed to know my email address and password associated with my Desk.com account.

Following along? You can register an account here: http://help.desk.com/register (source no longer exists).

Mautic Developer Reference

In addition to the 3rd party API service and knowing what functionality is available from them you will also need to know the various endpoints, listeners, and more available within Mautic. You’ll want to keep a browser tab open with the Mautic Developer Docs loaded up. You can browse that information here: https://developer.mautic.org

Next Step

The next step after defining our purpose and looking at the basic plugin structure will be to begin writing all the necessary files to their respective folders and begin the process. We will get into this in the next article in this tutorial series.

]]>