Django 的 Satchmo 和 Flatpages 问题
我在 Satchmo 中配置 Flatpages 时遇到问题。我以前在纯 django 应用程序中使用过它们，但现在它不起作用，当我尝试进入平面配置站点时返回 301 http 错误。
我所做的配置是：
- 将中间件“django.contrib.flatpages.middleware.FlatpageFallbackMiddleware”添加到 MIDDLEWARE_CLASSES 作为列表中的最后，
- 在管理模块中配置示例页面。
简单地讲一下文档中关于平面配置的内容。
我感到很无助。不知道如何调试这个问题。对此有什么想法吗？
当然，感谢您的帮助。
感谢 Peter 的建议，我成功地将问题范围缩小到了 satchmo 商店的 urls.py 文件。
urlpatterns 只有一个条目：
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
此版本不起作用，而且会干扰平面页面。但是，从 MIDDLEWARE_CLASSES 禁用平面页面并将其添加到 urls.py 中，就像下面的代码片段一样有效：
(r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'),
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
但是下一个问题是从 / 到 /shop/ 的重定向。使用上述配置会导致无限循环。
也许您知道该行为的原因（重定向覆盖平面），也许您可以建议一些解决此问题的可行解决方案，或者应该如何处理对 / 的请求。
I'm having a problem with configuring Flatpages in Satchmo. I've used them before, in a pure django app, but now it just doesn't work, returning 301 http error when I'm trying to enter a flatpage-configured site.
What I've done to configure it:
- added the middleware "django.contrib.flatpages.middleware.FlatpageFallbackMiddleware" to MIDDLEWARE_CLASSES as last in the list,
- configured example pages in admin module.
Simply what the docs say about flatpages config.
I'm feeling helpless. Don't know how could I debug this issue. Any thoughts on that?
And of course help appreciated.
Thanks to suggestion by Peter I've managed to narrow the problem to my urls.py file, for the satchmo shop.
The urlpatterns has only one entry:
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
This version does not work and moreover interfere with flatpages. But disabling flatpages from MIDDLEWARE_CLASSES and adding it to urls.py like the snippet below works:
(r'^(?P<url>.*)
However next problem is with the redirection from / to /shop/. With the above config it results in infinite loop.
Perhaps you know the reason for that behavior (redirect overriding flatpage) and maybe You could suggest some working solution to this problem or what should be done with requests to /.
, 'django.contrib.flatpages.views.flatpage'),
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
However next problem is with the redirection from / to /shop/. With the above config it results in infinite loop.
Perhaps you know the reason for that behavior (redirect overriding flatpage) and maybe You could suggest some working solution to this problem or what should be done with requests to /.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
返回301？那是页面永久移动（HttpResponsePermanentRedirect），并且在 flatpages 目录中没有对此的引用，所以我认为它不是来自那里。事实上，在所有标准 1.1.1 版本中，大约只有 5 次引用
HttpResponsePermanentRedirect。可能的方法：
当提出这样的问题时，最好通过显示 settings.py（或其他内容）的适用部分的确切代码并提供其他内容（例如精确的 URL 和 urls.py 模式）来变得非常具体。正在尝试匹配。
更新：
好的，一些随机的想法：
模式
(r'^(?P.*)$', 'django.contrib.flatpages.views.flatpage' ), 将匹配任何内容。它后面的任何模式都将永远不会被看到。flatpages不能通过直接调用来工作，它在中间件中发挥其魔力。它会查找 404 响应（找不到页面），然后查看该路径是否存在于其表中。如果是这样，它会调用一个渲染页面的视图，等等。如果它找不到匹配，它会让 404 继续通过中间件处理。模式
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),将匹配任何内容（我刚刚测试过）。如果要匹配空路径，请使用r('^$', etc.)。这是无限循环的来源。如果您不熟悉正则表达式，那么 Django urls.py 文件看起来就像 F*cking Magic。我建议从非常简单的开始，一次添加一条规则。进行一些快速测试，以确保新规则 a) 匹配您希望它匹配的内容，以及 b) 不匹配它不应该匹配的内容。特别是，请确保文件中稍后出现的一些规则仍然可以访问。在这种情况下，他们就不会这样做，这应该会引发危险信号。
It returns 301? That's Page Moved Permanently (HttpResponsePermanentRedirect) and there are no references to that in the flatpages directory so I don't think it's coming from there. In fact there are only about 5 references to
HttpResponsePermanentRedirectin all of the standard 1.1.1 release.Possible approaches:
When presenting a problem like this it's better to get very specific by showing the exact code from applicable portions of settings.py (or whatever) and by giving other things like precise URLs and the urls.py patterns you are trying to match.
Update:
OK, some random thoughts:
The pattern
(r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'),will match anything. Any patterns after it will never be seen.flatpagesdoesn't work by being called directly, it does its magic in middleware. It looks for 404 responses (Page Not Found) and then looks to see if that path exists in its table. If so, it calls a view that renders the page, etc. etc. If it doesn't find a match it let's the 404 continue on through middleware processing.The pattern
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),will match anything (I just tested it). If you want to match an empty path, user('^$', etc.). This is the source of your infinite loop.If you are new to regular expressions the Django urls.py file can seem like F*cking Magic. I recommend starting very simply and add one rule at a time. Do some quick tests to ensure that the new rule a) matches stuff you want it to match, and b) doesn't match stuff it shouldn't. In particular, make sure that some of the rules that occur later in the file are still reachable. In this case they wouldn't have been which should have raised a red flag.