Using a “staging” server – a replica of your production Mautic instance – to test whether an update is successful before applying it to production, is a best practice to prevent unexpected errors with your live marketing database.

In this article, you will learn how to clone your Mautic installation to a staging server and manually perform a Mautic update to the latest stable version.

The article assumes that you are running Mautic on a VPS or dedicated server (not shared hosting), where you have root access to the Linux command line to update Mautic. It also assumes that the MySQL database is on the same server as Mautic. Before getting started, make sure you have access to the following credentials handy:

• Root access to the Mautic server (root password and/or SSH key)
• Username and password to the provider dashboard (e.g. Amazon AWS, DigitalOcean, Linode, etc.) where your Mautic instance is hosted
• Access to where your DNS settings are managed. Usually your domain registrar (e.g. GoDaddy, NameCheap, etc.) – if you are using the registrar’s DNS service (e.g. nsXX.domaincontrol.com), or hosting company – if you have pointed your domain to your hosting provider’s nameservers.

If your hosting provider offers a “snapshot” or “image” option that is the simplest way to clone Mautic along with all of its dependencies (e.g. PHP and its related modules). This ensures that you are testing against the same web server and PHP versions on staging as in production. This way you can accurately see how the new version of Mautic would behave according to your specific server configuration.

Create a production server snapshot

Amazon AWS refers to this functionality as creating an EBS snapshot of the root volume of your EC2 instance (virtual server) running Mautic. Other providers, such as DigitalOcean call this taking a snapshot image of your Mautic Droplet. Either way, the hosting provider should allow you to launch a new virtual server based on the snapshot that is a clone of your original server. Prior to taking the snapshot however, you should ensure that you have disabled cron jobs by commenting out the Mautic-related cron jobs in the user-specific cron tab:

crontab -u www-data -e

or the system-wide cron tab

/etc/crontab

To comment out a crontab entry, simply add the # symbol at the beginning of the line.

This ensures that the staging server will not actually send out segment emails or trigger actions on published campaigns once it is switched on, which would be duplicated on your live server as well. After taking the snapshot you can safely remove the # symbols to re-enable cron jobs on your live instance.

Create a staging server based on the snapshot

Next, deploy the staging server using the snapshot that you have previously taken. The process for this will slightly vary based on the provider.

In AWS you would create a new EBS volume from the snapshot, then attach it as the root volume to a separate EC2 instance.

In DigitalOcean, you would create a new droplet and select the snapshot as the image that should be used as the droplet’s boot disk.

Point a separate ‘A’ record at the staging server

Note down the public IP address of the new, staging server, and for Amazon AWS, ensure that it has been added to a security group that allows inbound traffic on HTTP (80) and HTTPS (443) to the server.

From your domain registrar or managed DNS service (e.g. Route 53, Dyn, No-IP), create a new A record that points a staging subdomain (e.g. staging-mautic.example.com) at the public IP address of the staging server.

If you can configure the TTL (time to live) value you should set it to as low as possible (e.g. 300 seconds) so that the new record propagates across the Internet as rapidly as possible.

Modify staging server (e.g. Apache) configuration

After booting up the staging server, you’re still not quite done yet, because the new server is still listening for HTTP(S) requests from the domain or subdomain of the production instance. You need to change the VirtualHost URL in Apache or Nginx, as well as the site_url value in /path/to/mautic/app/config/local.php.

Most Mautic installations in the wild are running Apache. If you are using Ubuntu, your Apache configuration file is either located in /etc/apache2/sites-available or /etc/apache2/conf.d. If you are using CentOS or RHEL, your config file is located in /etc/httpd/conf.d by default.

Find the configuration file(s) with the ServerName value corresponding to your production Mautic URL and modify any instances of ServerName to the subdomain that you will be using for testing. If you are running Mautic on HTTPS, you should make sure to modify ServerName for both the port 80 and port 443 VirtualHost blocks. Depending on how it was set up, these VirtualHost blocks may be contained in two separate Apache config files.

