Skip to main content

The Tyee: Bricolage and Drupal Integration

The Tyee is a site I've been involved with since 2006 when I wrote the first, 4.7 version of a Drupal module to integrate Drupal content into a static site that was being generated from bricolage. About a year ago, I met with Dawn Buie and Phillip Smith and we mapped out a number of ways to improve the Drupal integration on the site, including upgrading the Drupal to version 5 from 4.7. Various parts of that grand plan have been slowly incorporated into the site, but as of next week, there'll be a big leap forward that coincides with a new design [implemented in Bricolage by David Wheeler who wrote and maintains Bricolage] as well as a new Drupal release of the Bricolage integration module.

Plans

Application integration is tricky, and my first time round had quite a few issues. Here's a list of the improvements in the latest version:

  • File space separation. Before, Drupal was installed in the apache document root, which is where bricolage was publishing it's content. This was dangerous and confusing because of the risk of Bricolage overwriting a Drupal file and vice-versa, and the mess that it left us for version control since bricolage versioning was best maintained within the bricolage application on another machine. So in the new version, Drupal is installed in it's own non-document root directory and Drupal pages are accessible via an Apache alias command like this:
    Alias /cms /var/www/drupal-dir
    This change also allows us to be more specific about which of the bricolage url get passed through Drupal, because that mechanism has it's own mod_rewrite rule, something like:
    RewriteRule ^(.*)\.html$ /index.php?fid=%{REQUEST_FILENAME}&q=$1 [L,QSA]
  • Drupal file discovery. Drupal 'discovers' bricolage files using the Drupal custom not found mechanism. This is probably not always the best way to do it - instead Bricolage could publish a csv file of new articles that Drupal processes, or maybe even push data directly into the Drupal database. But file discovery is the mechanism that we inherited on this site, and it's robust and relatively simple. When Drupal does discover a new page, there are a few pieces of information that Drupal likes to know about, such as a page title, a unique bricolage id (if a page gets republished with a new name, it knows how to move the comments over), and whether comments are allowed for the page, to name just a few. In my first version, these bits of information were translated via some php defines, which aside from being ugly, meant that the bricolage page had to be php. So in the new version, all these values are now in meta tags.
  • Template files The best thing this version does is to get rid of the extra file that was required for each bricolage page. Previously, because of trying to reimplement the integration on a live site with existing comments in vb3, i resorted to getting bricolage to output separate template files from the original html files. Because we were starting fresh here, Bricolage can now just output one page per file and use the meta tag mechanism for all it's drupal-specific stuff. The nice result is that to remove Drupal integration, you can just update the apache mod rewrite command and the site suddenly becomes a regular php or html site.

Mainstreaming?

So in spite of failing to release early or often, i'm hoping that the new release will be appreciated and used outside of The Tyee. In that spirit, here are some step-by-step instructions for a simple install that adds static page integration to an existing Drupal installation.

  1. Create the static page directory if you don't already have one. I just added a subdirectory called 'static' to my site directory, and then added an alias so I could address pages within that directory more simply /static/. By default, these pages would not be processed by Drupal because they actually exist.
  2. Download and install the module. This won't break or do anything.
  3. Add a mod rewrite to send your 'static' files through the drupal bricolage module. See above for an example, which maps static urls like /static/pathname/filename.html to the Drupal path 'pathname/filename'. For the tyee, all the filenames are index.html, so we remove that (because each index.html file has a print.html version which doesn't need to go through Drupal).
  4. Set up the discovery mechanism. In the Drupal admin -> site config -> error reporting, put in "bricolage/notfound" as the 404 page.

With those steps complete, urls like /static/test/blah.html that correspond to an actual html page will get mapped via the url_alias mechanism to an internal Drupal path like 'bricolage/id' and display those pages as if they were phptemplate pages after running through the Drupal bootstrap and generating appropriate values (e.g. the user, blocks, etc.). To get commentability on your static pages, you'd also need to add the appropriate meta tags and on your static pages.

How is this useful?

The original use case of this module is to add Drupal commenting to a static site. Since you get a full Drupal bootstrap for each page, you also get blocks and users, and nodes if you want. Which means that really, you're injecting any Drupal-generated dynamic content into a site who's design and primary content can be controlled via another mechanism [like Bricolage].

Of course, intergration is always complicated, and the Tyee example is instructive in that bricolage is outputting php, which, without Drupal, would be reinterpreted on each page load. By running it through Drupal, you can get the static page cache for anonymous users, which has the potential to also speed up the site [but you have to consider whether the dynamic content in the page php really should be cached ...].

Popular posts from this blog

Me and varnish win against a DDOS attack.

This past month one of my servers experienced her first DDOS - a distributed denial of service attack. A denial of service attack (or DOS) just means an attempt to shut down an internet-based service by overwhelming it with requests. A simple DOS attack is usually relatively easy to deal with using the standard linux firewall called iptables.  The way iptables works is by filtering the traffic based on the incoming request source (i.e., the IP of the attacking machine). The attacking machine's IP can be added into your custom ip tables 'blacklist' to block all traffic from it, and it's quite scalable so the only thing that can be overwhelmed is your actual internet connection, which is hard to do.

The reason a distributed DOS is harder is because the attack is distributed from multiple machines. I first noticed an increase in my traffic about a day after it had started - it wasn't slowing down my machine, but it did show up as a spike in traffic. I quickly saw that…

Confused by online payment processing? You're not alone.

In the old days during "polite" conversation, it was considered rude to talk about sex, politics, religion and money. You might think we're done with taboos, we're not (and I'll leave Steven Pinker to make the general argument about that, as he does so well in The Better Angels of Our Nature).

The taboo I'm wrestling with is about money - not how much you make, but about online payment processing, how it works, and what it costs. In this case, I think the taboo exists mainly because of the stakes at hand (i.e. lots of money) and the fact that most of those who are involved don't get much out of explaining how it really works - i.e. the more nuanced communications are overwhelmed by sales-driven messaging, and the nuanced stuff is either proprietary secrets or likely to get slapped down by the sales department.

In other words, if you want to really understand about online payment processing because you want to decide between one system and another, you'…

drupal, engagement, mailing lists, email

I lived, worked and studied in Costa Rica from 1984 to 1989. Ostensibly, I was there to study Mathematics at the University, and indeed I graduated with an MSc. in Mathematics supervised by Ricardo Estrada (check that page, he even advertises me as one of his past students). And yes, I do have a nine page thesis that I wrote and defended in Spanish somewhere in my files, on a proof and extension of one of Ramanujan's theories. But mathematics is a pretty lonely endeavour, and what drew me back to Central America (after the first visit, which was more of an accident), was the life and politics. The time I lived there was extremely interesting (for me as an outsider, though also painful and tragic for it's inhabitants) because of the various wars that were largely fuelled by US regional hegemonic interests (of the usual corporate suspects and individuals) and neglect (of the politicians and public) - the Contra war in Nicaragua, the full-scale guerrilla wars in El Salvador and …