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.

1. Blueprint CSS framework

While not a django-specific add-on, Blueprint CSS framework is a perfect companion for django template designers: it features cross-browser style reset, a 24-column grid layout, a nice looking typography and a print-friendly style.

2. django-uni-form

django-uni-form implements UniForm CSS framework in Django: you can render your forms as stylish xhtml-compliant divs using a simple template tag filter and add form layout information to your Form classes.

3. django-compress

Optimization of CSS and Javascript distribution can greatly improve web client rendering times: django-compress outputs concatenated and minified files and handles smart client-side caching.

4. django-userskins

Using django-userskins you can enable user-selected themes in your application.

5. django-tabs

For your navigation bar, you can use django-tabs to highlight active tab (possibly with multiple navigation layers), by combining Django template extension mechanism and a special template tag.

6. django-reversetag

Default url tag is quite primitive, but using reverse tag introduce by django-reversetag, you can resolve urls from variables and string literals, which is very useful if your view or named view is computed at run-time.

7. macros template tags

Django macros template tags help you apply DRY criterias in your templates, while maintaining separation between presentation and logic. Download macros.py and save it into your app’s templatetags folder.

8. smart_if template tags

smart_if template tag add-on replaces default if/else/endif tags with a custom version that allows basic yet useful value comparisons. Download smart_if.py and save it into your app’s templatetags folder.

Tip: original smart_if doesn’t support elif syntax. You can find amended version here.

*~
*.orig
*.pyc
*.rej
.installed.cfg
__minitage__*
bin/*
develop-eggs
downloads
eggs
log
parts
project/media/uploads
tmp

As usual, feel free to post your additions as comments.

UPDATE: Vinicius Mendes commented on using django.template.loaders.app_directories.Loader to solve the problem (a similar module exists for eggs, which is named django.template.loaders.eggs.Loader). It’s definitely the easiest way if you don’t mind importing all of your applications templates. Instead, if you need to pick only selected directories or non-standard directory names, keep on reading.

The solution is to add a dynamic path that is resolved at runtime using add-on egg’s path. Here’s an example of how I got django-reversion templates added:

import os
from  pyclbr import readmodule_ex

TEMPLATE_DIRS = (
    os.path.join(os.path.dirname(__file__), "../templates"),
    os.path.join(os.path.dirname(readmodule_ex('reversion')['__path__'][0]), "templates"),
)

In vanilla django, using “manage.py sql” or “manage.py sqlindexes” you can generate respectively “CREATE TABLE” and “CREATE INDEX” sql statements to setup your database schema (if you use manage.py syncdb, generated sql is feeded into your database). Table names are defined in db_table variable in model’s meta class and default name is generated using the following statement in django.db.models.options:

self.db_table = "%s_%s" % (self.app_label, self.module_name)

Now, if your generated db_table is greater than 64 characters (quite easy if your application name is long), django doesn’t truncate it and when sql is feeded into mysql, table creation routine will fail. A similar trouble happens for index creation routine (typically used with unique constraints) and using dmigrations tool instead of plain syncdb doesn’t get any better.

At this point, there are two options for table naming:

1. Renaming tables in models.py by hand (quite boring if your project is big).
2. Patching django to apply a truncation to db_table.

For option 2, here’s the simple one-liner patch you need for django 1.1.1:

--- django/db/backends/mysql/base.py.orig
+++ django/db/backends/mysql/base.py
@@ -214,6 +214,9 @@
         second = '%s-12-31 23:59:59.99'
         return [first % value, second % value]

+    def max_name_length(self):
+        return 64
+
 class DatabaseWrapper(BaseDatabaseWrapper):

     operators = {

In dmigrations, index names are defined as:

index_name = '%s_%s_%s' % (app, model, column)

You can fix the length problem in r29 with this simple patch:

--- dmigrations/mysql/migrations.py.orig
+++ dmigrations/mysql/migrations.py
@@ -141,7 +141,7 @@
     def __init__(self, app, model, column):
         model = model.lower()
         self.app, self.model, self.column = app, model, column
-        index_name = '%s_%s_%s' % (app, model, column)
+        index_name = '%s_refs_id_%s' % (column, abs(hash((app, model, column))))
         super(AddIndex, self).__init__(
             sql_up = [self.add_index_sql % (index_name, app, model, column)],
             sql_down = [self.drop_index_sql % (app, model, index_name)],