Can't look at this because of network outage but I have some suggestions when I get reconnected.
Via mobile -----Original Message----- From: The Editor <[email protected]> Sent: Friday, September 25, 2009 7:21 AM To: BoltWire <[email protected]> Subject: Mail formats... 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 -~----------~----~----~----~------~----~------~--~---
