As I've been playing with the scripts, it seems that as the length of the series gets longer, it may be desirable to change the advertising. The sample I've been working with is only 5 parts and they all relate to the item that I'm advertising, so that doesn't seem to be an issue.
One of the things I want to do with this script is allow people to have sections of a book downloaded into their mailbox every day. Since many people read their email religiously, they could also read a book.
Anyways, sending the same two ads everyday might not be all that effective, so I'm working on how to integrate an ad rotator with the script.
Any comments are welcome.
|
|
|
Seriesmail text file formats |
|
|
|
The text file containing each message will contain:
$subject (subject in the email header)
$from (from in the email header)
$greeting (introduction in the email body)
$text_1 (first half of the email body)
$text_2 (second half of the email body)
$unsubscribe (a message on how to unsubscribe)
$ad_1 (will come from a separate file and be inserted after $text_1 in the body after $greeting)
$ad_2 (will come from a separate file and be inserted after $text_2 in the body before $unsubscribe) |
|
|
SeriesMail... with file based messages |
|
|
|
Work has been started on the script to use file-based messages. That is, the text for each mail message will be stored as a file. A Series which contains 6 messages will have 6 files. I've been thinking that you might want to have a 7th file that tells the person that the first 6 are done and direct them back to the site to renew or add other Series.
I hope to release a version this weekend that has the following features implemented:
Reads the current list from a database. The list contains the id of the person, the message they are to receive and whether they want it to repeat when it's done.
Sends the message specified, including an advertisement or sponsorship message
Updates the database with a summary of the mailing and the date the script was run so that it only gets run once a day.
The package will include the script and an sql file for the database. |
|
Well, we're still working on the architectural decision about files verses database storage of the content for the mailings.
In my works with Xoops (for Troop 81), I found that much of the data was stored in the database. There were extensions however which allow you to wrap html. In my experience there, I found it much easier to add content that way. Let me go look at the Joomla wrapper.
I'm back. That works like the Xoops one. I think I like that way best. I get to tweak everything offline then upload. Let's look one more place.
Back again. In reviewing my work with OSCommerce (at Gem Paper, I found it tedious to add lots of data through the web interface. I found the extension that allows me to upload a batch of data to be a life saver.
Well, I guess that settles it. For now we'll go forward with a file-based storage of the email messages.
Tomorrow we'll see how the implementation's going.
|
|
We're getting closer to a release!
Today we're working on cleaning up soem of the variable definitions. We're trying to decide whether to store the text of the messages in the database or in files. I don't expect perfromance to be an issue, because we want to slow everything down anyways in order to not overwhelm the server with outgoing messages.
The positive thing about storing them as files is the ability to locally edit/duplicate similar items and then upload. teh server response time won't be an issue.
Putting them in the database seems a little cleaner. I can put an editor in the admin section, but that's lots more work. I've looked at some of the code for CMS systems and there seems to be a split. Some things are in the data base, some in language files.
I hope to eventually package this up as a module (or component, or whatever it's called) fro some of the popular CMS modules such as Joomla nd Xoops (I'm somewhat familiar with those 2) In that case it would seem appropriate to follow their convention. I guess we'll spend today examining CMS code!
Until tomorrow.
|
|
|
|