Question

编辑：这似乎没有触及jinja。我错了。它纯粹的django模板。

已修复：令人尴尬：将旧的django-templated-email与破解的1.9模板系统的变通方法相结合。使用新的django（v1.11.x）和新的lib（v2.2.0），它再次正常工作。这个代码库开始于1.4左右。不确定如何错过这个lib更新。我不知道django是否修复了模板加载程序错误（它无法记住dirs在第二遍中搜索）或者lib是否修复了它

我正在使用Django进行电子邮件模板化。我们的模板使用{% extends %}从基本模板动态派生，具体取决于用户选择的电子邮件的样式。

似乎永远不会重新评估{extends}。始终重复使用为base_template参数提供的任何值。感觉就像文本结合的两个。

使用django-templated-email包（使用标准模板）
这使用默认的DjangoTemplates引擎
我已将所有来电记录到cached.Loader，并且永远不会重新请求基本模板
{% include footer %}似乎每次都会从装载机中重新获取
Debug=True|False导致无变化
我在每次通话前清除模板缓存，无效

我们的电子邮件模板如下所示：

# email/object_created.email
{% extends base_template %}
{% block subject_line %}New Object Created{% endblock %}
{% block html_content %}
    <h2>Hello {{ name }},</h2>
{% endlbock %}

# base_template (email/base/*.email) are like this:
<html>
    ...static html code, different in each base/*.email file...
    {% include 'email/partials/contents-footer.html' %}
</html>

Cache Clearing的工作原理如下：

from django.template import engines
for template in engines.all():
    for loader in template.engine.template_loaders:
        loader.reset()
        for ln in loader.loaders:
            ln.reset()

我不确定Jinja2实际上是如何使用{extends}的，并且在文档中没有看到任何内容表明这将会或不会发生。

我们这样称呼send_templated_email：

send_templated_mail(
    template_name="object_created",
    template_prefix="email/",
    context=dict(
        # this value changes, but only used(?) the 1st time
        # for each template_name.  different template_names reload it
        base_template="email/base/happy.email",
        name="Sam & Max"
    ),
    recipient_list=[...],
    ...
)

这导致printf_trace©之类的内容如下所示。输出已缩短以适应屏幕，但就此而言。

django.template.loader.get_template('email/object_created.email')
  uses: <django.DjangoTemplates at 0x108573668>
    .get_template('email/object_created.email') <Engine object at 0x108d7a2e8>
      .find_template('email/object_created.email') <cached.Loader at 0x10b957ef0>
      .find_template('email/base/happy.email') <cached.Loader at 0x10b957ef0>
      .find_template('email/partials/contents-footer.html') <cached.Loader at 0x10b957ef0>
...
django.template.loader.get_template('email/object_created.email')
  uses: <django.DjangoTemplates at 0x108573668>
    .get_template('email/object_created.email') <Engine object at 0x108d7a2e8>
      .find_template('email/object_created.email') <cached.Loader at 0x10b957ef0>
      .find_template('email/partials/contents-footer.html') <cached.Loader at 0x10b957ef0>

Answer 1

Mea culpa，有点尴尬。此问题已在较新版本的django-templated-email和django中得到修复。我花了很多时间来追踪它，这被浪费了。

简而言之，django 1.9有一个问题，每次都会重新评估模板，但是在处理{extends}节点时，加载器会忘记搜索目录，可能更多。这导致了自定义补丁（可能是他们的跟踪器中的问题？）和我们的pypi中的自定义包的解决方法。不幸的是，我使用了与原始名称相同的名称，因此pip list --outdated没有显示它。

我不确定问题在什么级别得到解决。我想它是在django级而不是django-templated-email但是我有点厌倦了盯着所有这些代码看得更远。

故事的道德是：始终检查您的依赖关系，并在新的django版本何时退出时重新评估。模板化的电子邮件没有发布，因此我们必须将提议的修补程序作为其自身的一部分打包并进行部署。

使用{％extends var_name％}未在

1 个答案: