Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We use apache, mod_php, and mod_wsgi to serve a central wordpress site, with some paths instead powered by Django, so for example these pages might be powered by Wordpress:

but these URL's might be Django-powered:

Right now, we use a long list of WSGIScriptAlias to map particular paths to Django. This annoying and labor intensive.

So, is there a way that we can configure things such that:

  • One or the other first attempts to handle the URL (I'm not too concerned) first
  • If that handler returns a 404, try the other one

I'm particularly interested in an Apache solution, but will consider alternatives.

share|improve this question

This is in response to your entertainment of alternatives.

I've hosted Django and WordPress on the same domain behind Nginx using php5-fpm for WordPress and relying on Nginx's X-Accel-Redirect to return undefined URLs to the WordPress upstream.

The Nginx configuration starts with known patterns which WordPress should handle: an index page, a few top-level content pages or top-level sections, and/or the pattern for blog posts. This means most WordPress URLs can be caught with a dozen or fewer URL patterns.

Everything else is routed to the Django upstream.

What about new pages or changes to the WordPress site? Rather than update the URL patterns for every WordPress page or section added, the Django app uses a custom 404 handler to redirect the request to the WordPress upstream.

def page_not_found(request):
    A 404 view that redirects to the WordPress installation.
        new_url = Redirect.objects.get(old_path=request.get_full_path())
    except Redirect.DoesNotExist:
        return redirect(new_url.new_path)

    if not settings.WORDPRESS_REDIRECT:
        return render(request, "404.html", {})

    response = HttpResponse()
    response['X-Accel-Redirect'] = '/wordpress/'
    return response

By redirecting the requests the redirect middleware won't "see" any 404 errors, so if you want to use the redirect feature it should be added here. The /wordpress/ location is defined as an internal location in the Nginx configuration.

  location /wordpress/ {
    try_files $uri $uri/ /index.php;

I've written a little bit more about using X-Accel-Redirects for this purpose, though I recognize this doesn't answer the specific question.

Hopefully it gives you some ideas of you could employ X-Sendfile to do something similar with mod_php and mod_wsgi.

share|improve this answer
Under this setup, couldn't you do without defining the Wordpress patterns? Is that just a performance benefit? – Ross M Karchner Mar 25 '13 at 19:53
Yes, to both questions. The redirect shouldn't be a big performance hit for the app, but I'd rather not send unnecessary requests to the app. The key is that only the "big" top level WordPress URL patterns are set up. – bennylope Mar 25 '13 at 20:07


Use the AddHandler/mod_rewrite method.

If a URL can't be handled by your PHP application because there is no corresponding .php file, it will fall through to your WSGI application.

share|improve this answer
That looks promising, I'll give it a try! Thank you. – Ross M Karchner Mar 25 '13 at 21:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.