If using HTTPS, also make sure to modify SSLCertificateFile, SSLCertificateKeyFile, and SSLCertificateChainFile values in the port 443 VirtualHost to refer to a path containing a valid SSL certificate for the staging subdomain.

If using Let’s Encrypt to obtain certificates, the directory structure is /etc/letsencrypt/live/subdomain.example.com/. Refer to the Let’s Encrypt Certbot documentation for instructions how to obtain a valid certificate for the staging subdomain.

Also, if you set up any 301 or 302 redirects in your VirtualHost files to redirect HTTP to HTTPS, remember to update those redirects with the staging subdomain as well.

ServerName staging-mautic.example.com

…

ServerName staging-mautic.example.com

…

SSLCertificateFile /etc/letsencrypt/live/staging-mautic.example.com/cert.pem

SSLCertificateKeyFile /etc/letsencrypt/live/staging-mautic.example.com/privkey.pem

SSLCertificateChainFile /etc/letsencrypt/live/staging-mautic.example.com/chain.pem

After making all of the changes above, restart the Apache server with the following commands.

Ubuntu: sudo service apache2 reload

CentOS: sudo systemctl restart httpd

Modify site_url in Mautic config on staging server

Using a text editor, change the site_url value in /path/to/mautic/app/config/local.php to reflect the staging site URL.  To prevent permissions errors, you should modify this file as the web server user (www-data on Ubuntu, apache on CentOS/RHEL) using the command (replacing username in both cases below with the appropriate web server user):

sudo -u username nano /path/to/mautic/app/config/local.php

Next, clear the Mautic cache so that the staging site URL takes effect.

sudo -u username php /path/to/mautic/app/console cache:clear

Test the Mautic update on the staging server

On the staging server, run the following commands to perform a Mautic update to the latest stable version, and bring the database schema into alignment with the latest version. If prompted whether to proceed at the doctrine migration or schema update steps, respond ‘y’ for yes (replacing user in all cases below with the appropriate web server user). 

Note: if you are updating to a release other than Stable (e.g. beta release) you will need to change the stability setting in the /path/to/mautic/app/config/local.php file.  Look for ‘update_stability’ and change to the relevant setting (e.g. ‘update_stability’ => ‘beta’).  If you haven’t previously saved the configuration settings in Mautic (settings > configuration) you may not see these settings until you save in the user interface for the first time.

sudo -u username php /path/to/mautic/app/console mautic:update:find 
sudo -u username php /path/to/mautic/app/console mautic:update:apply 
sudo -u username php /path/to/mautic/app/console doctrine:migration:status 
sudo -u username php /path/to/mautic/app/console doctrine:migration:migrate 
sudo -u username php /path/to/mautic/app/console doctrine:schema:update --dump-sql 
sudo -u username php /path/to/mautic/app/console doctrine:schema:update --force 
sudo -u username php /path/to/mautic/app/console cache:clear

Try the latest version of Mautic on the staging server

If you got the message in the console that Mautic has been updated to the latest version and you cleared the cache one last time after all of the commands in the previous step, you’re ready to test the latest version of Mautic.

Visit the staging Mautic URL in your web browser, login with your existing credentials, and verify the bottom right hand corner of the dashboard reflects a newer version of Mautic.

You should also make sure that no server errors are displayed by clicking on the “gear” icon in the top right-hand corner of the dashboard, then selecting System Info. Then, navigate to Error Log to ensure nothing unexpected is displayed there.

If you can navigate around the pages of the Mautic dashboard and check that features such as the visual editor are working properly, you may be ready to attempt an upgrade on your production server – after taking a backup, of course.

If you wanted to re-enable cron jobs (by uncommenting the lines in the crontab file) on the staging server to see the outgoing emails that would be generated by Mautic with the new version running in production, you would need to modify the email gateway settings to a test SMTP server such as MailHog, to prevent any live emails from actually being deployed.  

