基于现有数据库制作 Wagtail 站点的一般方法

编程问答 2022-06-01

问题描述

请提供有关从现有的相当大的数据库设置 Wagtail 站点的指导。

就其核心而言，该站点将非常传统，包括两种基本页面类型：列出数据库中多个项目的“索引”页面类型，以及显示有关单个项目的信息的“详细信息”页面类型。

假设我正在使用生物数据库进行工作。在这种情况下，主数据库表中的每条记录都对应一个特定的物种。

在计划中的 Wagtail 站点中，给定的索引页面将显示物种列表（可能按“植物”、“灭绝”或“虚构”等类别进行过滤）。用户将能够单击任何列出的物种以显示该物种的详细信息页面，该页面将提供昆虫、蕨类植物或恐龙的完整描述和照片。详细信息页面还会显示其他信息，例如物种的完整分类、地理范围等。

我现有的数据库不完整，但已经包含数十万个“物种”，因此我需要将该数据导入 Wagtail（当然，为每个现有数据库记录从头开始创建 Wagtail 页面根本不实用） .

导入数据库并访问 Wagtail 中的数据的最佳方法是什么？我可以：

  1. 以编程方式（根据给定的技术 here）为当前数据库中的每个物种实例化一个 Wagtail 页面，以便每个物种都有自己的“永久”页面；

    ——或——

  2. 将数据导入站点的 Wagtail 数据库，与页面结构无关。然后，我必须创建片段模型来访问数据，并添加代码以根据在这些片段上运行的适当查询提供的数据为任何选定的物种动态呈现页面。

我完全是个新手，但方法 1 可能有两个优点：在导入期间创建的预定义页面已经有 slug，我可以轻松地将其转换为索引页面上的可点击链接；并且预定义的页面将被搜索引擎发现。

方法 2 对我来说似乎更清晰 — 将核心“数据数据”与“页面数据”（例如标题和 slug）分开是合乎逻辑的，并且会简化导入/导出程序。但是我是否正确地认为它会降低单个页面对搜索引擎的可见性？除了动态呈现页面所需的编程外，与方法 1 相比，它还有其他优点或缺点吗？

（关于方法 2：在 Wagtail 中，如何从基于片段的查询结果动态呈现页面？我知道 RoutablePageMixin，但我发现的示例使用它来访问已定义的 Wagtail 页面。我反而想要将代码片段查询中的数据放入模板中，并在页面呈现过程中创建一个 slug。将不胜感激配方或示例。）

解决方法

到目前为止，没有人回答过这个问题，但我确实从我自己联系过的一位经验丰富的 Wagtail 开发人员那里得到了非常有用的指导。基于该输入，我决定使用方法 #1（每个单独项目/“物种”的 Wagtail 页面），原因我将在本文末尾说明。

首先，这是我通过几封电子邮件收到的输入的编辑版本：

我不能给你一个明确的答案，因为我对 您正在尝试解决的问题，并记住任何事情都可以 将来改变了。但我认为最初可能会更容易 与选项 1 一起使用。 Page-as-entity 方法使整个过程 更容易推理。以下是一些需要考虑的利弊：

  1. 核心页面模型
  • 好处：您可以获得 slug、每个实体的唯一 URL、SEO 功能、页面呈现控件（例如发布复选框）、搜索、 翻译等——所有这些功能开箱即用，无需 太多的工作。您可以免费获得树结构。
  • 缺点：您在开发初期就被迫使用 URL 和页面层次结构，这在未来可能不适合。与数千 您可能会开始遇到一些性能问题的页面，并编辑 使用 Wagtail 管理界面的页面数据效率不高。它 在多个站点之间共享页面并不容易（例如，如果您 有一个供公众使用的简化网站 另一个有更多数据的网站 需要登录的地方。
    • 缓解不利因素：
      URL 结构 - 设置独立于您的类别/分组的页面层次结构（见下文）
      性能 - 如果您开始遇到问题，自定义代码可能会有所帮助，但最好等到真正出现问题时再使用。页面列表被很好地缓存，直到需要时才访问更深的模型。
      编辑界面 - 使用 ModelAdmin 可以增强编辑设置，为您提供多种访问/导航方式
      通过页面列表—— https://docs.wagtail.io/en/stable/reference/contrib/modeladmin/index.html
      跨站点共享 - 解决这个问题并不是一个简单的方法

  1. 作为普通 Django 模型的核心实体模型（与 Snippets mixin 一起使用）

    如果您想让实体数据与它们在页面中、跨站点中的使用方式隔离开来，请选择此方法，从而为您提供更多 控制。

    • 优点：更多地控制实体模型的使用方式，无需拘泥于 Title/Slug/id 等一些严格的字段，更多 控制编辑界面如何呈现这些实体（例如 通过 Snippet 编辑或 ModelAdmin 无需考虑如何 这些项目用于页面编辑 UI 区域）。
    • 缺点：在选择、国际化/翻译中显示片段列表的潜在性能问题将更加困难 一旦你到达那个点，将每个实体显示为一个独立的页面 更难，需要一些重写一些东西 页面模型已经做到了。
    • 缓解不利因素：
      性能 - 与上面类似，当它成为问题时解决它，你可能需要用一些更聪明的方法来弄脏你的手 索引和 Django 查询缓存。
      国际化 - 可能，但你可能会发现你会在一些框架下工作。
      独立页面渲染 - routablePageMixin 是你的朋友，你需要实现一个适用于每个页面的页面视图 独特的实体，即时生成 slug（记住，可以 改变，这意味着 SEO 影响）和其他正常的事情 默认情况下，页面视图会执行，但所有这些都是可行的。

无论哪种方式，规划页面结构都很重要 小心。对于选项一，最好使用扁平的 方法，即使页面的树结构使它看起来很容易 使事情真正嵌套 - 有时会适得其反。如果你的页面 结构具有实体的扁平方法（即一页用于 'entities' 并且每个实体都是直接位于下面的单个页面），然后 您可以自由制作其他页面或其他片段、标签或混合 与这些实体页面相关的任何内容。然后你可以做出 100 种方式 “列出”这些与实际完全分开的页面 单个实体页面（就树结构而言）。

考虑到上述情况，我决定将我们的核心数据绑定到 Wagtail 页面结构中的优势超过将数据保存在独立模型/表中的优势。一个重要的因素是，当我只是试图让网站的第一个版本运行时，事情会变得更快。另一个原因是该网站的翻译/国际化版本确实已在计划中，因此我希望从 Wagtail 在该领域的支持中获益。

就在 Wagtail 中编辑大量数据的低效率而言，解决方案是使用数据库工具，然后将更改上传到 Wagtail 数据库。对这些核心内容字段的访问可能必须在 Wagtail 管理中受到限制，以便内容编辑者不会做出在下一次上传时被覆盖的更改。

使用 Page 模型方法将意味着失去一些灵活性，我将不得不忍受核心数据被同一表格中的（与显示相关的）Wagtail 页面项目“污染”的想法。

但此后我遇到了一个令人印象深刻的开源 Wagtail 项目，该项目对其核心数据使用片段式配置：https://github.com/okfn/rtei / https://www.rtei.org/en/

wagtailwagtail-pageurl