Problème de Satchmo et flatpages de Django

Question

Je rencontre un problème avec la configuration de Flatpages dans Satchmo. Je les ai déjà utilisés, dans une application django pure, mais maintenant ça ne marche pas, renvoyant une erreur HTTP 301 quand j'essaye d'entrer dans un site configuré pour flat-page.

Ce que je l'ai fait pour le configurer:

• ajouté le middleware "django.contrib.flatpages.middleware.FlatpageFallbackMiddleware" à MIDDLEWARE_CLASSES en dernier dans la liste,
• pages par exemple configurées dans le module d'administration .

Tout ce que disent les docs à propos de la configuration de flatpages.

Je me sens impuissant. Je ne sais pas comment pourrais-je déboguer ce problème. Des pensées à ce sujet?

Et bien sûr, aide appréciée.

Grâce à la suggestion de Peter, j'ai réussi à réduire le problème à mon fichier urls.py, pour la boutique satchmo.

Le urlpatterns n'a qu'une seule entrée:

(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}), 

Cette version ne fonctionne pas et d'ailleurs interférer avec flatpages. Mais la désactivation flatpages de MIDDLEWARE_CLASSES et l'ajouter à urls.py comme l'extrait ci-dessous œuvres:

(r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'), 
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}), 

Cependant problème suivant est la redirection de / à /shop/. Avec la configuration ci-dessus, il en résulte une boucle infinie. Peut-être connaissez-vous la raison de ce comportement (redirection rediriger flatpage) et peut-être que vous pourriez suggérer une solution de travail à ce problème ou ce qui devrait être fait avec les demandes à /.

Answer 1

Renvoie 301? C'est Page déplacée en permanence (HttpResponsePermanentRedirect) et il n'y a aucune référence à cela dans le répertoire flatpages donc je ne pense pas que cela vient de là. En fait, il n'y a qu'environ 5 références à HttpResponsePermanentRedirect dans l'ensemble de la version 1.1.1 standard.

approches possibles:

1. Commentez le middleware Flatpages et voir si les changements d'erreur (je parie qu'il ne sera pas).
2. Essayez de changer l'ordre de vos cours MIDDLEWARE et de voir si les choses changent.

Lors de la présentation d'un problème comme celui-ci, il est préférable d'obtenir très spécifique en montrant le code exact de parties applicables de settings.py (ou autre) et en donnant d'autres choses comme les URL et les motifs de urls.py précis vous essayez de faire correspondre.

Mise à jour:

OK, quelques réflexions au hasard:

1. Le motif (r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'), fera tout match. Tous les modèles après il ne sera jamais vu.

2. flatpages ne fonctionne pas en étant appelé directement, il fait sa magie dans le middleware. Il recherche 404 réponses (Page Not Found) et cherche ensuite à voir si ce chemin existe dans sa table. Si oui, il appelle une vue qui rend la page, etc etc Si ne trouve pas une correspondance il laisse le 404 continuer à travers le traitement middleware. Le modèle (r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}), correspond à n'importe quoi (je viens de le tester). Si vous voulez faire correspondre un chemin vide, utilisez r('^$', etc.). C'est la source de votre boucle infinie.

Si vous êtes nouveau dans les expressions régulières, le fichier urls.py de Django peut ressembler à F * cking Magic. Je recommande de commencer très simplement et ajouter une règle à la fois. Effectuez quelques tests rapides pour vous assurer que la nouvelle règle a) correspond aux éléments que vous voulez qu'elle corresponde, et b) ne correspond pas à ce qu'elle ne devrait pas contenir. En particulier, assurez-vous que certaines des règles qui apparaissent plus tard dans le fichier sont toujours accessibles. Dans ce cas, ils n'auraient pas été ce qui aurait dû déclencher un drapeau rouge.