Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/templates/zerver/emails/email_base_default.html

52 lines
2.1 KiB
HTML
Raw Normal View History

emails: Inline CSS in emails in build_email. Previously, we had an architecture where CSS inlining for emails was done at provision time in inline_email_css.py. This was necessary because the library we were using for this, Premailer, was extremely slow, and doing the inlining for every outgoing email would have been prohibitively expensive. Now that we've migrated to a more modern library that inlines the small amount of CSS we have into emails nearly instantly, we are able to remove the complex architecture built to work around Premailer being slow and just do the CSS inlining as the final step in sending each individual email. This has several significant benefits: * Removes a fiddly provisioning step that made the edit/refresh cycle for modifying email templates confusing; there's no longer a CSS inlining step that, if you forget to do it, results in your testing a stale variant of the email templates. * Fixes internationalization problems related to translators working with pre-CSS-inlined emails, and then Django trying to apply the translators to the post-CSS-inlined version. * Makes the send_custom_email pipeline simpler and easier to improve. Signed-off-by: Daniil Fadeev <fadeevd@zulip.com>
2023-04-05 11:19:58 +02:00
{% import 'zerver/emails/macros.html' as macros %}
templates: Use HTML5 doctype for emails. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-04-21 01:37:51 +02:00
<!DOCTYPE html>
emails: Extract CSS from email_base_default.
2017-09-16 13:58:17 +02:00
<html lang="en">
<head>
<meta name="viewport" content="width=device-width" />
templates: Use HTML5 doctype for emails. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-04-21 01:37:51 +02:00
<meta charset="UTF-8" />
emails: Extract CSS from email_base_default.
2017-09-16 13:58:17 +02:00
<title>Zulip</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" class="body">
<tr>
<td>&nbsp;</td>
<td class="container">
<div class="content">
<a href="#" class="illustration">
{% block illustration %}{% endblock %}
</a>
emails: Fix preheader coming up inside email. This makes the preheader correctly invisible inside the email.
2018-07-25 15:16:31 +02:00
<span class="preheader">
{% block preheader %}{% endblock %}
</span>
emails: Extract CSS from email_base_default.
2017-09-16 13:58:17 +02:00
<table class="main">
<tr>
<td class="wrapper">
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td>
{% block content %}{% endblock %}
</td>
</tr>
</table>
emails: Add alt tags to images.
2019-04-19 21:23:58 +02:00
<img src="{{ email_images_base_uri }}/footer.png" alt="{{ _('Swimming fish') }}"/>
emails: Extract CSS from email_base_default.
2017-09-16 13:58:17 +02:00
</td>
</tr>
</table>
<div class="footer">
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="content-block">
server settings: Add setting for MAILING_ADDRESS. The rules here are fuzzy, and it's quite possible none of Zulip's emails need an address at all. Every country has its own rules though, which makes it hard to tell. In general, transactional emails do not need an address, and marketing emails do.
2017-10-19 04:09:53 +02:00
<span class="apple-link">{{physical_address}}</span>
emails: Extract CSS from email_base_default.
2017-09-16 13:58:17 +02:00
{% block manage_preferences %}{% endblock %}
</td>
</tr>
</table>
</div>
</div>
</td>
<td>&nbsp;</td>
</tr>
</table>
</body>
</html>