It\u2019s possible to run a Django application on the same Web server as an application powered by another technology. The most straightforward way of doing this is to use Apache\u2019s configuration file, httpd.conf, to delegate different URL patterns to different technologies.<\/p>\n
The key is that Django will be activated for a particular URL pattern only if your httpd.conf file says so. The default deployment explained earlier assumes you want Django to power every page on a particular domain:<\/p>\n
<Location “\/”>
\nSetHandler python-program
\nPythonHandler django.core.handlers.modpython
\nSetEnv DJANGO_SETTINGS_MODULE mysite.settings
\nPythonDebug On
\n<\/Location><\/p>\n
Here, the <Location “\/”> line means \u201chandle every URL, starting at the root,\u201d with Django. It\u2019s perfectly fine to limit this <Location> directive to a certain directory tree. For example, say you have a legacy PHP application that powers most pages on a domain and you want to install a Django admin site at \/admin\/ without disrupting the PHP code. To do this, just set the <Location> directive to \/admin\/:<\/p>\n
<Location “\/admin\/”>
\nSetHandler python-program
\nPythonHandler django.core.handlers.modpython
\nSetEnv DJANGO_SETTINGS_MODULE mysite.settings
\nPythonDebug On
\n<\/Location><\/p>\n
With this in place, only the URLs that start with \/admin\/ will activate Django. Any other page will use whatever infrastructure already existed.<\/p>\n
Note that attaching Django to a qualified URL (such as \/admin\/ in this section\u2019s example) does not affect the Django URL parsing. Django works with the absolute URL (e.g., \/admin\/people\/person\/add\/), not a \u201cstripped\u201d version of the URL (e.g., \/people\/person\/add\/). This means that your root URLconf should include the leading \/admin\/.<\/p>\n\n\n