RobYates.org

Recently, I was tasked with building an application to be used by several clients in which everyone used a single codebase and database, but they could provide their own “lingo” for how form fields would show in the application. So if one of the model attributes was “department”, one client may refer to that as “group” whereas another might refer to it as “gaggle”.

My initial thought was to use Django’s fantastic i18n and localization features to provide separate translations for each client, but Django’s i18n support is truly supported for user-based locales and not some other arbitrary attribute of the user such as what company they work for.  Since I couldn’t find a solution, I decided to put together an app I call django-lingo which provides a simple LabelCustomization model that ties a user to a set of label customizations as well as a form that you can extend in lieu of ModelForm that properly displays the customized labels if there are any.  If no label customizations exist for a given field or a given user, the default field from the original model definition is used instead.

You can find django-lingo on Github here:

http://github.com/ryates/django-lingo/

What’s Next

Although tying the label customization to individual users worked for me (we only had one user per client using the application), it doesn’t hold up for many use cases so I intend to develop a more generic way to tie a set of label customizations to whatever group of folks that you want to see those customizations.  I’m happy to have suggestions.

Today, I ran across a scenario where a client found an old, dusty domain that they wanted to point to their existing production site.  Seems that this domain is managed by the predecessor to the predecessor to the current hosting provider (us) and they’ve been dutifully re-aiming it at a CNAME every time they migrate their site to a new provider.  When I learned of this domain and found out it was still pointing to their old website host, I gave them the information to create a CNAME to point to the new Drupal-based site.  What I didn’t consider is that we’re using Drupal’s multi-site feature to manage several Drupal sites under one set of code and modules.

Exactly how does it work?

Unfortunately, Drupal’s multi-site feature isn’t very flexible when it comes to domain mapping.  Drupal essentially tries to match on the most-specific host name provided to see which “site” should handle the request.

For example, if you had two directory in your Drupal “sites” directory of:

/sites/example.com/
/sites/www.example.com/

and you sent in a request to http://www.example.com, Drupal would broker the request to the site in the www.example.com directory.  However, if you only had one site and named it simply /sites/example.com/, Drupal is smart enough to send request to both http://example.com and http://www.example.com to the site in the example.com directory.

So what’s the problem?

The client wanted to essentially point http://oldexample.com and http://www.oldexample.com to the new site as well.  Since I hadn’t defined these as separate sites in Drupal-land (nor would I want to as I want the standard example.com site to handle the request), Drupal was kind enough to give me an error message stating that my site is offline.

Luckily, even though we front-end our web servers with Lighttpd as a reverse proxy, Apache handles the sites that have either PHP or Python code on them so we could leverage Apache’s uber-powerful mod_rewrite module. I was able to insert three lines into my Apache configuration (I could have put it in an .htaccess file as well) and tell Apache to re-write requests from oldexample.com to example.com so Drupal is no wiser that these requests came in from said old, dusty domain.

Here are the lines that did the trick:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www\.)*oldexample\.com
RewriteRule ^(.*)$ http://example.com/$1 [R=permanent,L]

The RewriteCond line will attempt to match the HTTP_HOST header variable value to either www.oldexample.com or oldexample.com.  If either of these conditions are true, then the URL is re-written to request http://example.com and append anything else that was on the URL (paths, files, or querystrings).  Now I have all domains properly pointing to the correct Drupal site and didn’t have to play games with additional Drupal modules or symbolic links on the server.

On October 17th of this year, I was offered the opportunity to present a Django talk at the Central Pennsylvania Open Source Conference (CPOSC).  This conference is hosted by our local Linux Users Group and I must say they did an absolutely fantastic job.  Representatives from many respectable organizations were there including RedHat, Ubuntu, and Anteil.  Because of the awesome support form sponsors, registration fees were quite low for participants and the end result was a sell-out crowd.

Continue reading »

Though I’m embarrassed to say NaBloPoMo out loud, November is National Blog Posting Month.  This blog has been up for quite some time and gotten no love from me so I’m going to make a an attempt at changing that this month.

As Django development is both my day job as well as my current technology passion, most posts will be oriented in that direction.  Wish me luck.

More about NaBloPoMo here: http://www.nablopomo.com/

I’m doing a talk tonight at the Central Pennsylvania Linux Users Group on using the Vera Z-Wave controller for Home Automation.

You can download the presentation here.