Skinning Mailman (how to add a customer UI in five minutes or less...)
I've got this running now, so I figured I'd toss out a cookbook recipe on it while it's fresh.
I've always hacked Mailman to install a custom interface on it so it matches the rest of my sites (for instance, see www.hockeyfanz.com/mailman/listinfo). The downside to this is that every time a new release comes out, you have to repatch all your changes.
This makes it more work to upgrade than it should be, so I've been keeping an eye out for a better way to do this (and it gets worse -- on one of my sites, I also have a web board that needs custom patching, my mhonarc rcfiles that need patching, and the standard files that need tweaking every time the UI or graphics get revamped, and I'm not always in control of when they get redone...)
I finally found a tool that takes care of this for me -- it's called mod_layout (www.tangent.org), and it's an apache module, so this is apache specific.
If you run your apache with DSO (and if you don't, you're crazy...), installation is trivial. Download the thing, unpack it, then run "make" and "make install". It uses APXS to handle everything.
To get it running, I added these lines to the httpd.conf. In my case, they're in the <virtualhost> declaration (it supports all fo the apache stuff, so it recognizes and honors virtual hosts, directories, etc... Very flexible beast)
# stuff to wire in mod_layout LayoutMerge On LayoutFooter /home/httpd/html/footer.incl LayoutHeader /home/httpd/html/header.incl
(I also have some lines causing it to NOT tweak files in directories I want left alone -- it can be configured on a file or directory basis, host basis, or systemwide)
Then create the header and footer, and restart apache.
What mod_layout does (as configured here) is put itself in the middle of everything, and when it sees the <BODY> declaration, it inserts the header. And when it sees </BODY> it inserts the footer before it. For the CGI or html page, it's completely transparent, and you don't have to worry about screwing up CSS or javascript, and it leaves cookies alone. It also doesn't affect your HTML, since it comes after the <BODY> so it can't interrupt tables or other location sensitive things.
Very nice hack, IMHO, and allows you to wrap an interface around mailman quite nicely -- as well as most other CGI-based stuff that doesn't support templating. And even nicer, IMHO, is that if you need to change things, you change the included files -- and it magically propogates, no need to even restart apache.
This gives me control over almost all of Mailman (and, hint hint) -- hopefully Barry will add the configuration for the rest down the road.
One is that some of the text-box colors are hard-coded (see, for instance, /mailman/admin/listname/general/. It'd be nice (and it seems to be easy to do) to turn those into globals that can be set in mm_cfg.py instead of requiring someone to whack all of the source files they're sprinkled in.
The other key one for me are some of the admin messages (Mailman/Handlers/Hold.py). I've modified some of the messages for various reasons, and it'd be nice if I could simply override their definitions in the mm_cfg.py file
And the third place I've made custom changes are in some of the list templates (most radically templates/listinfo.html) -- but that's why they're template; you simply keep a copy somewhere and watch out for additions to the updated copy...
It took me about three days and a couple of exchanges with the author of mod_layout to get it going the way I wanted (the documentation is still being fleshed out), but it's a nice improvement to the old way of doing things -- and since I know others build custom skins around their installations, I'd thought I'd pass this one along.
If you want to see a version of mailman with mod_layout, see www.plaidworks.com. My mailman set up the old way is www.hockeyfanz.com (for now. I'll be working to move this to all my stuff over time...)
Chuq
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> I finally found a tool that takes care of this for me -- it's
CVR> called mod_layout (www.tangent.org), and it's an apache
CVR> module, so this is apache specific.Very cool indeed. Although I haven't had time to play with it, it seems like a low-cost approach that gets you 90% of the way there.
CVR> This gives me control over almost all of Mailman (and, hint
CVR> hint) -- hopefully Barry will add the configuration for the
CVR> rest down the road.
CVR> One is that some of the text-box colors are hard-coded (see,
CVR> for instance, /mailman/admin/listname/general/. It'd be nice
CVR> (and it seems to be easy to do) to turn those into globals
CVR> that can be set in mm_cfg.py instead of requiring someone to
CVR> whack all of the source files they're sprinkled in.I've completely rewritten the user options page (more on this later, tomorrow is checkin day :), and have taken the opportunity to do exactly this. I may have missed some, but the idea is that the colors are now overridable in mm_cfg.py.
Which makes me think more about having a better support for virtual domains by having something akin to a different mm_cfg.py per domain. That's rumbling around in the back of my head.
CVR> The other key one for me are some of the admin messages
CVR> (Mailman/Handlers/Hold.py). I've modified some of the
CVR> messages for various reasons, and it'd be nice if I could
CVR> simply override their definitions in the mm_cfg.py fileI'll have to think about this. One hackish idea (untested) is to try to import Mailman.Hold from mm_cfg.py, and then set the class's __doc__ attribute with the message you want. The fact that Mailman/Hold.py imports mm_cfg.py means you might have to play games with the importer to get this to work. Not a great solution, but it might help localize your customizations for now.
CVR> And the third place I've made custom changes are in some of
CVR> the list templates (most radically templates/listinfo.html)
CVR> -- but that's why they're template; you simply keep a copy
CVR> somewhere and watch out for additions to the updated copy...Exactly, and the new template lookup scheme should be much more friendly to this approach.
CVR> It took me about three days and a couple of exchanges with
CVR> the author of mod_layout to get it going the way I wanted
CVR> (the documentation is still being fleshed out), but it's a
CVR> nice improvement to the old way of doing things -- and since
CVR> I know others build custom skins around their installations,
CVR> I'd thought I'd pass this one along.Yes, thanks!
-Barry
On Wednesday, May 30, 2001, at 10:51 PM, Barry A. Warsaw wrote:
CVR> The other key one for me are some of the admin messages CVR> (Mailman/Handlers/Hold.py). I've modified some of the CVR> messages for various reasons, and it'd be nice if I could CVR> simply override their definitions in the mm_cfg.py fileI'll have to think about this. One hackish idea (untested) is to try to import Mailman.Hold from mm_cfg.py, and then set the class's __doc__ attribute with the message you want.
I think a more general solution is to rethink the admin messages, and make them part of the site and list databases. You would have 0 ... n definitions, each of the form:
regex action message lockflag
where the latter is in the site database only.
actions would include HOLD, DISCARD, REJECT and whatever else people would find useful.
you could then define this as a set of python regexes (with, I think, a few procmail-esque extensions, so you could define whether to look in header, body or both, and in the body, optionally the first N lines...), and do something with it, and a message including python ''' multiline format.
The lockflag is so the site admin can, if they choose, keep list admins from over-riding definitions. So for each message, you'd check the site-wide LOCKed lines, then the list definitions, then the site-wide definitions, and stop on the first match. that way, you stop having to migrate global definitions to each list, and have to worry about updating them on updates...
And make them definable, editable and viewable from the web interface so the list admins and site admin can tweak them.
-- Chuq Von Rospach, Internet Gnome <http://www.chuqui.com> [<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>] Yes, yes, I've finally finished my home page. Lucky you.
I like you. You remind me of when I was young and stupid.
I've completely rewritten the user options page (more on this later, tomorrow is checkin day :), and have taken the opportunity to do exactly this. I may have missed some, but the idea is that the colors are now overridable in mm_cfg.py.
Wonderful!
Which makes me think more about having a better support for virtual domains by having something akin to a different mm_cfg.py per domain.
This would be very cool. My favorite implementation of virtual domains is Apache's, and it strikes me that adding the <virtualhost domain> directive might be an easy and intuitive way of accomplishing virtual domain directives now that you have overridable colors in mm_cfg.py.
Just a thought. If you did key admin messages in mm_cfg.py you could put them here this way.
Thanks for all the improvements! Some day if I could consolidate all my mailman virtual implementations, all in their separate chrooted environments, back into one virtual mailman environment, I would die happy and will Barry my Star Trek hologram trading cards AND my wool Canadian Army cap.
Dave Klingler
That's rumbling around in the back of my head.
CVR> The other key one for me are some of the admin messages CVR> (Mailman/Handlers/Hold.py). I've modified some of the CVR> messages for various reasons, and it'd be nice if I could CVR> simply override their definitions in the mm_cfg.py fileI'll have to think about this. One hackish idea (untested) is to try to import Mailman.Hold from mm_cfg.py, and then set the class's __doc__ attribute with the message you want. The fact that Mailman/Hold.py imports mm_cfg.py means you might have to play games with the importer to get this to work. Not a great solution, but it might help localize your customizations for now.
CVR> And the third place I've made custom changes are in some of CVR> the list templates (most radically templates/listinfo.html) CVR> -- but that's why they're template; you simply keep a copy CVR> somewhere and watch out for additions to the updated copy...Exactly, and the new template lookup scheme should be much more friendly to this approach.
CVR> It took me about three days and a couple of exchanges with CVR> the author of mod_layout to get it going the way I wanted CVR> (the documentation is still being fleshed out), but it's a CVR> nice improvement to the old way of doing things -- and since CVR> I know others build custom skins around their installations, CVR> I'd thought I'd pass this one along.Yes, thanks!
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
On Thursday, May 31, 2001, at 09:46 PM, Dave Klingler wrote:
This would be very cool. My favorite implementation of virtual domains is Apache's, and it strikes me that adding the <virtualhost domain> directive might be an easy and intuitive way of accomplishing virtual domain directives now that you have overridable colors in mm_cfg.py.
The downside is that you have a single point of administration. In an ISP environment, it'd be nice to export that administration to the owner of the domain, so you don't have a support guy going crazy with "can you make this change?" requests.
But you could deal with that by extending it to allow included files>
<virtualhost domain> <include /page/to/file> </virtualhost>
so you have the option of handing it off. But that gets you into issues of whether those users can screw things up for everyone else with typoes, etc. It'd be nice if an included file has a typo that it only destroy the current virthost...
-- Chuq Von Rospach, Internet Gnome <http://www.chuqui.com> [<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>] Yes, yes, I've finally finished my home page. Lucky you.
Always look away from the obvious answers, because if you don't find a better one, you can always go back to them on short notice.
participants (3)
-
barry＠digicool.com -
Chuq Von Rospach -
Dave Klingler