Thank you for extensive write-up. I finally find some quite free eventing to have a look into that.
Translations contain the link as "^url" in qa-include/lang/qa-lang-emails.php
Notifications are send from:
* the translations and actual URLs are gathered together, but yet not substituted
* qa_q_path() is used to get the URL, there is qa_q_path_html(), which would be cleaner solution.
* substitutes the ^url for the actual link
* "redefined" by plugin.
* gets already substituted in plaintext format
* uses several methods to convert to HTML: qa_html()
So what is the actual problem?
* We have non-html message which is just put into HTML "frame" and send.
* This is not the problem of the core, but the problem of the plugin. Though having this feature in the core would be nice, but there ain't nobody having time for doing this from scratch into existing project.
So what to do?
* as you propose use some regex to rewrite the URL to valid HTML link. This seems ugly, because it might break also other stuff
* "overwrite" also qa_send_notification() and inject the html in the links makes more sense.
My commit. I will propose it as a pull request later, if you will be satisfied with such solution:
To the broken links (I saw few of them also recently), I believe it is caused by the weird encoding:
* content-transfer-encoding: quoted-printable
It is fine for normal text, but it breaks html and long lines. Have a look in the source code of the notification mails. It is real pain, especially with all that CSS.
Example from one of the broken mails:
It should be possible to instrument the PHP Mailer to use different encoding, I would be for classing base64 to make sure it is delivered as it is send, though it might be arguable. The idea:
diff --git a/qa-include/app/emails.php b/qa-include/app/emails.php
index da9ab33..955cc08 100644
@@ -133,6 +133,7 @@
+ $mailer->Encoding = 'base64';