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.


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.


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

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

Orchestrating Drupal + CiviCRM containers into a working site: describing the challenge

In my previous posts, I've provided my rationale for making use of Docker and the microservices model for a boutique-sized Drupal + CiviCRM hosting service. I've also described how to build and maintain images that could be used for the web server (micro) service part of such a service. The other essential microservice for a Drupal + CiviCRM website is a database, and fortunately, that's reasonably standard. Here's a project that minimally tweaks the canonical Mariadb container by adding some small configuration bits: That leaves us now with the problem of "orchestration", i.e. how would you launch a collection of such containers that would serve a bunch of Drupal + CiviCRM sites. More interestingly, can we serve them in the real world, over time, in a way that is sustainable? i.e. handle code updates, OS updates, backups, monitoring, etc? Not to mention the various crons that need to run, and how about things