Run Django with URL prefix ("subdirectory") - App works, but URLs broken?

Question

Below are the relevant configuration files, also at http://dpaste.com/97213/ .

The apache config is currently working, because accessing 'example.com/' shows me the index.html file I have placed at the document root.

I'd like to serve Django/apps at the prefix '/d', so 'example.com/d/' would load the default app, 'example.com/d/app3' would load another, as configured in urls.py.

Serving Django, I'm using the suggested mod_wsgi, on Linux.

Currently, I can access the Ticket app at 'example.com/d', but when the @login_required decorator tries to send me to the login page, I get sent to 'example.com/accounts/login', rather than the expected 'example.com/d/accounts/login'.

Since the default app loads correctly, I'm not sure what I'm doing wrong here, or if this is a bug in Django when generating the urls.

Any suggestions?

EDIT: As a note, if I change the apache config line: WSGIScriptAlias /d /home/blah/django_projects/Tickets/apache/django.wsgi to WSGIScriptAlias / /home/blah/django_projects/Tickets/apache/django.wsgi The application, commenting, and logging in all work fine. Even going to 'example.com/admin' loads the admin, although I've left the admin media broken, so no stylesheets are loaded.

--- Configs Follow:

#
# /home/blah/django_projects/Ticket/urls.py
#
from django.conf.urls.defaults import *
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    (r'^', include('ticket.urls')),
    (r'^admin/', include(admin.site.urls)),
    (r'^comments/', include('django.contrib.comments.urls')),
)


#
# /home/blah/django_projects/Ticket/apache/django.wsgi
#
import os, sys

sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..')

sys.path.append('/home/blah/django_projects')
sys.path.append('/home/blah/django_projects/Tickets')

os.environ['DJANGO_SETTINGS_MODULE'] = 'Tickets.settings'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()


#
# /etc/apache2/sites-available/django_tickets_wsgi (apache conf)
#
NameVirtualHost *
<VirtualHost *>  

    Alias /media /home/blah/django_projects/Tickets/media


    WSGIScriptAlias /d /home/blah/django_projects/Tickets/apache/django.wsgi
    WSGIDaemonProcess exmaple_com user=blah group=blah processes=1 threads=10
    WSGIProcessGroup example_com

    ServerAdmin [email protected]
    ServerName example.com

    DocumentRoot /var/www/

    <Directory /var/www/>
        Options -Indexes FollowSymLinks -MultiViews -Includes 
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>

    ErrorLog /var/log/apache2/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog /var/log/apache2/access.log combined
    ServerSignature Off

</VirtualHost>

Solution 1

This is a possible duplicate of Django Apache Redirect Problem, as that answer solved this problem.

I only eventually stumbled on that answer by opening almost all of the 'related questions' here, just out of desperation. From my perspective, I think my question has some valuable "search friendly" words.

EDIT: The answer: (via alex vasi)

Things to try:

1. Change current domain to "yourdomain.tld/cflow" in the "sites" framework. It's easy to do using django admin or dumpdata/loaddata manage.py commands.

2. Looks like your site is using login_required decorator. In that particular case you can add to settings.py:

   LOGIN_URL = '/[prefix]/accounts/login/'

Solution 2

In your urls.py rename urlpatterns to base_urlpatterns; then add the followinig definition at the end of the same file:

urlpatterns = patterns('',
    '^', include(base_urlpatterns), # iff you wish to maintain the un-prefixed URL's too
    '^your_prefix/', include(base_urlpatterns),
)

Comments

[David Berger]

Please don't delete your own question (for the reason you mentioned). I believe it is possible for an admin to undelete your post, but they probably won't even if it would have been better to have kept it around. But please do accept your own solution after the mandatory waiting period.

[Graham Dumpleton]

That sort of fiddle should not be needed and would certainly not recommend it as it implies then that have two URLs to same resource, which is bad practice.