Django's Satchmo and flatpages issue - django

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>.*)$', '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 /.

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 HttpResponsePermanentRedirect in all of the standard 1.1.1 release.
Possible approaches:
Comment out the FlatPages middleware and see if the error changes (I'm betting it won't).
Try changing the order of your MIDDLEWARE classes and see if things change.
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.
flatpages doesn'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, use r('^$', 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.

Related

Django urlconf fails to resolve valid regex

I'm experiencing problems in routing urls to views in Django. Specifically, I use URLs with the pattern:
url(r'^(?P<id>[A-Za-z0-9\ ]+)/(?P<subid>[A-Za-z0-9\ ]+)/managetables$', views.compiledata, name='compiledata')
An example url would be My data/current/managetables. I checked that the regex returns the expected captured groups on www.pyregex.com (example)
However, actually visiting the url does not result in the view being called. Most importantly though, it works for a highly similar url:
url(r'^(?P<id>[A-Za-z0-9\ ]+)/(?P<subid>[A-Za-z0-9\ ]+)/managetab$', views.compiledata, name='compiledata')
If I visit My data/current/managetab the view is called as expected. Additionally, appending a "/" in the urlconf works also - but it is not clear to me why, i.e.:
url(r'^(?P<id>[A-Za-z0-9\ ]+)/(?P<subid>[A-Za-z0-9\ ]+)/managetables/$', views.compiledata, name='compiledata')
and visiting My data/current/managetablesresults in a redirect to My data/current/managetables/which calls the view.
I appreciate any hints how to solve this issue.
Ok, whereas the problem did manifest only on one of two machines, the hint to slugify the urls solved the issue. For anybody encountering similar issues, more information on slugify can be found here:
Tango with Django's Chapter 7, as well as in the Django Documentation.

Django reverts to default urls

I'm working with Django 1.6.4 and I've constructed a login system that appears to be working up until the back button is pressed in the browser. The URL giving me fits is http://127.0.0.1:8000/login. Here is my project URLconf:
urlpatterns = patterns('',
(r'', include('apps.mylogin.urls')),
)
(Before any of you Django veterans point out the empty regex pattern :) – I've tried a number of different ones that have been suggested on the interwebs: ('^', '^$'), and even tried moving the app's URLconf into the project's URLconf and all of them seem to yield this error. Of course if you detect shenanigans in this code, feel free to point it out, I like best practices :D)
The URLconf contained in the include is as follows:
urlpatterns = patterns('apps.mylogin.views',
url(r'^login/$', 'login', name='login'),
url(r'^logged_in/$', 'logged_in', name='logged_in'),
)
Let's say I land on the login page and I don't enter any information, I just click submit; the LoginForm class that I've created will (during the clean method) return a raise ValidationError. Everything works as expected: all the appropriate errors are displayed to the user and life is peachy... until I hit the back button. It is at this point I'm presented with a captured 404 page that says it was a GET request sent to http://127.0.0.1:8000/login with the following read out:
Using the URLconf defined in myproject.urls, Django tried these URL patterns, in this order:
^admin/
^account/
The current URL, login/, didn't match any of these.
I'm assuming these URLs are some part of a 'base' set defined by Django; which is well enough and all, but I'm quite curious as to why it appears to have forgot my URLs and suddenly can't find the location I was just at.
Any help would be greatly appreciated and if there is any additional information required please let me know and I'll attempt to edit this question to reflect it.
After yet additional testing and thought on the matter it appears that there is a conflict of caching mechanisms. It appears the conflict is produced when using certain Safari extensions, causing what appeared to be an injection of information; when in reality it was using code from several tutorials that had run before it.
I've arrived at this conclusion by testing Chrome, Firefox and Safari all without any extensions or enhancements beyond their default configuration. It is only when I return to Safari and enable a specific extension (and what is more absurd is that this particular extension does not inhibit my desktop ... it might be likely that there are additional extensions working in conjunction to cause this) that I receive the captured 404 error along with the seemingly injected ^account/.

URL.py in Django unexpected behaviour

