discourse/app/services/user_notification_renderer.rb

# frozen_string_literal: true

class UserNotificationRenderer < ActionView::Base
  include ApplicationHelper
  include UserNotificationsHelper
  include EmailHelper

  LOCK = Mutex.new

  def self.render(*args)
    LOCK.synchronize do
      @instance ||= UserNotificationRenderer.with_empty_template_cache.with_view_paths(
        Rails.configuration.paths["app/views"]
      )
      @instance.render(*args)
    end
  end
end
FEATURE: customization of html emails (#7934) 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. 2019-07-31 03:05:08 +08:00			`# frozen_string_literal: true`

			`class UserNotificationRenderer < ActionView::Base`
			`include ApplicationHelper`
			`include UserNotificationsHelper`
			`include EmailHelper`
PERF: reuse renderer when rendering email templates Previous to this fix we were leaking methods on the internal action view template class per render. This caused email generation to be very low and a steady memory leak in the application in sidekiq when sending out emails The behavior change is new to Rails 6 so this fix does not need to be backported into stable. 2019-10-07 11:57:03 +08:00
FIX: during concurrent emails generation renderer should not be reused Our instance used for template rendering needs a lock to ensure there is no race condition where rendering happens on 2 threads at the same time. This can lead to local poisoning which can cause unexpected results in emails 2019-10-10 05:50:48 +08:00			`LOCK = Mutex.new`

			`def self.render(*args)`
			`LOCK.synchronize do`
DEV: Upgrade Rails to 6.1.3.1 (#12688) Rails 6.1.3.1 deprecates a few API and has some internal changes that break our tests suite, so this commit fixes all the deprecations and errors and now Discourse should be fully compatible with Rails 6.1.3.1. We also have a new release of the rails_failover gem that's compatible with Rails 6.1.3.1. 2021-04-21 17:36:32 +08:00			`@instance \|\|= UserNotificationRenderer.with_empty_template_cache.with_view_paths(`
FIX: during concurrent emails generation renderer should not be reused Our instance used for template rendering needs a lock to ensure there is no race condition where rendering happens on 2 threads at the same time. This can lead to local poisoning which can cause unexpected results in emails 2019-10-10 05:50:48 +08:00			`Rails.configuration.paths["app/views"]`
			`)`
			`@instance.render(*args)`
			`end`
PERF: reuse renderer when rendering email templates Previous to this fix we were leaking methods on the internal action view template class per render. This caused email generation to be very low and a steady memory leak in the application in sidekiq when sending out emails The behavior change is new to Rails 6 so this fix does not need to be backported into stable. 2019-10-07 11:57:03 +08:00			`end`
FEATURE: customization of html emails (#7934) 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. 2019-07-31 03:05:08 +08:00			`end`