Open martinstadelmann opened 4 years ago
@martinstadelmann We figured out what is the issue. There is a caching that is done by Matuic that looks at the email content. Since the content before injecting data is the same it uses the same cache value and that is why it doesn't change in the web view. We had to hack Mautic by first injecting a div at end of email through the plugin to identify it was using the plugin then detect it in Mautic code and generate a new hash. Definitely not an idea way to solve it but it was necessary for us to get it to work.
@arashsoheili Thanks for the feedback! So the root cause of the issue is event deeper than expected. Can you point me in the direction of where the caching of the email content is done in the Mautic core?
@martinstadelmann bundles/EmailBundle/Helper/MailHelper.php
. Line 1901. Problem was that emails sent with TWIG blocks email_stat row was referencing the same copy_id where the TWIG data had already been rendered was therefor the same for each email. Our change creates a new row in email_copies table for us to reference in email_stats table for emails with TWIG blocks. Not following where cacheing comes into play here
When viewing a campaign email that has been sent to multiple contacts through the web view the values within the twig template are the same for all contacts. This can be replicated by sending a campaign to multiple contacts containing a twig block referencing a variable that's unique to the contact and then either opening the webview URL in the email or by opening the email in the contact details.
This issue was previously affecting the actual sent emails as well, but was fixed in #10 (issue #6 ). But others have experienced the same issue concerning the webview (comment here).
If I check the actual values saved to the database you can see that the referenced copy (
email_copy
) sent to the contact inemail_stats
is the same for all users and contains the values of the first contact, but thetokens
row does actually contain adynamiccontent="Dynamic Content 1"
containing the whole email with the correct values for that contact.For now we removed the
{webview_url}
variable from our email templates to mitigate this issue by at least not showing faulty information to users or leaking sensible data.