[development] integration with bricolage ?
alan.g.dixon at gmail.com
Thu Aug 3 20:12:51 UTC 2006
i'm looking for some opinions, ideas, feedback...
I have a client with a bricolage (perl-based cms that spits out static
html files for publishing, popular with newsletter, newspaper sites)
site, that wants to offer a user comments feature. There was already
an attempted integration with vbulletin that didn't work super well,
and they liked the other parts of drupal so I was approached to see
what kind of drupal integration might work. That was many months ago -
at this point I have a working prototype waiting for the client to
decide what to do next. I'll describe here my strategy and am looking
for general feedback, criticism, other approaches or refinements.
If I was starting from scratch, I might use an approach I've seen or
heard about that just pumps the bricolage output into node bodies, but
this bricolage install has already got a lot of logic about the
navigation/theming in it that I thought would lend itself to a less
So (omitting the tedious details):
1. I've laid a drupal install over the existing bricolage site's document root.
2. i've created a 'bricolage' module which defines a
'bricolage_render' callback function for the path 'bricolage'.
3. I've created a custom 404 function in the module called
bricolage_not_found to handle page not found replies.
4. I've adapted the .htaccess file to have drupal handle .html files.
The html that this bricolage install generates includes some php,
which was being used to provide the vbulletin interface and that
defines the bricolage publication id, as well as whether the article
should allow comments.
Here's how my module works now:
1. when a bricolage url gets called for the first time (they're always
different from regular drupal paths), the bricolage_not_found function
is invoked and reads in the corresponding bricolage .html file and
generates a new 'bricolage' type node that has an empty body and some
extra fields for the url and the bricolage id, and then it also
generates a path alias to convert the bricolage url to the drupal path
'bricolage/<bricolage_id>'. (it figures out the bricolage id by doing
a drupal_eval on the bricolage output). Then it does a drupal_goto to
reload the same url.
2. the second (and all subsequent invocations) of the bricolage url
then trigger the bricolage_render callback function. This function
looks up the location of the bricolage-generated content (yes, it
could try to just get it from the request_uri, but we don't want to
rely on that for a few reasons), and then does a drupal_eval to get
the output of the page. Then it can selectively invoke whatever other
modules it wants (in my case, the comments module), to generate the
dynamic content, and sticks it into the output.
In other words - it treats the bricolage html pages as templates that
drupal outputs as is with some selective mangling (in my case, just
comments, but potentially other bits as well, like blocks).
1. i've chosen to output the content via a callback instead of as a
node because I didn't want the overhead and potential mangling of
other nodeapi-type modules. It means that these urls are special and
don't behave like the other node content on the site - in particular,
the drupal search doesn't work. This could be fixed, but my client
doesn't need it (yet anyway, they're using google).
I did put in a function so that if the corresponding node gets invoked
directly with a node/<nid> url, it'll redirect to the bricolage/<bid>
url (or rather, it's path equivalent).
2. it's definitely not plug-and-play (yet?) - in my case I needed also
to migrate the existing comments into drupal (i did put that in a
separate module), and there's probably other code that would need to
be written to make this module useable as is with other bricolage
Alan Dixon, Web Developer
More information about the development