在Wagtail多站点设置中，每个站点都有一个404

我正试图让两个不同的Wagtail站点拥有自己的404页面，但似乎没有办法在Wagtail“设置”=>“站点”部分的“站点”配置中指定使用哪个页面作为404页面，当我将它们放入相关的应用程序目录时，我似乎无法加载正确的404：

codebase/
  ./__init__.py
  ./manage.py
  ./apps/
     ./settings.py
     ./urls.py
     ...
     ./django-app-1/
     ./django-app-2/
     ./templates/
        ./404.html
     ./mainsite/
        ./migrations/
        ./static/
        ./templates/
           ./mainsite/
           ./404.html (this 404 always gets used)
     ./spinoff/
        ./migrations/
        ./static/
        ./templates/
           ./spinoff/
           ./404.html (this file never gets used)

因此在

已安装的应用程序中

我们有：

INSTALLED_APPS = [
  ...django apps...
  ...wagtail apps...

  'apps.mainsite',
  'apps.spinoff',
]

在这种情况下，主站点拥有大量的页面类型，而在不同域上运行的派生站点通过从apps.mainsite导入这些页面类型来使用这些页面类型

在Wagtail中，我们有两个页面作为根：一个是

主页

，它是

主站点

页面类型；另一个是

派生主页

，它是从主站点的页面类型继承的

spinof

页面类型

在站点设置中，我们有一个站点条目指向

mainsite.com

，其中main

主页设置为Root，另一个站点条目指向
spinoff.com
，其中派生主页设置为Root

对于这两个站点，一个不存在的url请求会导致主站点的404.html被使用，所以问题是：我们如何使派生域上不存在的url解析为派生域的404.html？
既然Wagtail是在Django上构建的，您可以。Wagtail的
core.view.service
调用
core.models.page.route
，如果找不到页面路由，则会引发
Http404
。因此，在
urls.py
中，您将放置：

从yourapp.views导入自定义404\u视图

handler404='yourapp.views.custom404\u view'

在
views.py
中：

from django.http import HttpResponseNotFound

def custom404_view(request, exception):       
    return HttpResponseNotFound('<h1>{}</h1>'.format(request.site))

从django.http导入HttpResponseNotFound
def custom404_视图（请求、异常）：
返回HttpResponseNotFound（“{}.”格式（request.site））

我上面显示的内容返回了Wagtail站点，以说明该站点在视图中可用，因此在您的情况下，只需根据该站点有条件地返回HTML。
为参考，针对该问题提出了一个问题，因为文档中似乎缺少该问题。参考文献是我：我提出了这个问题，在这个问题在通常的时间里没有得到答案后，摇摆问题do=）是的，要得到一个可靠的解决方案有点棘手，因为，我对Github问题做了更多的说明。不确定文档是一个解决方案，也许是一个简单的配方（像下面的丹的解决方案），但是它可能需要一个代码增强来使这类东西更容易从BOX中出来。WAGEW文档在给出示例方面是相当不错的，所以对于一个专门的“当使用多站点设置时，你需要考虑的事情”文本，一个具体的例子肯定是有用的，也是合适的。当然，理想的解决方案是，这变成了你在
站点设置中设置的东西：选择一个根页面和一个404页面。不，因为wagtail站点可以是任何页面类型的混合：同一个模型可以用来创建两个不同的页面，定义两个不同的站点，所以你不能将该处理程序添加到模型中，您也不能将其添加到url模式中，因为Wagtail管理并自动生成其自己的所有url。请再看一看，并希望重新考虑否决票。根据赏金：你能把这变成一个文件公关对wagtail的文件回购？因为wagtail不使用
views.py
文件，也不使用基本url.py以外的
url.py
，所以这个解释依赖于人们理解在使用wagtail时不适用的概念（即使在引擎罩下，他们也会）。我很乐意这样做（我非常重视良好的文档，并在Wagtail文档中批准了相当数量的小型拉动请求）。希望Wagtail维护人员会批准此PR。请记住一件事-Wagtail维护人员不希望看到Django文档在其文档中重复，因此我的PR将在适当的情况下引用Django文档-但我将解释在应用程序中创建views.py文件的需要。我计划今晚提交PR。我'我已提交了一份PR，以在Wagtail文档中介绍此解决方案：。关于您选择根页面和404页面的想法，我对Wagtail成为完全多租户非常感兴趣。为此，我已开始使用主题文件夹。主题文件夹位于项目的第一级，其中的每个文件夹都包含所有主题l特定主题的资产。在我的理想世界中，你会将一个主题与一个站点相关联。