Please note this does not capture other channels such as push notification, browser notifications and text messages.

Otherwise, if there are errors, consider visiting the Mautic Community Forum for advice and troubleshooting tips from other community members, or hiring a Mautic support specialist or consultant to repair any server configuration issues before attempting the update on your live instance.

Testing, a good first step in the community, a highly appreciated contribution

Testing the app and the code of the app is one of the easiest ways to contribute to the Mautic community for the first time. 

While this is a very important contribution which must be done with a high degree of attention, most of the time, it doesn’t require technical skills. Any user of Mautic can contribute by testing a pending Pull Request.

A Pull Request (PR) is a piece of code offered to the community to fix a bug, enhance, or offer a new feature. You will find a list of all pending PRs on the Mautic community GitHub project.

High quality testing is needed

Testing is not complicated, it is just a matter of installing the targeted PR and testing the feature (newly created or fixed). But be careful, this is not enough!

Why? Simply because a bugfix or the introduction of a new feature can unfortunately create side effects, which means that it might introduce new bugs.

Conclusion, to do a (very) good test, you should ensure that you check all aspects of the feature you are testing, using all the different options or configurations. 

The aim is to ensure that the change has not introduced any new bugs, so it’s important that the testing is thorough. 

For instance, if there is a new feature around custom fields, while testing the feature itself works (creation, editing, deleting, etc.), be sure to also test that all the features using the customs fields are still working (email token, segment filters, reports, forms, etc.), and this will be a high quality test.

Testing a PR is easier than you might think

This is something very important. GitHub is a tool for developers, but we are asking you (maybe a marketer) to test the PR. No worries! Heath Dutton has been developing an amazing tool for you, Mautibox.

Anyone can now test a PR, without special technical skills.

If the PR is a bug fix, you will want to start by trying to reproduce the bug in your Mautic instance – for example using a locally installed Mautic instance. The PR will tell you the version of Mautic you need to test against in the details.

Note: Mautibox no longer exists. Please check the link for updated tester instructions.

 

Go to Mautibox and select the PR you want to test by the title or ID number (you’ll find the ID next to the title), click ‘Let’s Go!’ to launch the box and run your tests.

Once you log in to the PR on Mautibox, there is a toolbar at the bottom of the screen to help you, which includes a link back to the PR for providing feedback

Yes, that is very easy!

Mautibox FAQ:

• Do I have to do anything to install or update a PR?
  
  No, if you have made it to mautibox.com/7802 the patches for the pull request 7802 have been applied to the latest staging branch. This is automatically kept in sync even when the PR is updated. This includes database migrations and plugin updates.
• How do I trigger cron tasks?
  
  No need. The standard Cron tasks are executed every 5 minutes for all PRs that are active. This only includes the standard Mautic Cron tasks. You cannot use Mautibox to test specific/new Cron tasks at this time. That is best done offline.
• Can I test email from Mautibox?
  
  Yes,  but all outbound emails are captured for review here. Email will not go out into the internet to real email addresses. Please note this tool is shared between all PRs, so everyone’s test emails are publicly visible here.
• I get an error with a specific PR. How do I fix this?
  
  This usually means the PR is out of date and cannot be tested properly due to a conflict. Please comment on the PR in Github so that the developer can address this. Mautibox tries to use the same mechanism for code merging that Github would use, but there are rare cases where a PR is mergeable, but Mautibox cannot test it. If you feel that you’ve found such a bug with Mautibox itself, you can create an issue here.
  
• How long is my PR active?
  
  We aim to keep the PRs in Mautibox alive as the PRs in Github are applicable. We currently only put PRs “to sleep” when hard drive space becomes limited, purging static assets. Database contents persist indefinitely at this time.

Sharing test feedback

Last but not least, when you have completed your testing, the community needs your feedback! Please follow attentively the next procedure:

