feat: minify and notify clipable email body

[miguelpeixe]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Email content larger than 102kb gets clipped by Gmail. This PR implements a notice to let the user know their content may get clipped if we detect a resulting body larger than 100,000 bytes. This approximation is assuming that the ESP will add extra tags for tracking, footer, etc.

It also implements the minifying options to MJML to reduce the chance of clipping. My local tests produced a reduction of 25% of an email with ~100k bytes.

How to test the changes in this Pull Request:

1. Check out this PR and run npm run build
2. Send an email using multiple different blocks to make sure the markup is not altered by the minification
3. Add multiple text blocks in a newsletter draft until it reaches > 100k bytes
4. Save the draft and confirm you see the notice in the screenshot above

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[dkoo]

Email rendering seems okay (except the new WP 5.9 "Row" block seems to not render correctly—perhaps we should disable this block for the newsletter editor?). The length warning is also great and works well upon save.

Issue: I'm seeing this JS console error about the minify option for MJML:

"minify" option is deprecated in mjml-core and only available in mjml cli.

Inspecting the meta value, it does appear to be minified, but I wonder if the above indicates support for this feature might go away at some point?

[miguelpeixe]

except the new WP 5.9 "Row" block seems to not render correctly

Nice catch! I just pushed #772 for this.

Inspecting the meta value, it does appear to be minified, but I wonder if the above indicates support for this feature might go away at some point?

I didn't notice that warning, but unfortunately yes ☹️
We could use the minify option until the next stable major release is out and until then figure out if we'll use a different library for the task. We can also not minify at all and just use the notice. WDYT?

[dkoo]

We could use the minify option until the next stable major release is out and until then figure out if we'll use a different library for the task. We can also not minify at all and just use the notice. WDYT?

This sounds good to me, as long as continuing to use the minify option doesn't end up causing an error on the MJML side. I'm assuming after the option is removed from the library behavior will revert back to what's happening on the current master HEAD, right? Basically the meta value will be saved as unminified HTML again?

[miguelpeixe]

Reading the PR, it just changes the warning message from "is deprecated" to "has been removed" and doesn't apply the htmlMinify(). Shouldn't produce any actual error. The HTML should be stored the same way, only not minified anymore. This will also not affect how the notice interprets the body length.

[dkoo]

That matches my understanding, too—thanks!

[matticbot]

🎉 This PR is included in version 1.43.0-alpha.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This PR is included in version 1.43.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