时间戳

首页 > 解决方案 > 基于现有数据库制作 Wagtail 网站的一般方法

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

问题描述

请提供从现有的相当大的数据库建立 Wagtail 站点的指导。

该网站的核心是非常传统的，由两种基本页面类型组成：一种列出数据库中多个项目的“索引”页面类型，以及显示单个项目信息的“详细信息”页面类型。

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

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

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

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

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

    ——或者——</p>

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

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

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

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

标签： wagtailwagtail-pageurl

解决方案

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

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

我不能给你一个明确的答案，因为我对你试图解决的问题了解不够，请记住，将来任何事情都可以改变。但我认为最初使用选项 1 可能更容易。页面作为实体的方法使整个事情更容易推理。以下是一些需要考虑的利弊：

  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 查询缓存来弄脏你的手。
      国际化 - 可能，但您可能会发现您将在框架上工作一点。
      独立页面渲染- routeablePageMixin 是你的朋友，你需要实现一个适用于每个唯一实体的页面视图，动态生成 slug（记住，可能会改变，这意味着 SEO 影响）和其他正常页面视图所做的事情默认情况下，一切都是可行的。

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

考虑到上述情况，我认为将我们的核心数据绑定到 Wagtail 页面结构中的优势超过了将数据保存在独立模型/表中的优势。一个重要因素是，当我试图让网站的第一个版本运行时，事情会变得更快。另一个是该网站的翻译/国际化版本确实在计划中，所以我想要 Wagtail 在该领域的支持带来的好处。

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

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

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

推荐阅读