准备好迎接 Wagtail，目前最好的 Django CMS

既然 Wagtail CMS 正在为 1.0 版本做准备，我想花一些时间向大家介绍这款目前可用、全方位最好、最灵活的 Django CMS。 Wagtail 已经存在一段时间了，但似乎没有得到我认为它应得的关注。

在 Revolution Systems，我们最近在许多项目中使用 Wagtail，总体体验非常棒。 它在使简单的事情变得容易，以及使困难的事情不仅成为可能，而且相对容易之间取得了恰当的平衡。

功能亮点

• 非技术最终用户易于使用。 定制管理界面，具有出色的 UI/UX
• 与您网站上的任何其他 Django 应用程序良好兼容
• 轻松进行管理自定义和品牌化
• CMS 模型的灵活性，可以处理超出仅仅拥有一个“页面”的更多结构化数据
• 内置表单构建器系统
• 出色的图像和文档/文件支持和 UI
• StreamField 提供终极灵活性，允许您定义和组织小的内容块
• 能够组织管理选项卡和字段布局
• 控制/灵活地控制哪些页面模型可以添加到某些 URL 下面
• 连接到 ElasticSearch 进行搜索
• 与 Varnish 和静态站点生成器兼容，以帮助提高大规模性能

管理界面

让我们面对现实吧，Django 管理界面有很多不足之处。 它非常面向 CRUD，对于除了最技术性的用户之外的所有人来说都令人困惑。 即使使用 Django Suit 之类的软件包对其进行改进，或者完全将其替换为像 Grappelli 之类的东西，也并不是您的最终用户想要的。 不要误会我的意思：这两个软件包都很棒，您应该查看一下，但是它们根本无法克服所有障碍和痛苦，这些障碍和痛苦来自于试图将 Django 管理界面自定义到超出某个点。

Wagtail 开箱即用地带有自己的自定义管理界面，该界面专门面向典型的 CMS 工作流程。 查看这个很棒的关于 Wagtail 的 宣传视频，您就会明白我的意思。 认真地，去看看吧。 我等你。

是不是看起来很棒？ 我第一次看到 Wagtail 视频时的第一个想法是：“不错，但我敢打赌自定义它会非常痛苦......。” 值得庆幸的是，我还是尝试了一下，发现自定义 Wagtail 管理界面实际上非常简单。

文档中有一个很棒的 编辑器指南，这是大多数最终用户入门所需要的。 到目前为止，在使用过程中，唯一让用户感到困惑的是资源管理器、根页面以及页面的一般分层性质。 即使是这些小问题，只需与用户快速交谈，他们就能理解并继续前进。

哦，还有一个巨大的好处，管理界面在移动设备和平板电脑上都出奇地好用！

自定义 Wagtail 管理界面的方法

您可以通过几种方式自定义管理界面。 首先，您只需进行 少量配置，就可以确定哪些字段对您的用户可见，以及在界面的哪个选项卡上可见。 将此视为您将要进行的“自定义”的入门级别。

自定义管理界面的品牌也是一个常见的需求。 技术人员通常看不到这一点，但如果您能暂时戴上您的最终用户帽子，那么访问 www.revsys.com 的登录页面显示“欢迎来到 Wagtail CMS 管理界面”似乎很奇怪并且常常令人困惑。 如果您安装 django-overextends，您可以 轻松自定义 CMS 使用的徽标、登录消息和欢迎消息，以符合用户的期望。

对我来说，我期望从 CMS 中获得这两个自定义选项；但是，Wagtail 更进一步，为您提供了 钩子，以便进行更丰富的自定义。 您可以执行以下操作：

• 将项目添加到 Wagtail 用户栏，该用户栏对于登录用户显示在页面右侧，很像 Django Debug Toolbar
• 从 Wagtail 管理主页添加或删除项目
• 从主页添加或删除摘要项目（页面、文档、图像等）
• 使用钩子在幕后执行操作，或者如果您想在创建、编辑或删除页面后获得自己的自定义响应
• 添加您自己的管理菜单项，这些菜单项可以转到您想要的任何 Django 视图或站外 URL。

[caption align="left"][/caption]

我成功地使用了最后一项能力在 TEDxLawrence.com 上添加管理菜单项。 我们需要一种方法让我们的演讲者委员会查看演讲者提交的内容、投票和发表评论。 我没有尝试将所有这些都塞进 Django Admin 甚至 Wagtail Admin 的领域中，而是简单地链接到完全自定义的基于类的视图，以便让我获得完整的端到端控制。

Wagtail 页面

大多数内容管理系统都围绕页面的概念进行操作，该页面通常具有标题、页面的某种简短描述以及页面内容本身。 许多为您提供漂亮的 WYSIWYG 编辑工具，使添加标题、列表、粗体和斜体等内容相对容易。

