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 drupal-centric approach. 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). Issues: 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 sites. Anyone? -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/