Our second year of running the event, we welcome everyone interested in deepening their knowledge of Mautic and joining our vibrant community. Whether you’re a developer, marketer, technical writer, or simply curious about Mautic, this is the perfect opportunity to dive into the world of this outstanding open source marketing automation platform.

What to Expect

The event kicks off on the first day with a comprehensive introduction to Mautic during a training session. This session is tailor-made to provide a solid foundation for individuals new to Mautic, ensure you’re up to speed, and ready to unlock its full potential. Don’t miss this chance to supercharge your Mautic skills!

For the subsequent two days, we have lined up an exciting schedule of community contribution sessions. These sessions offer firsthand experience in various aspects of the Mautic project, including development, testing, marketing, technical writing, community building, and event organizing. Regardless of your expertise, there will be ample opportunities for you to make a valuable impact and contribute to the growth of Mautic.

Embrace Flexibility

In recognition of the diverse Mautic community spread across the globe, we are pleased to offer a remote participation option. If you can’t make it to Vienna, you can still join us virtually from anywhere. We want to ensure that every member of the Mautic community has the chance to participate and contribute, no matter their location.

Several of our team members will be contributing remotely so we will have mentors available both in-person and online to get you started.

Mautic Sprint (21st-22nd) 

Kickoff: Friday 10:00 h
Please see Slack channel #community-sprint for hours and all coordination 
(Use https://mau.tc/slack-invite if you do not yet have an account for the Mautic Slack space)

Access for remote attendees: via Zoom
(Meeting ID: 875 0093 1130, Passcode: 330242)
 

What we’re going to be working on:

Community Team

• Strategy for growing local communities
• Preparations for the next in-person Mautic conference

Education Team

• Finalising work on the new developer docs (API documentation writers needed!) and end-user docs

Legal & Finance Team

• Workflows for CollectiveVoice integration for collaborative approving of expenses on Open Collective in Slack (doc & video, form to complete)
• Tooling for implementing the new governance model
• Preparing copy and workflows for the call for nominations for the Mautic Council

Marketing Team

• Preparatory work for the upcoming strategy workshop
• Content and visuals to support the Mautic 5.0 release

Product Team

• Testing the Mautic 5.0 alpha release
• Fixing bugs identified
• Writing Mautic-specific email transports for Symfony Mailer

Location

If you’re planning to join us in-person, here’s some information about the venue:

The event is happening at the University of Vienna (Oskar-Morgenstern-Platz 1, 1090 Vienna), located very centrally in the city of Vienna. The main contribution area will be in the Sky Lounge event room on the 12th floor, which includes a rooftop terrace with a panoramic view of the city!

The venue is certified for green meetings and surrounded by restaurants and well known points of interest like the Freud museum. The 1st district is just a 5 minute walk away.

Location, location, location:

• One tram station away or a 3-minute walk to the U2 & U4 Station Schottenring. Get the Wiener Linien APP on your phone or use a maps service for public transportation information.
• Important Update: As can be read here, the Vienna Public Transportation System will be doing construction on the U2 and U4 lines that will affect us during the event. 

You can read more about the venue on the DDD website.

How to Get Involved

To be a part of Mautic Developer Days and Community Sprint in Vienna, firstly make sure that you mark these dates in your calendar.

If you plan to attend in-person, please book your ticket here. (132 EUR including coffee, heathy snacks, drinks and evening entertainment)

If you plan to attend remotely, please book your ticket here. (free, but donations welcome)

We will be sharing updates on the event agenda, registration process, and logistics.

In the meantime, we encourage you to spread the word among your networks and colleagues who might share an interest in Mautic. The more diverse and engaged our community, the stronger we become.

Conclusion

The Mautic Developer Days and Community Sprint in Vienna is your gateway to immerse yourself in the world of Mautic, enhance your skills, and contribute directly to this awesome open-source project. Whether you attend in person or remotely, we look forward to your active participation and dedication.

Don’t miss this fantastic opportunity to connect with like-minded individuals, share insights, and help shape the future of Mautic. Together, we will build and improve a powerful marketing automation platform that empowers businesses around the world.

Stay tuned for further updates and get ready to join us in Vienna or remotely from July 19th to July 21st.

We are hosting our first ever Mautic Developer Days event alongside the Drupal Developer Days in Ghent, Belgium from 4-8 April 2022.

From 4-6 April we will be having short talks and unconference-style sessions in the mornings, with dedicated sprint time in the afternoon to work on a range of tasks including the Symfony 5 upgrade.

There is also the option to extend your stay for the 7-8 April which will be open sprint time alongside other Open Source communities. It’s a great way to learn more from other developers and help us to really make progress with Mautic over the week of the event.

There will also be social events in the evening where we will join with other open source projects and visit some of the attractions in Ghent, go out for dinner and generally have a lot of fun!

What will we be working on?

During the contribution sprints, we will be focusing on the following:

• Symfony 5 support
• Testing and reviewing pull requests
• Working on the Mautic Marketplace
• Improving automation of code reviews with PHPSTAN and Rector
• Reviewing new features for 4.3

Want to know more?

Check out our page here: https://drupalcamp.be/en/drupal-dev-days-2022/mautic-developer-days-2022

Tickets are 90 euro (early bird) or 115 euro after they sell out for the entire week, which includes food and unlimited tea/coffee during the event, and access to the Mautic/Drupal Developer Days events.

Please let us know if you’re planning to attend by emailing ruth.cheesley@mautic.org.

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.

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.

• • alanhartless*, 91179
  • escopecz*, 55362
  • dongilbert*, 39954
  • mqueme*, 33581
  • stollz, 22008
  • virlatinus*, 20850
  • GaberNeighbor*, 12113
  • Maxell92*, 10950
  • kuzmany, 6768
  • thecodeine, 5525
  • drmmr763*, 5287
  • npracht, 3783
  • MarkLL, 2541
  • mikegillis677, 2309

• Woeler, 1546
• shulard, 1439
• jordan8037310, 964
• isleshocky77, 750
• lightweight, 678
• Dreiser*, 634

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.

• alanhartless*, 628
• escopecz*, 390
• mqueme*, 150
• dongilbert*, 98
• kuzmany, 83
• virlatinus*, 76
• mbabker*, 37
• MaxWebmecanik*, 27
• drmmr763*, 23
• Dcoutelle, 18
• isleshocky77, 16
• arulrajsm28, 12
• phil-davis, 11
• shulard, 11
• SamWebmecanik, 11
• chandon, 10
• jordan8037310, 9
• Woeler, 9
• npracht, 9

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.

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).

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.

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!

