On the topic of the root directory
Despite all my tricks and attempts to make the site on the djanga catalog-independent, I still came across a rake buried in the dzhang itself.
Let me remind you, all the fuss due to the fact that the customer (and mine) has the root directory of the site is not always the root directory of the domain. Those. The first page of a site is often located at site / dj , for various technical reasons. The most common one is that the customer has some modules in PHP that are on the same server and are also needed.
The ambush lies in the fact that in templates and httpredirects it is necessary to specify the full paths to the pages. And if this path is still understandable inside the jungle itself (although I consider the need to specify the full path to the page from the view with httpredirect ugliness), then the root directory can change. And then shoveling all the code to fix it will be sad.
I found the following solution: in settings.py the variable ROOT = '' is written and a small templatetag:
root.py is written:
and that’s it. Now in the templates after {% load root%} we write at the beginning of each path {% root%} and we get what we wanted. In viewax, respectively, we use settings.ROOT for the same purpose. The
trouble came from where they did not wait. It turned out that in the bowels of the dzhangovsky auth there is a path '/ accounts / login', nailed by nails, to which requests are redirected if authorization is necessary. There are two ways out at the moment: either do not use standard decorators to check if the user is logged in (which is inconvenient), or hack the jung itself. So far I have taken the second path, but this is wrong.
I added the line in django / contrib / auth / __ init__.py
and added to settings.py
Let me remind you, all the fuss due to the fact that the customer (and mine) has the root directory of the site is not always the root directory of the domain. Those. The first page of a site is often located at site / dj , for various technical reasons. The most common one is that the customer has some modules in PHP that are on the same server and are also needed.
The ambush lies in the fact that in templates and httpredirects it is necessary to specify the full paths to the pages. And if this path is still understandable inside the jungle itself (although I consider the need to specify the full path to the page from the view with httpredirect ugliness), then the root directory can change. And then shoveling all the code to fix it will be sad.
I found the following solution: in settings.py the variable ROOT = '' is written and a small templatetag:
root.py is written:
from django.template import Library
register = Library ()
register .simple_tag
def root ():
"" "
Returns the string contained in the setting ROOT.
" ""
try:
import settings
except ImportError:
return ''
return settings.ROOT
and that’s it. Now in the templates after {% load root%} we write at the beginning of each path {% root%} and we get what we wanted. In viewax, respectively, we use settings.ROOT for the same purpose. The
trouble came from where they did not wait. It turned out that in the bowels of the dzhangovsky auth there is a path '/ accounts / login', nailed by nails, to which requests are redirected if authorization is necessary. There are two ways out at the moment: either do not use standard decorators to check if the user is logged in (which is inconvenient), or hack the jung itself. So far I have taken the second path, but this is wrong.
I added the line in django / contrib / auth / __ init__.py
if hasattr (settings, 'LOGIN_URL'): LOGIN_URL = settings.LOGIN_URL
and added to settings.py
LOGIN_URL = '% s / login /'% ROOT