当您想要在页面上表示的内容与此数据模型不太匹配时，问题就来了。 您是否只是将其塞进内容字段中？ 也许您的 CMS 具有一些笨拙的机制，可以通过某种插件系统将其他内容与页面相关联。 或者，也许您只是运气不好，放弃了，并从模板加载了一些带有 javascript 的内容。

使用 Wagtail，您可以构建自己的继承自其 Page 模型的模型。 这使您能够自定义特定数据的特定字段，并最终消除了将您的数据概念融入 CMS 对世界的愿景所需的许多通常的恶作剧。

这可能最好作为一个例子。 让我们构建两种不同类型的页面。 一个简单的博客类型页面和一个更复杂的员工页面，人们可能会用于单个员工。

我们的简单页面可以如下所示

from django.db import models
from wagtail.wagtailcore.models import Page
from wagtail.wagtailcore.fields import RichTextField
from wagtail.wagtailadmin.edit_handlers import FieldPanel

class BlogPage(Page):
    sub_title = models.CharField(max_length=500, blank=True)
    published = models.DateField()
    author = models.CharField(max_length=100)
    summary = models.RichTextField(blank=True)
    body = models.RichTextField()
    closing_content = models.RichTextField(blank=True)

    content_panels = [
        FieldPanel(‘title’),
        FieldPanel(‘sub_title’),
        FieldPanel(‘published’),
        FieldPanel(‘author’),
        FieldPanel(‘summary’),
        FieldPanel(‘body’),
        FieldPanel(‘closing_content’)
    ]

Wagtail 会自动为您设置一些字段，例如标题、页面的 slug、开始/结束可见时间以及 SEO/meta 相关字段，因此您只需定义您想要的超出这些字段的字段。

在这里，我们定义了一些我们想要在博客文章中包含的额外结构化信息。 一个可能的 sub_title 和摘要信息、作者、条目发布日期以及通常的body字段。 我们还添加了一个额外的 closing_content 字段，我们可能会将其用于结束语或我们想要突出显示并在帖子下方显示的其他内容。

您需要做的就是将其添加到 Django 应用程序的 models.py 中，运行makemigrations和migrate，您就可以开始了。

现在让我们制作一个稍微复杂的员工页面

DEPARTMENT_CHOICES = (
    (‘admin’, ‘Administration’),
    (‘accounting’, ‘Accounting’),
    (‘marketing’, ‘Marketing’),
    (‘sales’, ‘Sales’),
    (‘engineer’, ‘Engineering’),
)

class StaffPage(Page):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
    active = models.BooleanField(default=True)
    start_date = models.DateField()
    end_date = models.DateField(blank=True, null=True)
    department = models.CharField(max_length=50, choices=DEPARTMENT_CHOICES)
    email = models.EmailField()
    twitter = models.CharField(max_length=50)
    short_bio = models.RichTextField(blank=True)
    bio = models.RichTextField(blank=True)
    education = models.RichTextField(blank=True)
    work_history = models.RichTextField(blank=True)

    # Panel options left out for brevity

正如您所看到的，StaffPage 模型有更多的字段，其中大多数是可选的，这允许员工随着时间的推移更新他们的信息，并且不会被迫在其他必需字段中放入“简介即将推出”。

很简单，对吧？ 您可能认为这里面有什么猫腻；幸运的是，您错了。 实际上非常简单。 简单的事情变得容易，对吧？

Wagtail 中更困难的事情

那么 Wagtail 中困难的事情是什么呢？ 好吧，这主要只是熟悉整个系统。 一些可能会让您绊倒的事情是：

• 您不能在您的派生模型上有一个名为url的字段，因为 Wagtail 在父 Page 模型中使用该字段名称。 不幸的是，如果您确实添加了一个，我已经添加过很多次了，你会得到一个不是很有用的错误“无法设置属性”，没有太多其他信息可供参考。
• 在许多列表类型的页面上，只需以某种时间顺序显示所有带有分页的项目即可。 其他时候，用户希望能够手动管理哪些内容显示在给定的页面上。 Wagtail 使这相对容易，因为您可以使用通过类型的模型来定义与其他页面的 ForeignKey 关系，并使用 PageChoosePanel 为用户提供一个不错的界面来执行此操作。 用户还可以在管理界面中手动对其进行排序，无需额外工作。
• 通过在子模型上设置名为 parent_page_types 的列表，可以限制哪些页面可以作为子页面（即位于页面之下）创建。 这样，该页面只能添加到这些已定义类型的页面之下。 在具有大量不同页面类型的复杂站点上，这有助于将“页面选择和创建”选项的选择范围控制在用户可管理的级别。 显然，它也有助于防止用户在网站的错误部分创建错误的页面类型。
• Wagtail 目前在构建导航菜单方面做得不太好，但是有十几个可重用的 Django 应用程序可以帮助处理这个问题。 通常，网站的菜单保持相对静态，并且无论如何也不会每天都进行编辑。
• 支持使用相同 CMS 的多个站点。 这在技术上并不难，但在概念上更难理解。 Wagtail 通过其 wagtailsites 应用程序支持拥有多个站点。 其工作方式是您只需为每个主机名设置根页面，它基本上就从那里开始接管；但是，在大多数情况下，拥有两个不同的 Wagtail 实例并使用不同的数据库可能更容易和更干净。