The business is an interesting collection of talented individuals. They’re comprised of educators, strategists, programmers, artists, designers and more. The variety of talent gives them an advantage over their competition. But more importantly, their collaboration creates innovative solutions for their clients.

The solutions they produce are highly visual in nature. These large images help communicate strategy so that employees can understand the “big picture”. Associates can then have a dialogue with their peers about important, strategic issues. The visuals unlock understanding, that words so often, can not.

The Team

The outcome of these engagements were often riddled with “a-ha” moments. They are moments when an employee would stop and say “I get it!”. The visuals provided a much clearer picture than a presentation filled with bullet points. But the visual isn’t born out of thin air. It takes a close partnership between the business strategist and the creative artist.

The development of these visuals always begins with the problem. It starts with the team sitting down with the client and listening to the challenges they face. Each team member hears the problem from their own point of view. These unique perspectives add immense value to the solution. In today’s marketplace, the collaboration between marketing and software development teams will become invaluable. This partnership can spark innovation and will be more powerful when they work together. And as marketing continues to move online, development must have a seat at the table. They will play a vital role in growing the customer relationship.

The Collaboration

This partnership between the artist and the strategist is important. Even though their views are different, the goal of engaging associates is the same. Likewise, the collaboration between technology and marketing is critical. These two functions have operated in silos. They are focused on their own goals, without consideration for the other.

The collaboration between marketing and software development will become invaluable and more powerful when they work together.

The collective reset button needs pressed. Teams should tear down their silos and realign on the purpose and goals set out by the organization. What is that purpose and goal? Creating seamless user experiences that add value at every stage of the customer relationship. Media buyers used to operate in lock step with marketing, and many still do today. They work together to understand how customers buy products. But communication channels are changing. Digital is now how we reach and connect with our audiences. Many organizations must work to help teams come out of the dark ages. They must forge bridges of awareness and understanding.

The Approach

So what approach do we take when aligning marketing and development? Marketing automation is a perfect place to start. These two teams must converge to meet today’s customer demands. Just like the artist and the strategist, aligning around the common goal is where we start. People would always wonder how an artist and strategist could work together. With a common goal, these two different views always produced incredible results.

Let’s take a moment to reflect on the roles of marketing and software development. Although unique, they are two sides of the same coin. How does this collaboration work effectively?

• Listening: Strong developers and designers always begin by listening. Both these roles need a thorough understanding of the problem. This understanding is important before thinking through the problem and crafting the solution.
• Design: Any approach to solving a problem requires a big picture view. This view reveals all the elements that may impact the desired solution. Trusted marketers understand the entire customer experience and likewise, trusted developers are focused on creating structure and order in their code.
• Focus: Good marketing and design requires simplicity. There should be one single theme or idea. Great developers create beautiful code that works well with as little “extra” fluff as possible. This focus removes clutter and aligns our efforts.
• Vision: One of the most important elements that developers and marketers exhibit is vision. Marketing should take into account customer buying trends and consider feedback from their audience. Developers should also look ahead. Potential problems should be identified and resolved before they become an issue.

This approach, combined with a common goal, will create more meaningful value. And at the end of the day, that is what we want for our customers.

Marketing automation is becoming a more integrated way to do business in the digital age. It’s clear that these two roles not only have common ground, but approach their work in a similar way.

We are excited about the community of Mauticians that represent both marketing and development. It has, and will continue to, provide us with the ability to meet the needs of organizations around the world. It is in this special collaboration that we can provide tools to help you reach, engage and develop relationships with your audience.

But before discussing how to contribute, let us briefly talk about Mauticians. You’ll often hear this term as you get involved in our community. Mauticians are the backbone of our community. They’re amazing volunteers who contribute their time and skills to improve Mautic. They come from diverse backgrounds and skill levels, united by a common goal: to improve Mautic.

However, this article will focus on how you, as a developer, can engage and contribute to Mautic through code contributions and pull request testers.

Whether you’re a seasoned developer or just starting out, we offer opportunities for everyone. By contributing to Mautic, you’ll help shape our platform’s future and connect with a global community of passionate individuals.

Now, how can you get started contributing to Mautic?

Familiarize Yourself with GitHub

Our project lives on GitHub, and we assume you already have an account there. If not, go to their official website and create one.

Then, try to understand the GitHub basics. Learn essential concepts like repositories, branches, commits, and pull requests. Afterward, explore advanced features such as forking, merging, and resolving merge conflicts. At this point, it’s also important to learn the basic Git command to help you later with code contribution.

We won’t discuss these concepts in this article. However, you can read the official GitHub documentation to familiarize yourself with GitHub and the Git Guide to learn about basic Git commands.

Explore Mautic Issues and Pull Requests

Once you understand the basics of Git and GitHub, the next step is to explore issues and pull requests in our repository.

If you’re familiar with the tech stack we use at Mautic and want to contribute right away, you can explore the open issues available in our repository. You must search for those that are not assigned to anyone. Look at the “Assignee” tab to see which are still available. When it’s still empty, it’s still available to work on.

Tip: Leave a comment to ask to be assigned to an issue. Only claim another issue after you finish the one assigned to you so you don’t get overwhelmed.

As we said, there’s always opportunity for everyone, regardless of skill level. So, if you’re unsure and want to learn Mautic’s codebase and how things work, one of the best ways is to help us review and test the open pull requests. Head to the “Pull requests” tab and look for a pull request you want to test.

Depending on your skill level and familiarity with our project, we provide labels to help you choose which issue you can work on or pull requests you can review and test.

Understand Issues and Pull Requests Labeling System

Whether you are a new developer or new to Mautic, our labeling system will help you find and decide which issue or pull request to test or work on. So, what labels are they?

T1

If you’re a beginner or someone new to Mautic, we recommend you search for an issue or a pull request with this label. It requires minimal coding experience and takes a relatively short time to test. This label usually concerns small changes such as typo fixing, small bug fixes, translation changes, minor UI improvements, or minor enhancements.