1. Create an account on GitHub if you don’t have one yet (free)
2. Go on the Mautic project where all the pending PR are listed
3. Select the PR you tested
4. Under the title of the PR, click on “Files Changed” and then on the green button on the right “Review changes”
5. Share your feedback under the appropriate status:
   1. “Comment” if you have any question,
   2. “Approve” if that works as expected and you didn’t notice any new bug,
   3. “Request changes” if something went wrong: the fix doesn’t work, the feature doesn’t work or if you noticed a bad side effect anywhere.
6. Warning: if you notice a bug or a wrong behavior, please add the “how to reproduce” paragraph in you review. The developer needs to understand exactly how to reproduce the issue to have the ability to fix it.

You’re done! Congratulations for your first review and on Mautic community members’ behalf, THANK YOU!

Want to find out more about contributing to the Mautic community? Join our Community Forums or find us on Slack!

I’ve been in and around technology for nearly 20 years. Everything from IT administration/end-user support, software development and technology marketing/sales. In each one of these lines of work, there has been a consistent theme. Testing.

Why Testing?

If we’re honest, all end user support starts with a lot of questions. What was happening when that issue happened? Were you doing another task when that happened? What led up to the error? What showed up on screen when it happened? These questions are all designed to provide answers that lead to preventing that issue in the future.

Every operating system, mobile application or other software that we may use, operates in an environment that is unique to it. Trying to determine the source of these issues, often means understanding the environment as well as every unique element related to it. Once a possible source is discovered, we test to determine if our hypothesis is correct.

In a similar fashion, whether you are designing digital learning tools, or a robust marketing automation solution, each newly designed feature or added capability requires testing to ensure that it operates in a manner befitting its goal. And likewise with marketing messages, there are companies that primarily work on focus group testing messages with a variety of audiences to ensure that their message is resonating with it’s potential customers.

If we can find testing in so many environments, then it makes logical sense that we equip our own organizations with systems that provide us with the opportunity to test out new software that will impact our business. That’s why we are excited to share that we will be re-launching a beta-release program with the announcement of Mautic 2.9.0!

Beta-Release

For those who don’t adhere to a release management process, in its simplest form there is a test server and a production server. Each of these have their own purpose. The test server provides organizations with the ability to load and test pre-releases of software in an environment that doesn’t interrupt your day-to-day marketing automation (or other business) activities. The production server typically contains the most stable version of the software that enables you to continue gathering data on your audience as well as provide them with value at every interaction.

Mautic makes it simple to access and test beta-releases. To set up a test server, follow a similar process for a production server, with the most significant change occurring in the setup of Mautic. Follow the link below for more configuration details.

IMPORTANT NOTE: Please do not use beta releases in your production environment. There may be bugs still present in a beta release. Remember to always take a backup of your files and database prior to applying any updates, beta or otherwise.

Mautic 2.9.0 Beta-Release

For more detailed information on how you can access the Mautic 2.9.0 beta-release click here.

Now you are ready to test! Be sure to access Mautic’s Github Pre-release page to determine what features are being released and what issues are being resolved.

Landing Pages are a primary Marketing online tool. Most of the time they are the first visual element that a visitor experiences of your brand. While landing pages are usually designed to be informative, they must also focus on the action expected – completing a form, signing up to a mailing list or purchasing a product, for example.

The biggest challenge faced by the designer is to create a landing page that looks good, but also converts well.

The Mautic marketing automation platform provides the perfect technology platform to convert an anonymous visitor into a potential lead, but the designer is the person who has the power to make that happen.

• Design for the technology platform

Landing pages may be short and to the point, or they may be long-form, engaging the visitor and providing various sources of information to help the visitor come to a decision.

Whether short or long form, navigation plays a critical role in focusing the user on completing the action for which the page is intended. If your visitors will only be spending a few seconds on the page, the design elements must help them to find their way to the relevant information and action points.