图像和文档

文档是您希望能够上传到系统中的任何类型的文件。 这可以处理用户需要上传 PDF、Excel 或 Word 文档并能够从任何其他内容链接到它的任何情况。

图像正如您所想；但是，如果您选择，您可以为此定义自己的基本模型，并附加诸如版权、许可、署名，甚至如果您愿意的话，还可以附加诸如 EXIF 数据之类的其他字段。

文档和图像都通过 django-taggit 支持标签，并且在管理界面中为它们设计了非常漂亮的外观和用户体验。

是的，在您问之前，它内置了对模板中灵活缩略图的支持，以及手动定义图像中的主要焦点以避免奇怪裁剪的能力。

表单构建器界面

Wagtail 还有一个不错的 表单构建器 内置其中，可以轻松满足您的典型联系表单场景或更复杂的收集需求。

与页面非常相似，您只需从 Wagtail 子类化，并定义您想要收集的字段。 在您的模型上，您还可以覆盖 process_form_submission 方法以进行更复杂的验证，或者在更常见的情况下，向相关方发送电子邮件，告知他们有新的提交。

表单构建器的一个很棒的功能是内置的查看和下载界面。 查看已收到的数据很棒，但您知道您的用户肯定想要提取它并将其用于其他目的。 Wagtail 巧妙地预料到了这一点，并允许用户随时按日期范围将提交的数据下载为 CSV 文件。

代码片段

Wagtail 代码片段是可重用的内容，它们不是完整的网页。 通常，这些用于诸如侧边栏内容、广告或行动号召之类的东西。

与页面或表单不同，您不会对模型进行子类化，而是定义一个模型并将其简单地注册为代码片段。 然后，您可以自由地让您的用户选择将您想要的代码片段类型附加到其他页面。 或者，如果您只是想让他们能够编辑诸如页脚内容之类的内容，您可以手动包含代码片段数据，并且代码片段管理界面实际上只是他们的编辑界面。

最佳功能？ 内容流

虽然能够使用自己的字段定义自己的页面类型很有用，但这与真正自由形式的内容还有很大的差距。 Wagtail 的杀手级功能 StreamField 是 1.0 版本中的新增功能。

用户想要自由形式的内容，而开发人员、设计人员甚至运维人员都想要结构良好的数据。 StreamFields 可以满足双方的需求。

当您在页面上定义 StreamField 时，您设置可以添加到该流中的块类型。 块可以像文本的 CharField 一样简单，也可以像上面使用 结构化块类型 一样的 Staff 类型记录一样复杂。

最终用户可以添加几个不同类型的标题，一些富文本内容块，并将它们与一些图像和代码块穿插在一起。 您定义的每种块类型都可以使用不同的 CSS 进行不同的样式设置，并且/或者如果需要，可以完全不同地构造其标记。

在此功能添加到 1.0 之前，我不得不求助于复杂的页面关系，这些页面实际上并不是我们打算在网站上显示的页面。 我们只是颠覆了 Wagtail 的页面选择功能，以赋予用户他们需要的灵活性，并将所有内容都保留在同一个管理界面中。

以下是 StreamFields 的管理界面外观。 在这里，我们定义了一个名为 Body 的字段，其中包含标题、内容和代码块类型。 这些行中的每一行都是不同的块。 顶部和底部是标题。 如您所见，您可以简单地单击加号图标以在其他块之间添加新块，或者使用右侧的箭头来移动块。 由于我预计会很快修复的 CSS 错误，它们目前有点难以看清。

Wagtail 的未来

我认为 Wagtail 总体上，尤其是在 Django 社区中，有着非常光明的前景； 但是，与任何 1.0 产品一样，我绝对希望在未来的版本中看到一些东西。 我希望看到的两个主要内容是

• 高质量和灵活的通用页面和块类型的社区集合，使大多数站点更像是乐高积木练习而不是编码练习。
• 能够更轻松地自定义和控制在编辑内容时出现在屏幕底部的“发布/审核/另存为草稿”选项。 在许多较小的站点或具有扁平化工作流程的站点上，应该很容易将“发布”或“提交审核”设为呈现给用户的默认操作。

本文最初发表在 RevSys 博客上。