T2

The T2 label indicates issues and pull requests that are more complex than the T1. It requires more time, intermediate coding skills, and problem-solving abilities. Issues and pull requests with this label may require you to create an external services (e.g., Salesforce/HubSpot) account for testing.

T3

Issues and pull requests with this label are the most complex, demanding advanced coding knowledge and experience. They might touch multiple parts of Mautic, change large amounts of code, or completely change how some aspects of the code work.

Other Labels

There are other labels besides what is mentioned above to give you information on what type of issue or pull requests they are. To understand their meaning, hover over each label to see the information.

Search Issues and Pull Requests with Specific Labels on GitHub

You can use the filter options to locate specific labels. This will give you a list of issues or pull requests with the labels. You can filter and search one or multiple labels. Here is the way to do that:

1. Search One Label

To search one particular label, once you’re in the “Issues” or “Pull requests” tab, click the “Label” dropdown at the top. Scroll down or type the label you want to search in the input, then click the label name.

2. Search Multiple Labels

If you want to search more than one label, you can type them in the search input right on top of the issues or pull requests list. For example, `is:open is:issue label:bug label:T1`. This means you want to find open issues with “bug” and “T1” labels.

Start Contributing and Be a Mautician!

Now, you have the knowledge to start contributing to Mautic and join our community.

If you’re ready to contribute, you can find more detailed information in our Contributing to Mautic Guide for Developer and Code governance pages. Take your time to read them before contributing.

Lastly, we are excited to welcome you as a fellow Mautician!

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.

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.

Developer’s love APIs. There are APIs for everything. The popular ones like Google’s javascript mapping APIs, or Twitter’s REST apis. Amazingly useful APIs like Stripe and Paypal for running a business. APIs rule the world.

However, APIs aren’t everything, and they definitely can leave holes in your application’s integration when it comes data. This is because your application because responsible to go and fetch information from an API; or go and put information into that remote application using an API call.

What happens when that data can be changed by either application? Imagine a situation where you’re taking lead information from your website, and storing it in Mautic. But you also have another application that you want to house the information. You could use Mautic’s REST API and continually go and fetch new information, merge with any data you’ve curated on your own, and maintain a synced set of data that way.

You don’t have to think about that solution very long before you start realizing where it falls short – synchronized changes become a nightmare. What happens if a remote application changes some data?

A Mautic example might be a lead has the bounced flag added to it. Now your application has to be responsible to re-fetch that information. And your application can’t know that change has occurred, so it has to continually poll that external resource to keep that data synced. It can be a hassle for any application to continually do this. Add in other complications like API limits, which many large API providers like Paypal, Twitter, Google, and Facebook all enforce, and you’re left with a very likely possibility that at some point, you will not have an accurate representation of your data. This would be a lot like taking a roller coaster ride without knowing if the tracks in the loop are complete – you could end up careening to a swift and painful stop! Scary.

Enter Webhooks

Webhooks are a fantastic solution, guaranteed to save you time and money. A webhook is an HTTP URL endpoint supported by your third party application, which can receive a POST. It feels a lot like a REST API, but for you application’s purposes it is just one half of the API (eg: all the POST endpoints). That endpoint URL is then “executed” each time an “event” occurs. Webhooks close the roller coaster loop and ensure a safe ride for all your data passengers.

Adding webhooks to an application where data is changing constantly is a perfect solution to the API loophole, because now we know that data has changed, and our application just has to be responsible to receive the payload and update it appropriately.

Gone is the need to continually poll the remote resource to find out if data has changed, update it, and then check again in a little while to do the exact same check. This eliminates so many variables. API limits become a non-issue, out of sync data liabilities are reduced, and CPU cycles get saved by everyone in the transaction.

Webhooks are Simple

Webhooks are perfect at sharing bits of data on-time, when an event occurs, to a remote resource. This is usually all third party developers want from remote systems anyway. In these situations, using an API instead of a Webhook would be massive overkill. Using a webhook avoids the cost and time associated with building out an entire application to support API endpoints.

Next time you’re planning to create a full blown API for your application, ask yourself if the problem you’re trying to solve could be solved with some event listeners and a webhook call to a remote resource.

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:

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.

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.