As a designer, we try to convey a story through the elements we place on the page, using structure to guide the flow between different chapters in the story, and explaining points which may not be obvious to the reader.

• Design

At Virya Group our focus is on keeping things simple. Our main goal is to create theme which are clean, functional and with minimal distraction.

All our theme designs adhere to research-driven best practices related to landing pages. By dispensing with the fluff and keeping only the essential requirements, we focus on directing visitors’ attention to the appropriate page elements.

In most cases, this will be a call to action such as a button, special offer, lead capture form or video.

It is also important to cater for any eventuality. Each theme we design comes with a library of elements to choose from. This includes design guidance on everything from the weight of fonts to the styling of a table and the dimensions of images on a photo slider.

We try to ensure that we design everything with a focus on the experience of the visitor to the landing page and the flexibility that our end-users might require when customising the ‘off-the-shelf’ or bespoke themes that we provide.

• The Form

No matter what the goal of your campaign is, a great landing page needs to push your visitor to take a specific action and in many cases, this will be through a lead capture form.

The most important element of the landing page; the lead capture form presents a trigger. By this point (thanks to your awesome design work!) visitors are highly motivated to do something (complete the form) and the task now is to make sure that it is super easy, clear, and a nice experience to complete that action.

Sometimes we might add an extra convincer reminding them what they are getting when completing the form, but we always make sure the process is smooth, easy to understand and seamless.

It’s easy to forget the importance of the button on the form – but this is a vital ‘call to action’ – and an opportunity to remind the visitor what they will receive on completing the form.

From the designers perspective a good colour contrast with the background and a careful choice of wording are the two ingredients that will communicate clearly your goal and ensure the conversion takes place. Don’t just leave it at ‘submit’!

• The Language

Here we shift our attention from pixels to people. In Mautic landing pages we want to focus on using a certain language, which builds trust between the brand, product or service and the visitors.

As a designer, we need to think like the potential customers, determining what they need to see and what we want to communicate so that they fully engage with the value proposition on this landing page. We try to keep the language simple, describing why the product or service meets their needs or solves their pain-point, with no use of complex language.

Headers, sub-headers and text are structured to highlight for the reader any important messages.

Well designed Mautic landing pages allow you to communicate your value proposition clearly, without burying the visitor under piles of irrelevant information.

• Mobile First

Mautic landing pages should be designed with mobile in mind – if they are going to be used to target a mobile audience. As this segment is growing rapidly, it is an important factor when preparing visuals for a landing page.

Mobile visitors need to have the same kind of guidance throughout the page, be able to access the same resources, and have the same compulsion to complete the action as their desktop counterparts.

Designing for mobile devices is not simply about moving blocks around to fit a smaller screen, but must focus on a deep awareness of the behaviour differences on mobile as opposed to desktop devices.

• Test

With the growing importance of fast-loading web pages and a need to do everything possible to ensure a conversion when a visitor lands on your page, the overall page size is an important consideration.

Multiple studies have shown that landing pages which take a long time to load result in less conversions.

Optimisation in this regard involves a lot of testing, but also close communication between the designer and the developer to ensure that visuals are delivered in the most efficient way – for example using a single SVG image and applying CSS to select the relevant image, or making sure that the images are rendered and provided in the resolution that is required, rather than in maximum resolution.

Testing does not stop with page speed, however. Full testing should also include running A/B tests to determine the best button placement, applying design knowledge to identify the best colour choice, icons and photos, making sure that the typography is appropriate for the purpose of the page, and of course once the page is developed, ensuring legibility, navigation flows and of course interaction on any device or browser.

When the needs of the visitor are combined with the designer’s qualitative understanding of them, and a thorough understanding of the market, the results can be spectacular.

Are there other elements to landing page design that you include in your process? Please comment below! Thank you again to Betty Chatzisavvidou for allowing us to share this valuable content. For a look at the original post, click here.