Download the PHP package superbig/craft-mjml without Composer
On this page you can find all versions of the php package superbig/craft-mjml. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Informations about the package craft-mjml
MJML plugin for Craft CMS 3.x
Render Twig emails with MJML, the only framework that makes responsive email easy.
Requirements
This plugin requires Craft CMS 3.0.0-beta.23 or later.
Installation
To install the plugin, follow these instructions.
-
Open your terminal and go to your Craft project:
cd /path/to/project -
Then tell Composer to load the plugin:
composer require superbig/craft-mjml - In the Control Panel, go to Settings → Plugins and click the “Install” button for MJML.
MJML Overview
MJML is a markup language designed to reduce the pain of coding a responsive email. Its semantic syntax makes it easy and straightforward and its rich standard components library speeds up your development time and lightens your email codebase. MJML’s open-source engine generates high quality responsive HTML compliant with best practices.
Configuring MJML
Using MJML
You can either use the MJML CLI locally, the MJML API, or a custom/private MJML API endpoint.
To use the CLI, you need to install both Node and the mjml executable:
To use the official API, you need to request a API key.
Using a custom API endpoint
You can also use a custom or private MJML API endpoint instead of the official MJML API. This is useful for:
- Lightening the load on MJML servers
- Faster response times if the MJML servers are busy
- Having a fallback if something happens to the official API service
- Running MJML rendering in your own infrastructure for privacy or compliance reasons
To use a custom API endpoint, simply set the apiUrl configuration option to point to your server:
The custom endpoint must be compatible with the MJML API specification. A compatible option is mjml-server, which can be easily deployed using Docker:
When using a custom API endpoint that doesn't require authentication, you can omit the appId and secretKey settings.
Dynamic example with MJML CLI:
To use the API instead, swap mjmlCli with mjml.
Caching
The above examples will be cached. If you are passing Twig variables, each output will however be unique, rendering the cache ineffective.
In this instance you probably would like to use the include method:
The include method uses the CLI option by default, but you can set it to use the MJML API by passing api as the third option, like so:
Here is an example passing a contact in a newsletter template inside the Campaign plugin. The template path here is relative to your site templates root.
This will first render the MJML template once, cache it, then it will render the dynamic parts with Twig for each instance.
Includes
A caveat if you want to use includes:
Twig's built-in include method won't work in combination with MJML inside the template passed to the plugin include method.
This is because MJML is rendered first, before Twig, so if you include MJML in a partial that won't be rendered.
Workaround for MJML includes
Note that this is only supported for the CLI option.
A workaround for partials is to use the <mj-include /> tag to. Any partials referenced here will be relative to the Site templates root.
Note that you have to append the file extension here. This will resolve to /templates/mjml-partial.twig.
Another caveat with mj-include is that the content of partials isn't currently included when checking the cache of a rendered MJML template.
This means that if you render a MJML template that in turns has a <mj-include /> partial, then changes the content of the partial, the cache will be stale and your template won't reflect the changes.
A workaround for now is to clear the storage/runtime/temp/mjml folder in case this happens to you.
Brought to you by Superbig