Wedge
Public area => The Pub => Features => Topic started by: Nao on April 10th, 2013, 11:17 AM
-
I'm stupid.
I have stupid ideas.
But sometimes, even though they're stupid simple, they're just like, "uh? why didn't I think of that before..?!"
In this case, I just received a notification e-mail (after subscribing to the stuff), and noticed that it had <URL> in it. Woops... Okay, I should be careful about sending notification data by e-mail, replacing <URL> manually instead of through the output buffer handler, because it's never called on these...
And then it struck me.
What prevents us from adding this at the beginning of the sendmail() function..? Uh?
$message = ob_sessrewrite($message);
Duh.
Then it just... gets converted like a normal web page would. We could even automatically convert things to entities on the fly, too. Every time a mail is sent, it's passed through sendmail(). Then why bother doing 'special e-mail handling' inside $txt in this situation...?
There's probably a reason... But I can't find any. I told you -- I'm stupid.
-
Problem: stuff can be passed through sendmail TWICE. You'd have to ensure it's only passed to the rewrite function the first time. (Look in the source for mentions of the 'hotmail_fix', since that's the trigger to send it through again)
As far as special handling goes, you're right. You're absolutely right. Consider: if a post contains these things, it's still going to get sent so why should it matter if $txt contains them too?
-
Problem: stuff can be passed through sendmail TWICE. You'd have to ensure it's only passed to the rewrite function the first time. (Look in the source for mentions of the 'hotmail_fix', since that's the trigger to send it through again)
As far as special handling goes, you're right. You're absolutely right. Consider: if a post contains these things, it's still going to get sent so why should it matter if $txt contains them too?
-
Don't get what you mean here...?
-
I applied the ob_ change to Subs-Post here, and tested sending a mail to myself... It works, but there are issues -- for instance, we should add an option to disable shortening of URLs because it ends up stripping the domain name out of the links, oops... I added a temp $context variable, I guess I just need to set it at sendmail time.
There's also another problem with HTML... It shows up as plain code. I'm thinking that there isn't much of a reason NOT to send HTML emails by default... If anything, it kinda defeats the purpose of ob_ to send as plain text, because tags are shown in all their glory... :-/
Or, maybe we should simply fix that and turn anchor tags into text.
-
Just be *extremely* careful doing that. The rewriter is not a cheap process if you have to factor in things like looking up pretty URLs - and if you're doing the DB lookup every call, that's potentially DB queries every time you send an email. For some cases, that's not horrible - one off emails are fine. But newsletters... not so much.
I'm thinking that there isn't much of a reason NOT to send HTML emails by default...
-
- $message is parsed only once, AFAIK, and then sent to multiple recipients (i.e. sendmail() supports multiple recipients). So I don't think there's any problem with the number of calls to PURL code...
- Then what should we do? Convert anchors to text..?
-
- $message is parsed only once, AFAIK, and then sent to multiple recipients (i.e. sendmail() supports multiple recipients). So I don't think there's any problem with the number of calls to PURL code...
Not to mention that sendmail can still pass its own content BACK to itself. But that's less of an issue.- Then what should we do? Convert anchors to text..?