If you are reading this, then you are probably already aware of the big redesign going on at this site. As part of trying to get this site in sync with the suggestions over at
Dive Into Accessibility, I decided to tackle the search functionality of this site, or the lack of search functionality as the case may be.
The main problem with the search was that it as a standalone cgi wasn’t using the same method of page construction that this site uses.
This site is built around AxKit, an XML Application Framework using pipelines. In english, that means that this site uses a series of XSP / XML / XSL pages to make the final page a browser sees while the mt-search.cgi simple dumps it’s output to the browser bypassing all the flexibility and layout of the other pages. Bummer.
So, how do we fix this, or pipe the mt-search.cgi output through the existing pageflow? Apache::Filter to the rescue.
What Apache::Filter does is rearranged the order that PerlHandlers fire under mod_perl and allows the output from one handler to be filter through another handler.
Now it just so happens that mt-search.cgi can also be run under mod_perl using handlers. I also lucked out in that the current pageflow system can receive input from Apache::Filter. But after some httpd.conf config changes, nothing worked. The reasons turned out to be threefold:
- MT::App::handler was Apache::Filter ignorant. Not surprising. Who would ever need it to be. Just a matter of registering itself with the Apache::Filter module.
- MT::App::print was mod_perl aware, but was using the Apache::print method instead of printing to STDOUT. Another easy fix.
- MT::App::send_header was mod_perl aware, but if we have Apache::Filter turned on, no need to send headers.
So, with all that in mind I present to the masses MTApacheFilter, a patch to allow the mod_perl handlers in MT::App be more Apache::Filter friendly.