Community site: login faq

First, you guys are awesome. I really like your service!

OK--on to the question. I would prefer not to have anything in my URLs indicating whether they are run via django or not. Currently what I am thinking about is:

/ - attached to WordPress
/url1 - explicitly attached to Django
/url2 - explicitly attached to Django
/url3 - explicitly attached to Django in the website "contents" mappings

I can successfully map these different URLs to the same Django application (yay!).

However, Django does not get the "full" path for the URL--webfaction appears to remove the "root" URL and pass what's remaining to the application. (For example, if you go to "/url1" then Django runs but it thinks the URL is "/".) Under most circumstances this is ideal. In my case, though, I'd like to get the full URL ("/url1" or "/url2") so that Django can serve the appropriate content without me needing to create a bunch of Django webfaction applications.

I don't understand what webfaction does between the user's request and when the request is parsed by webapps/django/apache2/conf/httpd.conf . Is there any way I can get the full URL passed to django, rather than just the stem?

Yours, John B.

asked 15 Jan '13, 12:02

accept rate: 0%

edited 15 Jan '13, 12:04

This happens because your Django app is actually running at the root your back-end Apache instance.

The usual solution to this is to use FORCE_SCRIPT_NAME in your Django settings: Mounting a Django Application on a Subpath

In your situation, you're serving the same app on different paths, so I'm not sure if this will work for you. If each URL is serving a different project, each with its own settings, then it might.

If not, then you might be able to get the URL mappings you need by doing it in your httpd.conf instead of via our control panel, eg:

  • Delete the /url1, /url2, and /url3 mappings from your site configuration in the control panel.
  • Create additional WSGIScriptAlias directives in your httpd.conf, one for each URL path that you need mapped.

Hope that helps!

permanent link

answered 15 Jan '13, 14:24

accept rate: 37%

Sean, thank you.

Which httpd.conf would I edit? The only one I see is in ~/webapps/django/apache2/conf/httpd.conf.

Basically, I don't understand where the WSGIScriptAlias statements would go, because the ~/webapps/django/apache2/conf/httpd.conf file's scriptalias is

WSGIScriptAlias / /home/<<my_username>>/webapps/django/myproject/myproject/wsgi.py

and that conf file thinks "/url1" etc is "/".

(16 Jan '13, 11:07) borwick

If your Django app is named 'django' then the correct file is ~/webapps/django/apache2/conf/httpd.conf.

If all of your various /urlN paths will be serving the same Django project, I think you'll probably want something like this:

WSGIScriptAlias / /home/<<my_username>>/webapps/django/myproject/myproject/wsgi.py
WSGIScriptAlias /url1 /home/<<my_username>>/webapps/django/myproject/myproject/wsgi.py
WSGIScriptAlias /url2 /home/<<my_username>>/webapps/django/myproject/myproject/wsgi.py
WSGIScriptAlias /url3 /home/<<my_username>>/webapps/django/myproject/myproject/wsgi.py

Another approach to consider would be to use Django's own URL mappings for this. I don't really know what your use case is, so use whichever approach fits.

Whichever approach you use, do be sure to remove the /urlN paths that you've created on your site record in our control panel.

(16 Jan '13, 11:16) seanf

OK--I've removed all the /urlN paths from the control panel, and added a couple of entries to the httpd.conf:

WSGIScriptAlias /url1 /home/<<my_username>>/webapps/django/myproject/myproject/wsgi.py WSGIScriptAlias /url2 /home/<<my_username>>/webapps/django/myproject/myproject/wsgi.py

Then I restarted apache.

However, http://<<my_domain>>/url1 does not get sent to django.

What should be in the control panel, besides the application "django" itself, to let webfaction know that Django is at all involved for this domain and it should read that config file? It's like the config file isn't read in because it's not associated with any web site.

(16 Jan '13, 11:52) borwick

Ah, apologies - I missed that you were not also serving your Django app on /. So, what's happening now is that your WordPress app is serving all of the requests.

My suggestion won't work unless you serve Django at the root of the site.

Can you let me know why you want to use URL mappings in this manner, instead of creating them with Django's URL dispatcher? Knowing this will help me (or someone else) come up with a workable solution for you.

(16 Jan '13, 11:59) seanf

Yes, exactly.

I would super duper love to use Django's URL dispatcher. However, I also want to use WordPress. Here is my use case:

I am starting a business web site, and I want to be able to use WordPress to get up and running quickly with the simple portions of the web site: a blog, an "about us" page, a list of services, etc. I understand WordPress and your simple installer is really great. It is also good for rapid prototyping while I'm still learning about my customers etc. I want WordPress to serve "/", "/about", "/contact", "/blog", and maybe a few other URLs.

However, over time I want to create Django services and "plug them in" to the web site. For example if people want to order service I may write an order tool that lets them schedule a time on a calendar etc. I do not want to develop PHP ever in my life, and I really like what I know of Django. So, I'd like to have, say, "/service/order" be a Django application to order service. Then later I might want "/feedback" to be another Django application, ideally all a part of one big Django project.

I am totally open to other ways of doing this as long as WordPress and Django are both in the mix and I don't have to compromise my URL structure to have application-specific stuff in it. (For example I don't want to have to put in "/d/" or "/wp/" because I don't think URLs should have any representation of the underlying technology in them.)

For reference, my desired set-up is something like:

/ - WordPress

/about - WordPress

/contact - WordPress

/other-default-WordPress-URLs e.g. wp-admin.php - WordPress

/hello - Django

/goodbye - Django

/services/a - WordPress

/services/order - Django

I guess you could say ideally I would have an overlay of the two URL structures.

(16 Jan '13, 12:29) borwick

Sort of wondering if a set up like this is possible: http://stackoverflow.com/questions/3128256/how-do-i-install-wordpress-in-a-django-subdirectory , using RewriteRules to send WordPress content to WordPress and sending the rest to Django.

(16 Jan '13, 12:32) borwick

We can think of two more possible solutions. First, you could try using the Forwarded-Request-Uri HTTP variable. This is a variable that our front-end Nginx server sets to include the $request_uri before it initiates a proxy_pass to either Apache or your Django instance. This should be a clean solution, but will require some logic in your Django application to handle this before it hits your URLconf.

The other option is to put your wordpress app on the root of the domain, and don't mount the Django app on the site at all. You then should be able to use proxy rewrites (in a root-level .htaccess file) to send specific URLs to django on as needed (with "WSGISCriptAlias /services/order /path/to/wsgi.py" to catch it on the Django side).

Do either of these seem feasible?

(17 Jan '13, 00:56) ryans ♦♦

Excellent. I'm sure both would work, but I just successfully tried option #2! Thank you!

Notes in case anyone else is trying to do this...

  • on the Django-side, the WSGIScriptAlias is from "/", i.e. all URLs (that get to the proxy) are sent to Django.

  • put these rules at the TOP of your WordPress .htaccess file. "[L]" in a RewriteRule means "last", and WordPress uses a default rule to generate the 404 page. Your rules need to be above their rules

Here are the rules I added to the top of the file:

# ":NNNNN" is the django port number

RewriteEngine On

RewriteBase /

RewriteRule ^hello(/.*)?$$1 [P]
(17 Jan '13, 12:19) borwick
showing 5 of 8 show 3 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 15 Jan '13, 12:02

question was seen: 7,220 times

last updated: 17 Jan '13, 12:24