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_marketing.html

54 lines
2.4 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 %}
emails: Fix some css not being applied to emails. This commit places the email CSS into the `style` tag located in the `head` section. This resolves the issue of being unable to apply certain CSS styles that cannot be inlined, such as media queries and pseudo-classes.
2023-04-27 11:50:02 +02:00
{% import 'zerver/emails/email.css' as css_styles %}
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
<!DOCTYPE html>
<html lang="en">
<head>
<meta name="viewport" content="width=device-width" />
<meta charset="UTF-8" />
<title>Zulip</title>
emails: Fix some css not being applied to emails. This commit places the email CSS into the `style` tag located in the `head` section. This resolves the issue of being unable to apply certain CSS styles that cannot be inlined, such as media queries and pseudo-classes.
2023-04-27 11:50:02 +02:00
<style>{{css_styles}}</style>
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
</head>
emails: Fix body tag styles being applied in messages template.
2023-05-01 08:10:13 +02:00
<body class="default-email-font-settings">
emails: Fix style regression for dynamically generated content. The migration to css-inline "fixed" the fact that styles from this file previously were never applied to the internals of missed-message emails. Rewrite much of the CSS to more correctly scope to apply to the appropriate elements, and document with comments the purpose of most blocks. Co-authored-by: Tim Abbott <tabbott@zulip.com>
2023-04-25 07:55:33 +02:00
<table border="0" cellpadding="0" cellspacing="0" class="body layout">
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
<tr>
<td>&nbsp;</td>
<td class="container wide-container">
<div class="content wide-content">
<a href="#" class="illustration">
{% block illustration %}{% endblock %}
</a>
<span class="preheader">
{% block preheader %}{% endblock %}
</span>
emails: Fix style regression for dynamically generated content. The migration to css-inline "fixed" the fact that styles from this file previously were never applied to the internals of missed-message emails. Rewrite much of the CSS to more correctly scope to apply to the appropriate elements, and document with comments the purpose of most blocks. Co-authored-by: Tim Abbott <tabbott@zulip.com>
2023-04-25 07:55:33 +02:00
<table class="main layout">
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
<tr>
<td class="wrapper">
emails: Fix style regression for dynamically generated content. The migration to css-inline "fixed" the fact that styles from this file previously were never applied to the internals of missed-message emails. Rewrite much of the CSS to more correctly scope to apply to the appropriate elements, and document with comments the purpose of most blocks. Co-authored-by: Tim Abbott <tabbott@zulip.com>
2023-04-25 07:55:33 +02:00
<table border="0" cellpadding="0" cellspacing="0" class="layout">
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
<tr>
emails: Apply different styles to custom email headings.
2023-05-31 18:34:36 +02:00
<td class="custom-email-content">
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
{% block content %}{% endblock %}
</td>
</tr>
</table>
email: Replace `uri` with `url` in templates and backend. In #23380 we want to change all ocurrences of `uri` to `url`. This commit changes the ocurrences of `uri` appeared in files related to email, including templates (`.html`, `.txt`) and backend (`.py`) codes. In `email.md`, `base_images_uri` is changed to `images_base_url` - the words `base` and `images` are swapped and plural form is added for `image`. This is becasue the former is not found anywhere in the codebase while the later appears a lot. To reduce confusion, this doccumentation changed accordingly.
2023-04-26 01:47:00 +02:00
<img src="{{ email_images_base_url }}/footer.png" alt="{{ _('Swimming fish') }}"/>
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
</td>
</tr>
</table>
<div class="footer">
emails: Fix style regression for dynamically generated content. The migration to css-inline "fixed" the fact that styles from this file previously were never applied to the internals of missed-message emails. Rewrite much of the CSS to more correctly scope to apply to the appropriate elements, and document with comments the purpose of most blocks. Co-authored-by: Tim Abbott <tabbott@zulip.com>
2023-04-25 07:55:33 +02:00
<table border="0" cellpadding="0" cellspacing="0" class="layout">
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
<tr>
emails: Fix style regression for dynamically generated content. The migration to css-inline "fixed" the fact that styles from this file previously were never applied to the internals of missed-message emails. Rewrite much of the CSS to more correctly scope to apply to the appropriate elements, and document with comments the purpose of most blocks. Co-authored-by: Tim Abbott <tabbott@zulip.com>
2023-04-25 07:55:33 +02:00
<td class="footer-content-block">
<span class="physical-address">{{physical_address}}</span>
emails: Create wider marketing email base template. For our marketing emails, we want a width that's more appropriate for newsletter context, vs. the narrow emails we use for transactional content. I haven't figured out a cleaner way to do this than duplicating most of email_base_default.source.html. But it's not a big deal to duplicate, since we've been changing that base template only about once a year.
2021-08-02 06:11:36 +02:00
{% block manage_preferences %}{% endblock %}
</td>
</tr>
</table>
</div>
</div>
</td>
<td>&nbsp;</td>
</tr>
</table>
</body>
</html>