Skip to main content
Topic: Registration emails (Read 1569 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Registration emails

Reply #15

Quote from: tino – From what I can tell the links are still parsed correctly in the two clients? Which is the main issue to resolve.

Correct - it's a client issue, not an ElkArte issue. If you notice, the links in HTML/Rich-Text work correctly in each client (even with the line-wrapping).  Of my examples, it's only Pegasus in plain text mode that goofs it up.  Someday I presume Pegasus will fix that (too).
See the roundcube html links - because of its particular interface it wraps the last long link twice. It still works. I imagine a smartphone would wrap that link onto 4 or 5 separate lines (or do something like https://www.elkarte.net/community/index.php?action=.....)

So, it doesn't matter how much or what formula of Techron that Chevron puts in their gas, it's not gonna make Leroy's old motor with the worn rings and blown head-gasket pass the annual emissions-check.  :cheesy:  (If they tried to it would probably start messing up other motors instead).
Last Edit: December 31, 2022, 02:41:48 pm by Steeley

// Deep inside every dilemma lies a solution that involves explosives //

Re: Registration emails

Reply #16

The email issue(s) are a bit of a saga.  

Going way back to the original fork point, the existing email function sendmail was super janky (of course IMO) It was littered with ancient conditionals and other cruft.  So knowing that, we did what you always do, build on top of it ... nothing wrong with building on a weak foundation, that never comes back to:punch::face_with_spiral_eyes:back.   As issues showed up, mainly with our PBE (Post by Email / Listserver) functionality, various areas were updated, which of course exposed other issues.

Note that in 2.0 I could not take it any longer and redid the entire email function, such that whoever picks this up in the future can call it janky!  The new functions will send real HTML, not what occurs in 1.1 which is plain or base64 text but sent as HTML.   By real HTML I mean crusty old HTML wrapped in tables and inline style ... this due to the fact that there are some real old dinosaur email clients out there, and those are what render the HTML so you have to use some ugly markup.

Anyway, in 1.1 various attempts were make to live with it, and there were various "fixes" applied to the email formatters and converters, which often caused other interesting problems.  1.1.9 continues on that fine tradition, and again made updates, mostly back ported from 2.0.  One area that can cause the break is when we convert the email to markdown syntax (as its more expressive then plain text, and we don't due HTML).  There was a wrapping issue in that as I recall.

I'll check if the 1.1.9 file will work in 1.1.8, just as a test, but that may not fix it at all.  As noted, often the email client will butcher those links, and we have tried the <> trick and several others.  Often the client just grabs the first section (plain text) uses that and then wraps it at 78-80 characters, and a period is a great wrap point as what is a link in plain text?  They should prefer the most 'correct' version of the message in the email plain -> base64 encode -> html but that does not always happen (and some shut of HTML anyway)

I'll give the new function a spin on 1.1.8 just for the experiment and report back.

Re: Registration emails

Reply #17

Going back to the original post by BK, I think the complaint was the wrap of the link - not that the link didn't work. If that is the case, there's nothing EA can do about that, as that is purely the function of the client interface. With long urls, the client has to do something for presentation purposes. If it's a smartphone display, I've often seen the url truncated and "....." concatenated to the displayed url (and I'm reluctant to click a link I can't read all of, so that's not my ideal solution), instead of wrapping.

Now, if the link is "broken' (click on it and it doesn't call the intended resource), that can be fixed server side (in most cases), but not all (as the plain text chops them up in Pegasus shows). Nothing EA can do to fix the Pegasus rendering, nor should it try - the  other clients all handle those links just fine in plain text. It's a Pegasus problem.

So maybe the first question should be back to @Burke_Knight - is this an aesthetic issue, or a function issue?  The latter is resolvable, but aesthetic is purely a client issue.

Edit: For the record, this is what I get from EA 1.1.6  (no html encoding at all..)

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit



<*> To visit the forum on the web, go to:
    h...s://mydomain.com/myforum

<*> You can see this message by using this link:
    h...s://mydomain.com/myforum/index.php?topic=129.new#new

<*> You can go to your first unread message by using this link:
    h..s://mydomain.com/myforum/index.php?topic=129.new#new

<*> Unsubscribe to this by using this link:
    h..s://mydomain.com/myforum/index.php?action=notifyboard;board=40.0

And the last link is "broken" at the semi-colon (again, that's Pegasus)
And I had to modify the "https" so the forum wouldn't slap it's own link rendering over my display formatting when I pasted it.
Last Edit: December 31, 2022, 04:04:23 pm by Steeley

// Deep inside every dilemma lies a solution that involves explosives //

Re: Registration emails

Reply #18

@Steeley sending real html as happens with ElkArte 2 should resolve it in all instances. Even if it is html from the dark ages. If you disable that in the client or use one which doesn’t support it then you’re on your own.

The big ones however do favour html over plain text. Outlook, GMail, Thunderbird, Mail, etc


Re: Registration emails

Reply #19

Quote from: tino – @Steeley sending real html as happens with ElkArte 2 should resolve it in all instances. Even if it is html from the dark ages. If you disable that in the client or use one which doesn’t support it then you’re on your own.

The big ones however do favour html over plain text. Outlook, GMail, Thunderbird, Mail, etc



Agreed - and Pegasus renders html-formatted URL links just fine (it just messes up URL links sent plain text formatted at various punctuations within the link - again, a pegasus problem, not a server-side problem).

The question for BK is whether he is objecting to the presentation of the long URL in the email, or is the link actually "broken" (as Pegasus does to text-formatted urls).

I think what the current EA version (2.0?) is doing is fine as far as email html-formatting (which v.1.1.6 doesn't do). I'm not sure what EA version BK is using and whether it has been 'back-ported' or not, but if, as I'm assuming, it's just the presentation aesthetics (wrapped url) that isn't going to be "fixed" server-side, that's what the client is doing with it.  Virtually every client and forum I've seen now will wrap an html formatted long url at the "?" (or other embedded punctuation character), which makes sense from a human-readability point of view. The client has to do something with a long URL that won't fit on one line within its interface. 

Pegasus, like Roundcube and most other clients that support both formats have a toggle to switch between html and plain-text formatting.

Last Edit: December 31, 2022, 04:56:11 pm by Steeley

// Deep inside every dilemma lies a solution that involves explosives //

Re: Registration emails

Reply #20

Quote from: Steeley – Going back to the original post by BK, I think the complaint was the wrap of the link - not that the link didn't work.

So maybe the first question should be back to @Burke_Knight - is this an aesthetic issue, or a function issue?  The latter is resolvable, but aesthetic is purely a client issue.

No, the complaint was not just the wrap, but that said wrap broke the link.
When click the visible link before the break, it goes to:
Code: [Select]
https://www.allpointswh.com/index

It does not even have the .php in the link, causing a 404.
This means it's a 100% function issue.

That said, I know they can always just copy/paste the full thing, but with a line break in the middle of a link, not sure how some browsers might react. Most should do right, but of course, with so many off-the-wall browsers out there now, one never knows...  :wink:

Edit: All my forums are ElkArte 1.1.8

Re: Registration emails

Reply #21

Quote from: Burke_Knight –
No, the complaint was not just the wrap, but that said wrap broke the link.
When click the visible link before the break, it goes to:
Code: [Select]
https://www.allpointswh.com/index

It does not even have the .php in the link, causing a 404.
This means it's a 100% function issue.

That said, I know they can always just copy/paste the full thing, but with a line break in the middle of a link, not sure how some browsers might react. Most should do right, but of course, with so many off-the-wall browsers out there now, one never knows...  :wink:

Edit: All my forums are ElkArte 1.1.8

Alrighty-and @Spuds is now in the loop on that. 
(If he gets a back-port for 1.1.8, instead of pushing an upgrade to 1.1.9 maybe it will work for 1.1.6 too? :pray: . But if not no biggie for me, the text rendering works fine - if you're not using Pegasus anyway.)
Last Edit: December 31, 2022, 05:24:55 pm by Steeley

// Deep inside every dilemma lies a solution that involves explosives //

Re: Registration emails

Reply #22

After extensive testing ( it worked once ) using the html2md file from 1.1.9 on 1.1.8 did not break the link (using online gmail and a separate gmail client)

In my testing the link was fine if the core feature Post by Email Management is not enabled.  However when enabled and setup, the link can break during the markdown conversion.  If you are not using the maillist / listserver functions, this will make no difference, but in this case the site has that enabled so will see a change.

Replace your Html2Md.class.php file in sources/subs with the one attached and let us know how this works for you.


Re: Registration emails

Reply #24

Quote from: Spuds – After extensive testing ( it worked once ) using the html2md file from 1.1.9 on 1.1.8 did not break the link (using online gmail and a separate gmail client)

In my testing the link was fine if the core feature Post by Email Management is not enabled.  However when enabled and setup, the link can break during the markdown conversion.  If you are not using the maillist / listserver functions, this will make no difference, but in this case the site has that enabled so will see a change.

Replace your Html2Md.class.php file in sources/subs with the one attached and let us know how this works for you.

No surprise, when added to v 1.1.6, while it changed the second section of the email from 7bit encoding to base64 and changed that sections enclosed text to "Ck9uY2UgbW9yZSBpbnRvIHRoZSBicmVlY2gKAAoKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t......."

...none of my email clients render it in html.

I was hanging onto this thread by my fingernails (technically), and just lost my grip.. I don't see the difference in the received email formatting now between an email sent by EA 2.0 and EA 1.1.6 with this file, but from 1.1.6 the email doesn't render html at all, still, where 2.0 does just fine.  Obviously I'm missing something, something is different but I don't recognize any obvious deltas that would account for it, but ... that's OK.  Just thought I'd give it a  shot and see..





 

// Deep inside every dilemma lies a solution that involves explosives //


Re: Registration emails

Reply #26

Quote from: Spuds – The email issue(s) are a bit of a saga.  

-= snip =-

 As noted, often the email client will butcher those links, and we have tried the <> trick and several others.

-=snip=-

@Spuds

I just confirmed if the plain-text urls (even very long ones), are delimited with angle-brackets Pegasus renders them properly.. So, when you get a chance, Spuds., if you could 'splain to me what to modify. in 1.1.6 (since that is sending only plain-text emails..) I'd be much obliged 'n stuff, ya know?  :cool:

// Deep inside every dilemma lies a solution that involves explosives //

Re: Registration emails

Reply #27


Well, my forum supports a bunch of old 'nam vets who are long in the tooth and dwindling in numbers, and they don't deal with changes well. Not only that, but the forum owner is also an old 'nam vet who is slowly losing his marbles  :zany_face:  and is skittish of slapping an upgrade on top of a production platform that is otherwise working acceptably. I don't mind a tweak here and there to eliminate little annoyances, but I've learned over the years that "incompatibilities are just an upgrade away".  If I had a test platform to work with that's one thing.. but I don't, so if I can make 1.1.6 continue working as I've got it set up now, I can eventually fade away with a smile on my face and a song in my heart (instead of frowns and curses trying to figure out what I just broke..).    

// Deep inside every dilemma lies a solution that involves explosives //

Re: Registration emails

Reply #28

@Steeley I have not forgotten, I'm just stuck on some other things ATM!

Re: Registration emails

Reply #29

No hurry.. it's just a minor niggly for a few of us, and we know how to deal with it. But if I can make a quick code edit or two so the plain-text urls are also delimited and that makes it go away, cool.

Like a pinch of powdered sugar on the cherry on an ice cream sundae.. just a nice touch to let my brothers know they're loved, ya know?

// Deep inside every dilemma lies a solution that involves explosives //