具有apache + mod_wsgi（带有ubuntu的Amazon EC2服务器）的单个域上的Django-CMS和LFS

Question

I have some difficult to install multiple projects Django on a single domain. I want to run Django-CMS and LFS on same domain :

• mydomain.com (django-cms)
• mydomain.com/store (LFS)

For the time being, I can access to the two domains with the correct django-project without problem however in the LFS project all shop's links redirect to the first domain. For example, the cart link redirect to mydomain.com/cart instead of mydomain.com/store/cart .

I tried to change the url.py file by adding "store/" in all url patterns but it doesn't work. I think I have to add a configuration in the settings.py of the LFS project but I don't know what.

Have you some ideas ? Thanks ! :)

PS: here my httpd.conf

Alias /store/static /home/ubuntu/lfs-installer/lfs_project/sitestatic/

<Directory /home/ubuntu/lfs-installer/lfs_project/sitestatic>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias /store /home/ubuntu/lfs-installer/apache/django.wsgi


Alias /static /home/ubuntu/lfs-installer/selmyrtech/static/

<Directory /home/ubuntu/lfs-installer/selmyrtech/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /home/ubuntu/lfs-installer/selmyrtech/apache/django.wsgi

Answer 1

Django does not always play too nicely in a subdirectory--even in a situation where it is the only Django project on the domain. I had thought the docs recommend against this, but I was not able to find that page after a quick search

One of the problems may be here:

WSGIScriptAlias / /home/ubuntu/lfs-installer/selmyrtech/apache/django.wsgi

It would appear that this directive possibly maps all URI segments under / to this particular WSGI script, overriding the /store alias. Reversing the order of your script aliases may or may not clear up this problem.

Is it possible to rethink your URL convention to offer the 'store' area from a subdomain, like store.mydomain.com/cart?

If so, this may be a better supported structure and the two projects can have isolated Apache processes and WSGI scripts.

The other solution would be to see about integrating the two projects together into a single Django project. I don't know what your particular use-cases are that may prevent you from going this route or what unique challenges this may present, but this may be especially helpful to users if both projects will use authentication.