Extra subscribers fields in Dada Mail has been basically the #1 requested feature in the program and now it's actually a part of Dada Mail and not vaporware.
Enjoy!
Like many of the features in Dada Mail, we've tried to create a good balance of dead-simple to use and highly configurable. The Subscriber Fields project is a very large feature with a lot of interesting ways we can take it. We're starting out simple and easy, but we'd like to know what certain features are important to you - so let us know via our email, the dadadev mailing list and the support boards (http://mojo.skazat.com/support/boards)
The extra subscriber fields in Dada Mail are saved in the dada_subscribers
table. Right now, there's a limit of 100 extra columns and each column is given the data type of, text
.
Pretty simple stuff.
The subscriber fields feature in Dada Mail requires that you use one of the supporting SQL backends. Currently, Dada Mail supports MySQL, Postgres and SQLite.
Most likely, if you ever have to downgrade Dada Mail, these extra fields shouldn't hurt too much to keep around. From my tests, Dada Mail will simply just ignore the extra fields. There's no way to use these extra fields in any way for any version of Dada Mail under 2.11 (The alpha series).
Adding a new subscriber field is pretty easy. Log into the list control panel with the Dada Mail Root Password (very important) to any list. On the left hand menu, under, Manage Subscribers, click, Subscriber Fields
This screen will allow you to add/remove the subscriber fields. This screen will also let you set a fallback value. The fallback value is used in mailmerging and is used as the value fo the field tag when no value is present.
The fallback value is saved in the dada_settings table in the fallback_field_values setting.
Please note that removing any subscriber fields will permanently delete all the information that once was saved in this particular field.
Hazzah.
And we mean it.
The other thing to note is that subscriber fields are global, meaning, they'll be there for each list Dada Mail manages.
You can also add a subscriber field in Dada Mail by just adding a new column to the dada_subscribers table yourself via SQL. I would be careful doing so, since you'll curcumvent any checks that are done via the list control panel, but you're open to and Dada Mail will see your new columns as new subscription fields.
Dada Mail currently doesn't support changing the order of these subscriber fields, but if you feel mighty, you may do this yourself via SQL. If you had two subscriber fields, one called, ``last_name'' and one called, ``first_name'' and you'd like ``first_name'' come before, ``last_name'', you'd want to say do something like:
ALTER TABLE dada_subscribers MODIFY COLUMN last_name text AFTER first_name;
(This is for MySQL 5 - consult your own SQL server implementation... thingy)
Mail Merging in Dada Mail in mailing list messages using your new subscriber fields is pretty easy:
Say you have a field named, first_name. To use the value of the saved field in an email message, you'd write the field as a tag, like this: [subscriber.first_name]. It would look like this in your actual message:
Hello, [subscriber.first_name] It's really nice to talk to you! -- Me.
Mail Merging works for almost every single type of email message Dada Mail can send out.
You can now make a query on your subscription list to send to only part of your mailing list. For example, if you have a field named, ``city'', you can tell Dada Mail, ``only send to people whose, ''city`` value is set to, 'Denver'.
Currently, this is done in the, ``Send a List Message'' and, ``Send a Webpage'' screens. Click the, Show/Hide Partial Sending Options. You'll be presented with a form that allows you to make simple queries and give you a preview of who's going to the message.
The subscription process is similar to previous versions of the program, except that the subscription form now supports capturing any subscriber fields present.
Currently, all subscription fields will be shown, except (by default), subscriber fields that are prefixed with an underscore (``_''). For example, the field,
first_name
Will be shown! The field,
_secret_field
Will not. Consult the Config.pm file for how to set the special prefix.
Currently, all the subscription fields are optional, except the email address.
You may acquire the HTML code needed to embed the subscription form in a webpage in the usual location: Under Manage Appearance, click on, Subscription Form HTML.
There's also a new option to embed a javascript call that will create the HTML form for you. This is beneficial, since the subscription form on your webpage will automatically update, if you add/remove a form field.
There are a few difference internally with the subscription process. The largest is that all subscription requests by users will first have the subscriber information saved in the, ``sub_confirm'' sublist. This is where the information filled out in your subscription form is saved, before a subscription is confirmed. Once a subscription is confirmed, the information is moved to the main, ``list'' sublist.
A similar scenario takes place for unsubscriptons: The subscriber is first put on a, ``unsub_confirm'' sublist and is taken off this list, as well as the main, ``list'' sublist once the confirmation process is completed.
Because of this, you will no longer be able to use complete confirmaton URLS, (URLS that have the pin number and email address embeded in the URL) in any place other than in the subscription and unsubscription confirmation email messages.
Every single instance of the subscription form is handled by one template file, living in the dada/DADA/Template/templates directory called, subscription_form_widget.tmpl. Changes to this file will affect every instance of the subscription form in the program.
This file also takes the place of the two files:
You may add subscribers into your list via the list control panel. Under, Manage List, click, Add.
Several changes have been made from previous versions of the program.
In versions past, you were able to basically put in email addresses you wanted added in a free form way.
Not so in 3.0.
In Dada Mail 3.0, the file type you need to import your subscribers in must be in CSV format. The order of the fields in that CSV format should be displayed at the top of the screen.
You can edit an individual's subscriber information in the list control. Under, Manage Subscribers, click on, view. You'll be presented with a table of your subscribers, with all their subscription information. Clicking on the email address of the subscriber will bring you to a screen to edit the subscription information. Pretty simple.
Currently, subscribers can not edit their own individual information.
We've just about taken two thirds of the development time with testing the code we've written in the other third of the time. It works pretty darn well. We'd like you to use it as well, even in a production type site, but be cautious if you do find problems - as there may still be some we haven't uncovered.
We do encourage you to report problems as soon as you can - we'll be thankful that you have and may be able to give you a workaround on the spot. You can do this via the dadadev mailing list (nerdy):
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/list/dadadev/
Via the support boards (this forum is for the 3.0 development release):
http://mojo.skazat.com/support/boards/viewforum.php
These are new features that haven't seen a lot of real world action. We need your input and reports.
We're currently re-writing a lot of the documentation for the 3.0 release.
If you have a specific question about anything in the new version that doesn't seem to be covered, best to ask.
It's up in the air if the Global Blacklist is still working. It needs realworld testing.
Global list sending is currently disabled and most likely, broken. It's not impossible to have this feature back and we have interest in getting it back for you, but it just didn't make the first alpha release.
Plenty. Think of this as a 1.0 release of a brand new product. We'd like to hear from you in seeing what other features you'd like, relating to subscriber fields.
Upgrading to Dada Mail 3.0 is no different than upgrading in any other recent version of Dada Mail. The SQL schemas are just about the same.
If you're a developer geek, subscribe to the dadadev list to join the discussion on Dada Mail:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/list/dadadev/
If you have a question, please use the boards:
http://mojo.skazat.com/support/boards
The nerdy Perl API has changed drastically (and probably, for the better) in 3.0. Most likely, if you had a custom Perl program for Dada Mail 2.x that was using the API, it has now been broken.
For the Mailing List Subscriber API do consult:
MailingList_Subscribers.pm.html
Which should be fairly complete.
The HTML Screen and Email Template parts of Dada Mail all use the same system. See:
Template_Widgets.pm.html#screen
And also:
App_FormatMessages.pm.html#email_template
I think I've been asked when Dada Mail would receive the ability of saving more than an email address for about six years - a little less than how old the program is now.
I've given a lot of answers ranging from, ``I don't know'' to, ``three months'', sometimes rotating my answer weekly.
In December of 2005, I even had a fundraising effort to allocate some sort of resources (in the guise of money) to help offset the time it would take me, an unpaid (usually) Free Software Programmer to get Dada Mail the feature.
In the fundraiser I gave the (firm) estimate of, ``60 days'' after the goal was met. Wishful thinking. We're now closing in on two years since then and the feature is just finally coming to light in an alpha form.
It's been a long hard road till here and I wanted to at least explain a little bit about how Dada Mail has been developed and why it took so darn long.
Firstly, I want to let people know I had a small medical issue during the fundraiser and being uninsured, this small medical issue (it's highly embarrassing on what it was) took basically all my resources. It also happened out of the country in Europe. I barely made it home and the funds that were going to displace me for not working on anything else for 2 months, was used to keep me fed for two months.
Not an excuse, just what happened. I don't excuse the complete miss of a timeframe. It was foolish of me to think I could hit such a close goal and it shows the green in me.
Anyways,
The development of the 3.0 version has been extremely long - to the point of I'm not quite sure this version is coming out. Alpha 1 of 2.11 came out in around September of 2006. We've been folding a lot of features from 2.11 into the stable branch, but there was a time this year where that really didn't seem like a good idea anymore.
I've tried to go through the last two years of development, but it's pretty fruitless to attempt to summarize all the changes in the program and tell you why Dada Mail wasn't yet ready to have multiple fields. A few things do come to mind:
A lot of the HTML in Dada Mail was *still* still embedded in the program. This makes for very messy code and it's very difficult to keep added new features. This program has for the most part been resolved.
Here's the main problem in creating a large new feature in a program, so new developers take note:
Dada Mail didn't have an automated testing suite. This is bad news, since it makes it quite impossible to verify new work you've done hasn't broken old things and also this new work, works!
The lack of a testing suite makes a program's stability unverifiable. When faced with creating such Big New feature I had no idea how I'd do it successfully, since this new features adds quite a bit more complexity to the program.
There's now a very healthy testing suite in Dada Mail with fairly good coverage - it could always be better, but it's factors better than it was.