What is an emogrifier? Styling emails to match your brand is incredibly difficult. This is primarily due to how email clients like Outlook and Gmail interpret CSS (the technical magic behind your brand’s look). Most email clients only regard inline CSS, which is difficult and expensive to maintain. Luckily the emogrifier solves this problem by reading CSS from a standalone source and inlining against a given markup. It does this by converting CSS selectors to XPath selectors, and if you understand what those are we hope you never need to understand how it actually happens.
Magento, and most of the PHP world, rely on `pelago/emogrifier` for making emails beautiful. One of our clients’ sites was experiencing off-brand emails on a non-production site following an upgrade from Magento 2.2.5 to 2.2.7. While troubleshooting we noticed the upgrade command had also upgraded the emogrifier to the latest version. After rolling back the emogrifier version it fixed the issue, but peaked our interest in what could happen within a widely used utility package.
We decided to dig further and we found the offending CSS selector was `footer td:nth-child(1)`. After a few minutes of testing we narrowed the cause of the error to the `:nth-child` selector. Then we found `Pelago\Emoglifier::translateNthChild` which was the method responsible for the conversion. Within that function the output path was being prefixed with `static` and was no longer valid.
Previous versions worked fine, so what changed. Git blame to the rescue.
The result showed this function was edited to update the static attribute accessor from `self` to `static`. OK that makes sense, this was an innocent bystander of search and replace refactoring. We submitted a small PR to resolve, which the maintainers merged within a couple hours.