Ok, here's the logic I've settled on. Four options: content=default
('' or not set), simple, html, rules (your custom csv list of rules)Default: no markup processed Simple: if, vars, and links processed Html: vars,if,links,fmt,block,style,end Rules: set content = to the rules you wish, csv list. If it turns out regular html links work fine in most text email clients, we can make that the default. Also, theres no html parameter needed. If html or a custom rules set that produces html, it is labeled as html in the header automatically, and a check is made for the html wrapper around your message, supplying it if needed. Works pretty nice. I'll do some more testing with real emails, but curious about your initial feedback/reactions. Cheers, Dan P.S. I'll take a stab at the rss plugin also, and see if I can't get it to do something comparable. :) On Fri, Sep 25, 2009 at 10:21 AM, The Editor <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
