Zeitwerk simplifies working with dependencies in dev and makes it easier reloading class chains.
We no longer need to use Rails "require_dependency" anywhere and instead can just use standard
Ruby patterns to require files.
This is a far reaching change and we expect some followups here.
This feature adds the ability to customize the HTML part of all emails using a custom HTML template and optionally some CSS to style it. The CSS will be parsed and converted into inline styles because CSS is poorly supported by email clients. When writing the custom HTML and CSS, be aware of what email clients support. Keep customizations very simple.
Customizations can be added and edited in Admin > Customize > Email Style.
Since the summary email is already heavily styled, there is a setting to disable custom styles for summary emails called "apply custom styles to digest" found in Admin > Settings > Email.
As part of this work, RTL locales are now rendered correctly for all emails.
This reduces chances of errors where consumers of strings mutate inputs
and reduces memory usage of the app.
Test suite passes now, but there may be some stuff left, so we will run
a few sites on a branch prior to merging
We had quite a few cases in core where inputs are being mutated as a side
effect of calling a method.
This handles all the cases where specs caught this.
Mutating inputs makes code harder to reason about. Eg:
```
frog = "frog"
jump(frog)
puts frog
"fly" # ?????
```
This commit is part of a followup commit that adds # frozen_string_literal
to all our specs.
currently, Discourse uses '---' in its notifications to
separate the signature with unsubscribe links etc. from
the body of the message.
The RFC standard defines '-- '.
https://www.ietf.org/rfc/rfc3676.txt (4.3)
The problem has been discussed in:
https://meta.discourse.org/t/previous-replies-separator-is-not-rfc-compliant/39410
And an incomplete fix has been added a year ago:
86819f08c3
The separator is important, because some mail clients strip off the
signature automatically in replies if the signature is recognised as such.
Use "Site Name <>" for the Reply-To header when the reply is to the site or a public topic.
Use "username <>" for the Reply-To header only when the reply is to a private message topic.