Problem/Motivation

We should provide a template to customize the content of the notification emails. It is a better approach than to rely on customizing the swiftmailer, since we might not want to depend on swiftmailer in the future and usually I prefer to have one global swiftmailer template and customize it's content in separate templates.

We should pass all relevant data such as the product variation (currently not available at all) and the message to that template.

One example is the commerce_order_receipt theme/template: https://git.drupalcode.org/project/commerce/-/blob/8.x-2.x/modules/order...

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Lukas von Blarer created an issue. See original summary.

luksak’s picture

Issue summary: View changes
luksak’s picture

Status: Active » Needs review
StatusFileSize
new5.19 KB

Here is a first working patch. I applies on to of #3200315: Notification form breaks add to cart form with multiple variations, since without that patch this module is currently basically unusable.

The actual issue I was trying to solve is to render the product variation in the email. The render array can be provided like this in a custom theme:

/*
 * Implements hook_preprocess_HOOK().
 */
function THEME_preprocess_commerce_stock_notifications_message(&$variables) {
  /** @var ProductVariation $product_variation */
  $product_variation = $variables["product_variation"];
  $view_builder = \Drupal::entityTypeManager()->getViewBuilder('commerce_product_variation');
  $variables['product_variation_teaser'] = $view_builder->view($product_variation, 'teaser');
}

And can be output like this:

{#
/**
 * @file
 * Template for the stock notification message.
 *
 * Available variables:
 * - message: The message
 * - product_variation: The product variation.
 * - product_variation_url: The product variation url.
 * - user: The user.
 * - mail: The mail address.
 *
 * @ingroup themeable
 */
#}

<div class="commerce-stock-notifications-message">
  {{ message }}
  {{ product_variation_teaser }}
</div>
luksak’s picture

StatusFileSize
new5.28 KB

There was an issue in the previous patch. Here is the fixed one.

I realized that the patch from #3200315: Notification form breaks add to cart form with multiple variations is not need for this to work.

The patch additionally fixes an issue with email address that don't belong to any user throwing an error, because setting the language of the mail can't work using the user language.

poker10 made their first commit to this issue’s fork.

  • poker10 committed 68b5ea4c on 8.x-1.x authored by luksak
    Issue #3322273: Provide a template to customize the content of the...
poker10’s picture

Status: Needs review » Fixed

Thanks for reporting and working on this. I think this is a useful feature.

Updated the code in the MR:
- moved the logic from the .module file to the CommerceStockNotifyQueue::processItem()
- removed static call to Drupal::service()
- kept the original parameter names for BC
- added DeprecationHelper to handle renderPlain deprecation
- removed the language fix which landed in another issue

Merging this to the 8.x-1.x now. Further improvements can be made if needed in follow-ups. Thanks!

poker10’s picture

Need to say, that previously, it was possible to send non-filtered HTML in the $message variable directly to the email body (which is not good from the security perspective). After this commit, the variable is filtered by twig (which is not good for BC reason). We cannot use Xss::filter() or any other filtering because some sites could have a whole HTML pages in the field HTML body field (including styles, attributes, various HTML tags, ...), so it would not help much regarding BC. It seems like that any filtering option will have a potential to break the "unlimited" options provided until this was committed.

I am not sure how extensively this HTML options were used, but I think there are two options now:

1. Keep it filtered by default (as it is now) and force existing sites to convert the field HTML to the twig (which is the most secure way) or to override the template and use the |raw filter (the fastest way).

2. Mark the Administer Commerce stock notifications permission as restricted and allow |raw filter on the $message variable in the default twig template. That is not a best solution, but this will preserve all options.

Will wait for some opinions from sites using the module. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

thalemn’s picture

I'm testing this module and like much of the functionality. Thanks!

As for the message html filter, I'm not understanding what is actually happening. I am overriding the meessage template, but if I put html in there, for example <h2>hello world</h2>, the message prints the tags and not the style.

In the Stock Notifications Settings, if I put html in the HTML Body field, it prints out the tags but only if I add the |raw filter to the {{ message }} var.

When I add tokens to the HTML Body field, they appear to work as expected.

Thanks for any help with understanding the HTML filtering. I would like to be able to add HTML Tag styles.

One more thing, I also tried using the Symfony Mailer policy, but I could not pass the tokens through that body field. But my html tags worked as expected.

luksak’s picture

@thalemn I'm facing the same issue and I created a follow-up regarding this: #3532501: All HTML in commerce-stock-notifications-message.html.twig is being escaped

Could you explain how you solved this?

I don't understand your comment regarding Symfony Mailer policy. How did you make this work?

thalemn’s picture

@luksak

I have put this work on hold for the time being. I never did solve the issues, and did not get anything to work using the mailer policy. Sorry I can't be of more help at this time.

luksak’s picture

@thalemn all good, thank you for your feedback!