I'm going to start working on the mail function again today and need
to resolve a particular question. How to format the email content.
Essentially this is the code we have in the latest release (I think!):
if ($args['html'] == 'true') {
$header .= "MIME-Version: 1.0\r\nContent-Type: text/html;
charset=ISO-8859-1\r\n";
$body = BOLTdomarkup($body);
$body = BOLTescape($body, false);
$body = "<html><body>$body</body></html>";
}
else $body = BOLTdomarkup($body, '', '', 'vars,func,if');
This says if you have html=true in the function, it will take your
email template and do all markup on it and insert it into the mail
message as final html. Nice but, what if you have a <(forward {P})> or
something in the body of the message. Well right in the middle of
preparing a message, you get forward to a new page. No mail sent.
Maybe an extreme example, but you get the idea. If not set to true,
you have only certain markup rules processed: vars, func, if. With no
way to escape them because the escape rules are ignored. What if I
wanted to send a markup sample to the BoltWire mailing list? I'd be
hard pressed to do it. And what about style sheets? No real way to
include any kind of styles with the email in html format--which I
assume is allowed... Lot's of problems here.
It's similar in RSS where the plugin uses a content= parameter with
options of html, a custom function, text, or teaser (straight text,
first so many characters). And these work just so well. I like the
syntax, but we need to clarify some options, and ultimately the code.
Preferably with both of them at least somewhat similar.
Questions:
The email charset, should it be UTF? If so will that affect the
subject line. I've seen some hairy looking code dealing with UTF
subjects. Anyone know much about this?
How many email clients are likely to support html email? Is it
reasonable to send html messages without a multi-part message text &
html? The newsletter plugin does this. I have the code. But it's more
complex. Perhaps we should drop the simple html option we have here
from the core?
If we do send it text, will most email clients recognize some html?
Say an image link, or a url link? In other words should we do some
markup but not others? What about simple <b>BOLD</b> and the like.
What would most browsers do with this, if not sent in html mode?
Proposal:
Without knowing the answer to these questions fully, I can only take a
stab at a solution. But here are some possibilities.
1) Use the content= parameter to control the body output, with the
options of html, text, markup, escape, and perhaps a custom format
hook, like in rss.
* For html, expect the user to create an email message template
(including <html> and all, just as they want--and perhaps process
limited markup rules (if & vars) into html. This allows full control
of the message output.
* For text, try to write a function that processes a couple markups:
if, links, imgs, vars perhaps, and perhaps strip out some of the more
common markups in the text to generate something that looks like
regular text. Actually, why strip out. Just ignore it.
* For markup, process limited markup, like //italics// and links, plus
if and vars and maybe a couple others, then wrap it in a simple html
wrapper. So you don't require any html in the text.
* For escape, send exactly what is in the body exactly as it is given.
It's more a question of knowing what to call the custom content and
deciding exactly which rules to process for each. Hmmm...
For that matter, why don't we make the content configurable, with a
csv list of rules. :) Option of rules= , or go with the default
settings for one of the content= types. Perhaps configurable
themselves. That would give you very full control. Then keep the
html=true option merely to set the appropriate header, and wrap the
message in <html> if not already in it. That sounds like a jewel of a
plan.
Ok, well, I'll get working on it eventually.Have a full day today...
Also plan to put a mailmode override config setting as well.
Cheers,
Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
