Being a Django monkey, I’d like to share some tips on how to make WordPress and Django live together:

URL mapping

To make WordPress and Django co-exist, they should map to different parts of the url space: you can simply configure them to respond on different virtual hosts, or just map WordPress to a specific path. For instance, if your webserver is Apache and you’re serving Django through mod_wsgi, you can use a config snippet like this:

<VirtualHost *:80>
ServerName somehost.com
ServerAdmin hostmaster@somehost.com
ErrorLog /path/to/somehost.com/log/error.log
CustomLog /path/to/somehost.com/log/access.log combined
DirectoryIndex index.html
DocumentRoot /var/empty
WSGIScriptAlias / /path/to/somehost.com/parts/wsgi/wsgi
WSGIDaemonProcess somehost.com user=www group=www threads=25
WSGIProcessGroup somehost.com
Alias /blog/ /path/to/somehost.com/wordpress/
Alias /media/ /path/to/somehost.com/project/media/

<Directory /path/to/somehost.com/wordpress/>
Order allow,deny
Allow from all
</Directory>

<Directory /path/to/somehost.com/media/>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Accessing data

To share data between your WordPress blog and your Django instance, you have two three main options:

1. Save your WordPress tables and your Django models in the same database and configure your Django models accordingly.
   Pros: this approach is very straightforward and you don’t need to learn WordPress API. You can use Django admin interface to edit your WordPress database.
   Cons: sharing a database between two applications can have an impact on maintenance issues. For example, to rehash your Django application, you can’t just drop database, re-create it and populate with syncdb. WordPress database schema can change in new releases and make your ORM mapping obsolete.
2. Use Python’s xmlrpclib in Django to access WordPress XML-RPC interface.
   Pros: API changes won’t possibly break compatibility with previous releases. XML-RPC adds more logic, which means more consistency checks and more behind-the-curtain processing.
   Cons: XML-RPC calls are not as performant as direct access to MySQL.
3. UPDATE: Doug pointed me to another method: adding a PHP template loader to Django. An useful video tutorial is also available.

To setup method 1, you can use models.py from django-wordpress-admin project, which was built around inspectdb output with some custom manager enhancements. On GitHub there’s another project named django-wordpress, with the same approach and a step-by-step tutorial is published at uswaretech.com.

If you found Django-Wordpress integration tips useful, please drop a note in the comment box below to say how you used it, or just stay in touch with Twitter or RSS Feed for more Django stories.

UPDATE: For more performance info, James Abley pointed me to a very complete benchmark of available Python asynchronous webservers. It looks like Tornado is a real monster of concurrency.

There are already some how-to’s on the web on plugging Django web framework into Tornado webserver. A quick recap:

1. A tutorial on Tornado, Django and nginx by Jeremy Bowers.
2. How to import django framework inside a Tornado project by Lincoln Loop.
3. A snippet by lawgon.

My approach is slightly different as I wanted to run Tornado using Django management command-line interface.

The 3 easy steps are:

1. Add Tornado module to your django setup. If you use buildout, add Tornado git checkout to buildout.cfg using minitage.recipe.fetch recipe, like this:

   [buildout]
   ...
   parts =
   ...
       tornado
       django
   ...
   
   [tornado]
   recipe = minitage.recipe.fetch
   urls = git://github.com/facebook/tornado.git | git | | ${buildout:parts-directory}/tornado
   
   [django]
   recipe = minitage.recipe.scripts
   initialization =
       import os
       os.environ['DJANGO_SETTINGS_MODULE']='project.settings.development'
   scripts =
       django
   eggs =
       Django
       ...
   entry-points=
       django=django.core.management:execute_from_command_line
   extra-paths =
       ${buildout:directory}
       ${tornado:location}
   ...

2. Next, create a command-line extension hierarchy in your project’s main app:

   $ mkdir project/myapp/management
   $ touch project/myapp/management/__init__.py
   $ mkdir project/myapp/management/commands
   $ touch project/myapp/management/commands/__init__.py

3. Last, add a runtornado.py script in project/myapp/management/commands/ folder with the following content:

   from django.core.management.base import BaseCommand, CommandError
   from optparse import make_option
   import os
   import sys
   
   class Command(BaseCommand):
       option_list = BaseCommand.option_list + ()
       help = "Starts a Tornado Web."
       args = '[optional port number, or ipaddr:port]'
   
       def handle(self, addrport='', *args, **options):
           import django
           from django.core.handlers.wsgi import WSGIHandler
           from tornado import httpserver, wsgi, ioloop
   
   	sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
   	sys.stderr = os.fdopen(sys.stderr.fileno(), 'w', 0)
   
           if args:
               raise CommandError('Usage is runserver %s' % self.args)
           if not addrport:
               addr = ''
               port = '8000'
           else:
               try:
                   addr, port = addrport.split(':')
               except ValueError:
                   addr, port = '', addrport
           if not addr:
               addr = '127.0.0.1'
   
           if not port.isdigit():
               raise CommandError("%r is not a valid port number." % port)
   
           quit_command = (sys.platform == 'win32') and 'CTRL-BREAK' or 'CONTROL-C'
   
           def inner_run():
               from django.conf import settings
               print "Validating models..."
               self.validate(display_num_errors=True)
               print "\nDjango version %s, using settings %r" % (django.get_version(), settings.SETTINGS_MODULE)
               print "Server is running at http://%s:%s/" % (addr, port)
               print "Quit the server with %s." % quit_command
               application = WSGIHandler()
               container = wsgi.WSGIContainer(application)
               http_server = httpserver.HTTPServer(container)
               http_server.listen(int(port), address=addr)
               ioloop.IOLoop.instance().start()
   
           inner_run()

To run your tornado webserver, you just need to call your usual management program like manage.py with runtornado command, with the same syntax as runserver. In my case, I just run production server using supervisord, with a command like this:

$ ./bin/django runtornado --settings=project.settings.production 8000

If you found this quick how-to useful, remember to follow me on Twitter or subscribe to my feed for more django tips.