I've configured url.py as is explained in different places of the Django documentation, but its behaviour is completely anomalous, between consecutives acceses. In Debug Mode and after looking for an url I get the "Page not found" error. The strange thing is that between acceses the error given is different:
... Django tried these URL patterns, in this order:
^admin/?$
^cheqsim/?$
^login/?$
^logout/?$
^questions/?$
But if I look at url.py my last element is ^searchquestions/?$ and I had restarted the server before looking at it, but the error is indicating me a different urlpattern from the actual in url.py.
Then I keep looking URLs and when I delete all the cookies and I try some non-existent URL I get the actual URL.py:
, Django tried these URL patterns, in this order:
^login/?$
^logout/?$
^admin/?$
^cheqsim/?$
^searchquestions/?$
Ok, so now I try http://mysite.com/myprojecturl/searchquestions/ and voila! It appears a new pattern error that leave me completely knock out:
, Django tried these URL patterns, in this order:
^admin/?$
^cheqsim/?$
^login/?$
^logout/?$
A pattern that I had used like 5 or 6 hours ago!!!
Please, do anybody have any idea of what is happening to me because this is really frustrating...
Thank you very much
P.S.: By the way, some URLs matches sometimes magicly
Check if you have multiple runserver instances running.
Check the ROOT_URLCONF setting
It seems the solution is changing the project.wsgi file and is well explained here: http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Anyway only time will know... xD

404 error: no user matches the given query?

I am busy with my group profile app and whenever i click on the create_group link i get this error instead of the create_group page. I think the problem may be in my URLS.PY file, has anybody ran into this problem. I am at work so will post some code in a few hours.
UPDATE:
The issue was in my URLS.py project file, i guess it wasn't syncing well with my urls.py app file. Such a small issue but it was really frustrating. Thats the life of a newbe!
I had same problem. URL localhost:8000/admin/auth/user/add/ created 404. Solution was obvious after I first found it.
My accounts app had missing ^ in accounts/url.py:
urlpatterns = patterns('',
url(r'user/(?P<username>\w+)/$', 'accounts.views.profile')
)
So I fixed it:
urlpatterns = patterns('',
url(r'^user/(?P<username>\w+)/$', 'accounts.views.profile')
)
The original matched with .../user/add/ before admin urls.py and caused the 404.
This is a very vague question, and without your code it's almost impossible to answer you correctly. However, I'll take a stab at it. It seems to me that you may be using the get_object_or_404 method in your view? Or is this an admin view? Either way, the answer is the same: You have a group profile and a reference to a user from that group that doesn't exist. It seems like you may just have data inconsistencies in your DB. I may be way off, it's hard to tell with so little information. If you give me more information to work off, I'll amend my answer to give you a more complete response.
One thing I can tell you for sure is that is NOT a missing URL error message. That error message is sending a 404 back because it can't retrieve an object from the DB. This would occur after the URL pattern was matched. However, I guess it's also possible that it's a user session issue, where you were logged in with a user that no longer exists, but that's just conjecture.
Good luck!

Django catch-all URL without breaking APPEND_SLASH

I have an entry in my urls.py that acts as a catch-all which loads a simple view if it finds an appropriate page in the database. The problem with this approach is that the URL solver will then never fail, meaning that the APPEND_SLASH functionality won't kick in - which I need.
I'd rather not have to resort to adding a prefix to the static page URLs to stop it being a catch-all. I do know about flatpages, which uses a 404 hook rather than an entry in urls.py, and I had kinda hoped to avoid having to use it, but I guess this problem might be exactly the kind of reason why one would use it.
Any way round this problem or should I just give in and use flatpages?
Make sure that your catch-all URL pattern has a slash at the end, and that the pattern is the last in your URLconf. If the catch-all pattern doesn't end with a slash, then it will match stray URLs before the middleware tries appending a slash.
For example, use r'^.*/$' instead of r'^.*' as your last pattern.
To do the same, but pass the url to the view as a named argument, use r'^(?P<url>.*)/$'.
The statement if it finds an appropriate static page in the database seems like your static pages are not quite static so, you either pass your links through urls.py (just like you do now), or you extract those pages from the DB, put them in a directory and configure that directory as one for serving static files