Skip to content

Mautic Step 2 – Cron Jobs

Dear Reader,

This is the third post on “My Journey into Mautic”. I’m getting Mautic – a Marketing Automation Tool – setup and running on my own server. Along the way I’m sharing what I’ve learned in hopes that it helps someone, or at least helps me the next time I go down the road.

Maintaining Mautic from the command line

This time we are talking about the cron jobs necessary to make Mautic run. Mautic has several commands that are necessary to execute that are not web based. They are run from the command line manually (dumb idea) or using a scheduler like cron on Linux. As with my “Installing Mautic” post, this post is only interesting to those of you self-hosting Mautic.

There is a great manual page on this titles “Cron Jobs”. It tells you a lot of what I’ll tell you here. If you haven’t read it yet, I highly recommend you start there.

The jobs

There are 4 main cron jobs that need to run. All of them are commands build on top of the symfony/console package. Symfony/console is my favorite package to install from packagist. Most of my projects are run form the cli and I use symfony/console for all of them. The heart of the Mautic console commands is app/console. So all of the commands look like this:

$ php /path/to/mautic/app/console mautic:command

You need to locate the app directory on your installation and adjust the examples accordingly.

The 4 jobs that you need to run regularly are:

  • mautic:segments:update
  • mautic:campaigns:rebuild
  • mautic:campaigns:trigger
  • mautic:messages:send

The last one is necessary if you are using Mautic to send out marketing campaigns. Currently, I am not, I’m still fighting with the MailChimp integration in hopes of making that work instead. However, I have this one enabled anyhow.

My current install for Mautic is very low volume. I think there are currently 10 contacts in the DB. Even so, the manual recommends that you stagger the jobs so that they don’t all run at once. They recommend the following.

0,15,30,45 <— mautic:segments:update
5,20,35,50 <— mautic:campaigns:update
10,25,40,55 <— mautic:campaigns:trigger

The problem I ran into

All of this is pretty standard stuff if you are familiar with Linux and crontab. There is one thing that bit me in the butt, and it’s the reason I am blogging this, permissions.

Originally, I had all of those setup in my crontab. My “my crontab” I mean the cron tab for my personal account on the server. Since I am a member of the group that the web server runs under – mine is not a shared hosting environment, my sites are the only sites on the server – so I should have been able to do everything, right? Nope. The thing I forgot is that most everything is created with 0755 permissions. This means I can see the files created by the web server, but I can’t modify them. This hits you pretty quick when running any of these commands form any accounts that doesn’t have write permissions, because they all write to the app/logs/*.log files.

The obvious solution was to simply move them to the crontab of the account that my web server runs under, right? Yep, expect that that account has it’s shell set to nologin. This means that I can’t easily test them, or run them as a one-off for example clearing the cache. All system accounts are setup this way to adhere to the Best Practice Principal of Least Privilege.

The answer is yes, to add them into the account that the web server runs under, but you have to add the following to the beginning of the crontab.

SHELL=/bin/bash

NOW at least the cron jobs can run without a problem. I still have to jump through a couple of hoops to clear the cache.

Conclusion

Permissions will bite you in the butt every time on *nix systems. Be careful with them. The answer is almost never :

$ chmod -R 777 *

There is usually a way to get things done that don’t compromise your application’s security.

If you a reading this thinking “Well D’uh!” Again, this is more to remind me for next time than anything else. :) If it helps you along the way, I’m happy.

Until next time,
I <3 |<
=C=

My Journey Into Mautic

Mautic logoDear Reader,

Those that know me know that I have an obsession with marketing. I mean I’m no good at it, but the topic fascinates me. Almost all of the podcasts I listen to on a regular basis are marketing related. One topic in particular that interests me is “Marketing Automation”. Marketing Automation covers a huge swath of topics and since I am not an expert at the, I won’t attempt to explain them. However, three things that are covered by MA that I understand reasonably well are:

  • Lead Generators
  • Landing Pages
  • Email Marketing Campaigns

Even here we have topics so broad that entire books have been written on each of them. Still, these thee topics represent the heart of what is called “Inbound Marketing”.

Inbound Marketing is you trying to convince people to come to your site and buy/join your mailing list. This is as opposed to Outbound Marketing where you contact potential customers directly and try to convince them to buy.

Introducing Mautic

Because I am interested in Marketing Automation and want to start applying the techniques in the projects I run.

I started looking around for vendors who could provide these services. What I found is that most SaaS vendors assume that everybody who wants to use their software has deep pockets.

Side Note: I had a real interesting interview with someone form PostMark this past week after I tweeted that I did not choose them but chose Mail Gun. The subject of price came up and my words to him were “Yes, it’s only $15/month. However, right now I’ve got 7-8 companies wanting just $15-$25 per month. It all ads up quick.

During my research into solutions that may or may not work but I couldn’t afford to try, I cam across a project called Mautic. Mautic had three major things going for it right away.

  1. It is Open Source
  2. It is written in PHP
  3. One of the leads at Mautic is a friend of mine, Don Gilbert

Wow! To me, a long time PHP developer, this was a home run. I began digging deeper into it.

  • It integrates into WordPress, my tool of choice for building websites.
  • I can host it myself. (This is probably more important to me than others. My reasons are partly technical and partly political.)
  • I can contribute back to the project.

So we have a winner and I was able to give a big raspberry to all the other SaaS vendors who wanted me to pony up each month. Well, that’s what I thought at least.

As it turns out Mautic – while it it is most of the things I said – is still open source software. This means that development is at the whim of contributors that have other priorities. This meas that there are problems with Mautic that will get fixed when they are a problem for someone with the knowledge and time to fix them. While this is ok for me because it is possible for me to dive in and fix things if they reach a level of importance to me, it’s probably a downside to most non-developer users.

Where to go from here?

Despite some obvious flaws and at least one huge show stopping bug, I see a bright future for Mautic. So I’m going to invest my time in getting it setup and running. I’ve already run the install twice and I’m happy with the results the second time.

Along the way, I am going to blog what I learn. This is both for me so I can reference it later, and to help anyone else who is working with Mautic.

My setup will be:

Most of what I do can be done without having to worry about hosting your own copy. I am doing it this way so that I can integrate Mautic into my existing infrastructure. So don’t worry if you aren’t a programming, you can still learn from my mistakes. :)

Along the way, I will get things wrong – my definitions above may already be wrong. Leave me a comment and correct me. I’m not claiming that I know what I’m doing. I’m just saying that I’ll tell you what I’ve done, and what I’ve learned.

Posts

Until next time,
I <3 |<
=C=