Bypassing (or Upgrading Emogrifier) In Woocommerce

Published by John on February 1, 2019 Under Wordpress

Recently, while designing some custom emails for a Woocommerce shop, I was running into some styling issues, mostly in Outlook/Windows 10 Mail, although even clients that are better at rendering html, like ThunderBird, were seeing some issues.

I had designed the email separately in static HTML, validated it, and sent some tests and it looked fine. However, when I plugged it into the customer-invoice.php email template, several elements of the design broke. Specifically, the @font-face block was no longer working, there were several issues with some of the nested tables, like missing background colors, font colors being changed, etc.

I took a peak at the HTML of the email that was being generated and noticed that a bunch of inline styles were being added to the email. Initially, I thought the transactional email service we use was adding them, as that is an option they offer for their own email templates, however when I disabled that, the styles were still getting changed.

After a bit more digging, I discovered that Woocommerce, in woocommerce/includes/emails/class-wc-email.php, uses the emogrifier library to add/convert
to inline styles in emails. This happens in the style_inline function provided the email is a ‘text/html’ or ‘multipart/alternative’ email.

Unfortunately, there didn’t seem to be a good way to either disable this or change the settings of emogrifier, like using the addExcludedSelector function to keep an element from having styles added to it.

I think it would be possible to use the woocommerce_mail_content filter and manually add some styles back, although I was still running into some issues with some of the styles being automatically added.

Given some time, I think I could work around some of issues I was having with styles being added, but wanted a way to bypass/change settings in Emogrifier.

How to Disable or Upgrade Emogrifier in Woocommerce

Disclaimer: This isn’t an ideal solution, see below for some potential issues with this. Any updates will require email testing and it is probably better to fix the email template so it works with emogrifier whenever possible!

In the style_inline function of woocommerce/includes/emails/class-wc-email.php, Woocommerce first checks to see if the Emogrifier class exists. If it does not, it will load it’s own. So, if we load our own version of Emogrifier, this will allow us to change some settings or add a flag for disabling emogrification all together.

First, in your template, copy the emogrifier class to your template folder. I use ‘my-theme’ below, but you will obviosuly need to update paths so they accurately reflect your WordPress template and webserver directory:

cp /wp-content/plugins/woocommerce/includes/libraries/class-emogrifier.php /wp-content/themes/my-theme/includes/

Then, in your functions.php include this new file:

include_once('includes/class-emogrifier.php');

At the time of this writing, WooCommerce uses version version 2.0.0 of Emogrifier, so if you wanted to upgrade to a newer version of emogrifier, instead of copying the Woocommerce version as shown above, install the new copy into your theme and change the include_once as required.

Now that you have your own copy, you can make some tweaks to the default settings or the emogrify() function so that specific emails don’t get emogrified.

Potential Problems with This Approach

While I think this should be relatively safe and it allows you to disable or upgrade the emogrify library without modifying any woocommerce code, there are a few problems with this approach:

  1. Woocommerce updates emogrifier to a newer version: Best case, this just means some bugfixes or whatever are missing from the copy we have. Worse case, emogrifier changes their API and it breaks the emails.
  2. Woocommerce switches to a different email parser: Worse case, our emogrifier version is ignored and emails need to be tested/fixed again.
  3. Woocommerce changes options in emogrifier: Depending on how they do this, it is possible(although unlikely) that these might not be reflected in the library you are using or may overwrite some of the settings added.

So, you will still need to test emails, especially after a major woocommerce update, as well as probably take a peak at the class-wc-email.php class, but chances are it won’t break…probably.


No Comments |

Add a Comment