I have 2 urls which are kind of similar,
path('account/', views.register_login, name='register_login'),
path('account/<slug:user_slug>/', views.home, name='account'),
When I go to 127.0.0.1:8000/account/
I get redirected to the url with name account instead of to the one with name register_login.
How can I fix this?
EDIT:
Thank you so much for your answer, but turns out the issue was caused because of a slug on another application my friend implemented and I was unaware off.
I'm working on a core app so I don't use an appname, yet he's supposed to do so. We misunderstood each other and neither of us named our respective application hahahaha. So I was being redirected to his urls and his views...
Thank you so much everyone for your answer, but it turns out the issue was caused because of a slug on another application my friend implemented and I was unaware off.
I'm working on a core app so we said I wouldn't use an appname, yet he was supposed to do so. We misunderstood each other and neither of us named our respective application hahahaha. So I was being redirected to his urls and his views...
Related
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.
I am developing a project in Coldfusion with CFWheels MVC Framework with URL Rewriting enabled. It involves user registration and each user should be presented as username.domain.com instead of www.domain.com/users/username. Moreover once I am on username.domain.com all child pages should work as:
username.domain.com/page1
username.domain.com/page2
username.domain.com/search?k=xyz
... etc
which I am unable to achieve.
I have updated my DNS settings of the particular domain so that *.domain.com all point to the same host. What am I still doing? I found this configuration , but I have not figured out how to implement it.
Sorry this is more of an extended comment than an answer
The code has a name of coldfusion-subdomains.cfm but it looks like something that would go into application.cfc. If you look at https://github.com/cfmaniac/CF-SubDomains , it states
CF-Subdomains is a snippet of code (best used in your OnRequest Method of Application.cfc) to detect and include files from a subdirectory on your server and let it act like a subdomain.
So from here, I would go to the cfwheels documentation so see if it does anything special with OnRequest()
I don't see anything that wraps around OnRequest(), so maybe it can be used as is
You may also want to consider url re-writing instead
http://docs.cfwheels.org/docs/url-rewriting
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/.
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!
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.