Is it acceptable to use two includes for the same base url routing schema?
e.g. - I have allauth installed which uses r'^accounts/', include('allauth.urls')
and I want to extend this further with my own app, which extends the allauth urls even further.
An example of this would be accounts/profile or some other extension of the base accounts/ url.
Is it fine to do the following?
r'^accounts/', include('myapp.urls')
In additon to:
r'^accounts/', include('allauth.urls')
As far as I can tell both will just be included with the base url routing schema and it will just look for the allauth urls first?
Yes, that is perfectly fine.
Django will look for a matching url in the first one, and if it doesn't find it, it will move on to the next one.
Related
When I try to render a html file in django project, I get this error, and I can't see the localhost page 'cause of this.
The error is:
NoReverseMatch at / Reverse for 'it_languages' not found. 'it_languages' is not a valid view function or pattern name.
and it languages is url for in html
Then it bolds me with yellow this:
Home
About Me
**IT-languages**
Projects
Contact
I expect to see my offline page rendered by django project
Should I keep it like the original html version:
Home
About Me
IT-languages
Projects
Contact
Please start by providing your urls.py, views.py, and the it_languages template.
As #cbirch said, it's impossible to exactly provide an answer without more information (preferably the code they listed).
In general, the error 'NoReverseMatch' happens when you are trying to refer to an endpoint by the name, but the name doesn't map to a provided endpoint.
When you create a route you add an entry to the urlpatterns list in urls.py (typically) - if you don't give them a specific name, they will be given an automatically generated name. Then in your template file, if you refer to one of these names, they have to match!
Probably you use { url it_languages } or similar in one of your templates, but you haven't set that as a name for a url.
If you install django-extensions, there's a tool (show_urls) that will allow you to list your endpoints and their names (I believe) - that may help you trace the issue down. Good luck!
I need to redirect my clients to another endpoint in my django app. I know I can use relative urls with request.build_absolute_uri() to do this, but I am searching for a generic solution that doesn't require the redirecting handler to know its own place in the URL hierarchy.
As an example, I have handlers at the following two URLs:
https://example.com/some/other/namespace/MY_APP/endpoint_one
https://example.com/some/other/namespace/MY_APP/foo/bar/endpoint_two
Both handlers need to redirect to this URL:
https://example.com/some/other/namespace/MY_APP/baz/destination_endpoint
I would like for endpoint_one and endpoint_two to both be able to use the exact same logic to redirect to destination_endpoint.
My app has no knowledge of the /some/other/namespaces/ part of the URL, and that part of the URL can change depending on the deployment (or might not be there at all in a development environment).
I know I could use different relative urls from each endpoint, and redirect to the destination URL. However, that required that the handlers for endpoint_one and endpoint_two know their relative position in the URL hierarchy, which is something I am trying to avoid.
After doing more research and talking with coworkers, I realized that reverse does exactly what I need.
I'm using django-allauth with Django 1.5.1 and I have a few questions when setting it up:
1. Configure urls.py
The docs says that you have to add the following to urls.py file:
urlpatterns = patterns('',
...
(r'^accounts/', include('allauth.urls')),
...
)
The problem is that I already have a custom app called accounts and I already use the following URL pattern:
(r'^accounts/', include('accounts.urls')),
So I have a naming collision here with the accounts/ regex URL. My question is: can I rename the allauth URL pattern to (r'^auth/', include('allauth.urls')) without having problems, or is it unsafe to do so and it'd be better to rename my own URL to something like (r'^users/', include('users.urls')) (and rename my accounts app to users for naming consistency).
2. Customize allauth default templates
What is the proper way to customize the default templates for login, etc.? I think that modifying the library directly is not the best approach. I guess it should be done through templates directory using some concrete directory hierarchy. Also, I don't know if some kind of base.html file must be provided to extend from when overriding these templates or the site's base.html that all pages extend can be used without problems. Could you illustrate me with this?
3. Admin login form shows logins and logouts the first time it's accessed
When I access the admin panel after some logins and logouts the history appears, but if I refresh the page then it disappears. I think this must be something related with the django messages:
4. Setting SOCIALACCOUNT_PROVIDERS
Is the dictionary setting called SOCIALACCOUNT_PROVIDERS optional or must it be set?
5. How is the password calculated when a user signs in with a 3rd party app?
When the user is created it has a password, but how is it calculated? And... is it useful or is it only a placeholder for this required field? Can the user use it to local login?
Thanks!
With respect to 1):
There is no collision as long as there is no overlap in the fully matched URL patterns. For example: if your accounts app has a match for "/accounts/login/" then there is indeed a collision as allauth is gunning for that URL as well. But, if your accounts app simply matches other URLs with /accounts/ as prefix then you are fine.
If you insist, you can indeed put allauth URLs below a different path. allauth uses name based URL reversal, so the new path prefix will be picked up automatically.
As for 2):
There is nothing special about allauth templates. You can override them just like you would for any other Django app.
Have a look at the example app. It has both Bootstrap and uniform template overrides. They can be enabled by uncommenting this line: https://github.com/pennersr/django-allauth/blob/901485557d4ddee30fed920f2159cdf499c39e1c/example/example/settings.py#L126
All allauth templates inherit from a base template, called base.html. I would expect that your project also has a base template. Either override the base.html with yours, or, override base.html with a template that extends from yourbase.html
3): allauth uses the Django messages framework. See:
https://docs.djangoproject.com/en/dev/ref/contrib/messages/#expiration-of-messages -- if you do not iterate over the messages in order to display them, they do not expire. So apparently you are not showing the messages in your templates. Therefore, they heap up until the admin appears which renders (and clears) all messages collected so far...
4) Optional
5) There is no password set, meaning, the user can only login using the 3rd party account until he actually sets a password (/accounts/password/set/).
I have a django app that has / at the end of every URL conf. Example:
# user home page
(r'^home/$', 'user_home_page'),
However, I'm noticing this is causing a ton of redirects on my server, because when people dont add the /, it redirects them. Is there any way to have it accept both without a redirect except doing:
# user home page
(r'^home$', 'user_home_page'),
(r'^home/$', 'user_home_page'),
or should I avoid URL confs like that?
While you can accept both without doing a redirect by using:
(r'^home/?$', 'user_home_page'),
It is not best SEO practice because it will look like you have duplicate content and your hits will be split between the two pages.
You could modify your APPEND_SLASH Django setting, I haven't used it before.
You may be wondering what happens if someone requests the URL /hello
(that is, without a trailing slash). Because our URLpattern requires a
trailing slash, that URL would not match. However, by default, any
request to a URL that doesn’t match a URLpattern and doesn’t end with
a slash will be redirected to the same URL with a trailing slash.
(This is regulated by the APPEND_SLASH Django setting, which is
covered in Appendix D.)
This was taken from http://djangobook.com/en/2.0/chapter03/
The patterns are Python regular expressions. How about:
(r'^home(/?)$', 'user_home_page'),
should I avoid URL confs like that?
Yes. Django already handles this for you.
See this: https://docs.djangoproject.com/en/1.3/ref/middleware/#module-django.middleware.common
If APPEND_SLASH is True and the initial URL doesn’t end with a slash,
and it is not found in the URLconf, then a new URL is formed by
appending a slash at the end. If this new URL is found in the URLconf,
then Django redirects the request to this new URL. Otherwise, the
initial URL is processed as usual.
Use Django REMOVE_SLASH middleware instead.
https://gist.github.com/2204099
https://gist.github.com/gists/2204099/download
You need to ensure your application uses / consistently, make a choice which to use, and 301 redirect the rogue variation to the correct canonical one.
There should only be one version of a page, and the correct solution is in most cases to 301 redirect to the canonical version.
In some situations with additional paramenters for tracking you should also define a canonical in the head.
By using consistent URLs within your APP and out on the web in links pointing back to your app, you then won't have lots of redirects.
I have a django site. Like all standard sites, it uses URLConfs to associate URLs with views. However, in addition to that, I have some URL configs which I dynamically generate from data in the database. Everything works as I would like it.
Is it possible to reload all the URLConfs while the site is running, from code? In case someone updates the database and change some of the URLs in the site, I would like to trigger a "rediscovery" of all the URLs. This would cause my code to dynamically re-create the URLs from the data in the DB.
Currently, the generated URLs can be anywhere in the URL hierarchy. They are not all under one prefix, such as /dynamic/ or such. However, if this is absolutely necessary to do what I need to get done, I can place all the dynamic URLs under one prefix.
Some downtime is allowed for the site while the rediscovery of URLs take place.
How would I trigger such a reloading of all the URLConfs?
Your question starts from a premise that most Django programmers wouldn't accept: that you can or should create URLs dynamically from the database. If you're doing that, you're doing it wrong.
Your URL patterns are part of the code, not the data. Obviously, the URLs themselves are formed by combining the patterns with the data - eg foo/<slug>/bar/, but this doesn't need reloading when new slugs are added because it is resolved by the view, not the URL processor.
import sys
from django.conf import settings
from django.core.urlresolvers import clear_url_caches
clear_url_caches()
reload(sys.modules[settings.ROOT_URLCONF])