NetMusician Labs

Edit: the following instructions no longer seem to work. I have replaced these by writing to a file, picking up the contents of this file via a cron job, and using the included Mailman “add_members” binary to pick up the contents of this file.

As is the case with a number of web applications, one of the ongoing problems includes negotiating using a web interface as a bridge and functional interface into making system modifications securely, while acknowledging the fact that in most installs the Apache user will be different than the user(s) with the appropriate permissions to execute your Unix scripts and binaries over an SSH session. For commands and scripts that may affect a number of users on your system, typically only the root user may have executable permissions.

One such instance in which these restraints and challenges comes to the fore is in developing a more user-friendly, alternate Mailman web interface for users. Mailman is a superb mailing list with a robust plethora of features, but if you wish to make this available to a novice user simply to, say, subscribe users in bulk to an opt-in mailing, there are a lot of extraneous features the user will be forced to wade through. Additionally, I always thought that the unsubscribe process was a little unwieldy for a list configured to send out “one-way” mailings (i.e. a musician who wants to send out information to fans, but doesn’t want to invite responses to the entire list). I had envisioned it to be a simple form, preferably styled to match the look of the site. The subscriber in this instance does not need to be concerned with digest options and such, so there is no need for these options to even be displayed.

It seems like the two ways to go about customizing the web interface is to actually patch and markup the Mailman code base to your liking, or else simply piggyback upon the forms and binaries provided by Mailman, replacing the interface with your own.

Preface: I haven’t actually developed this solution yet, but I’m confident it will work. I will report back later with my findings…

I’ve developed my own subscribe and unsubscribe forms that mimic the ones provided by Mailman, setting up identical form fields that direct form output to the same Mailman pages. An example of my subscribe page can be found here. To enhance this, I setup a root cronjob to use the included Mailman list_members binary to generate a listing of members subscribed to the list, and save this output to a file that is inaccessible from the web. I then setup the subscribe email address field to trigger an AJAX request to grep for the email address in this list. If it is found, a “you are already subscribed to this list” message will be generated even before the form is submitted. You can use Javascript to hide the form submit button when the address provided has already been subscribed to the list.

Mailman’s normal form interface is designed to generate these errors, but I found them a little ugly and wanted to replace them with my own. I also wanted embed these feedback within my own site template. Mailman provides the means to modify the subscribe/unsubscribe feedback templates within its web interface, but I wanted to include PHP code in this template, and go beyond simple HTML. So, I decided to not rely on Mailman to generate this feedback, and simply replaced the Mailman subscribe feedback template with a meta redirect to a page of my own.

So, to summarize, I’ve basically replaced the logic behind examining an incoming subscription address with an AJAX call, and replaced the feedback that Mailman provides with pages of my own. The unsubscribe form can be designed in a very similar fashion.

What about providing mass subscription type functionality?

This is the part I’m still working on. I’ll need to find a script (or write one of my own) to convert vcard data to a list of addresses I can feed to Mailman, and I’ll need to design this web interface.

I intend for the web interface to work in a similar way as described above, where addresses are read from a flat file generated by the cronjob. Using this data, I can provide an AJAXey interface for manipulating the addresses in this list, and create another root cronjob to read this file an execute a remove_members and add_members to replace the list addresses with those in this file whenever this file is changed.

The one weakness of this approach is that there will always be a time delay and a lack of immediacy while the user waits around for the cronjob to run. This can be made a little more user-friendly by providing feedback that “your changes will take effect in 3 minutes”, or whatever, and having feedback emailed to that user’s email address.

Once the Webkit is released as an open source product, I may include this module for those that wish this functionality, in addition to my “Mailman HTML mailer” module.