zengenuity → created an issue.
zengenuity → created an issue.
zengenuity → created an issue.
I'm going to postpone this issue for now to see what develops with the core issue ✨ Entity reference: allow specifiying that every bundle is allowed Needs work .
In the meantime, Webform emails can be sent via Easy Email with the changes made in ✨ Create a way to generically override an email without parameter mapping Active .
From that issue, there is a new option in the Easy Email Overrides module that allows you to provide a (probably blank) template and have it copy over the content from the originally sent email to it on sending. In addition, overrides can now match sent emails by module or match all sent emails from the website. So, you can configure an override to wrap all emails from Webform in an Easy Email template before sending. This should address most of the use cases people have related to integrating Webform and Easy Email.
zengenuity → created an issue.
zengenuity → created an issue.
zengenuity → created an issue.
zengenuity → created an issue.
zengenuity → created an issue.
zengenuity → created an issue. See original summary → .
zengenuity → created an issue.
I have this functionality mostly working the MR. However, in practice, this core issue makes it hard to use: https://www.drupal.org/project/drupal/issues/3031637 ✨ Entity reference: allow specifiying that every bundle is allowed Needs work
I think when you build a template for a webform notification, you would normally want to have an entity reference field that holds a reference to the submission the email is about. That's how you get the tokens in the email template.
You can do this, and it works, but core requires that every entity reference field specify allowed bundles, which means that you have to specify the exact webforms in the field configuration. You can't just specify any webform submission. This doesn't prevent you from using an override for the webform, but it creates an unintuitive issue where you have to update the field configuration any time you add a new webform to the site, or you have to create a new webform submission entity reference field for each template. Each of these is somewhat annoying.
I'm still going to finish this up and release it, but I wanted to acknowledge the issue here, since it's likely to come up once this feature is available.
zengenuity → created an issue.
Merged. Thanks.
zengenuity → made their first commit to this issue’s fork.
Here are four things I think we should review for Easy Email in Drupal CMS.
1. Storing sent emails: By default, Easy Email stores all sent emails, which are then visible to review under Reports > Emails. (Security-related tokens like one-time login URLs are stripped out before saving.) For sites with a lot of users, this may increase the database size quickly. This functionality is configurable per template. So, we can decide to turn it off for all core emails or for specific ones.
2. Truncating sent email log: Each template has a setting to automatically delete the sent emails of that type from the database a certain number of days after sending. By default, this feature is disabled, and it's currently disabled on the core templates in the Easy Email Express Mail recipe. This functionality runs on cron, and there is a global setting that allows you to configure the maximum number of emails to delete on each cron run. The default is 50.
3. Theme: The recipe includes the Easy Email Theme → , which is an extremely simple theme that I created specifically for sending emails. The design is very basic. There's a grey body background, white content background, and then your email content is in there. It does have a header inside the white box which will include either your site name or logo if they are configured in the Easy Email Theme. The default theme logo is the Drupal logo, the result of which you can see on the Easy Email Theme page as a screenshot. What I have is functional, but it perhaps could be improved. I'm more of a backend dev, so the design stuff is not my forte.
4. Disabling the core email template edit form: In the recipe, all the core user-related emails are overridden by Easy Email. However, you can still see the editing boxes for them under Configuration > People > Account settings. This could be confusing for users, since editing the email templates there will do nothing. You need to edit the templates in Easy Email. I was planning to add a feature to the Easy Email Overrides submodule that would disable/hide the appropriate email elements on this page when they've been overridden by Easy Email. I was going to replace the form elements with a link to the related Easy Email template edit page. I think this feature would be important to have for Drupal CMS, but it's not built yet.
zengenuity → created an issue.
I'm the maintainer of Symfony Mailer Lite and Easy Email. If there's anything I can do to assist with this effort, please let me know. Both the Easy Email module and the recipe are somewhat opinionated in their defaults, with the goal of making things as easy as possible to set up. Some of those defaults may not be the best choice for something included in Drupal CMS. I'm happy to help with setting up a different recipe or adding more configuration options or features to the underlying Easy Email module or theme.
zengenuity → created an issue. See original summary → .
zengenuity → created an issue.
zengenuity → created an issue.
The project description starts with: "Easy Email Theme is an email-only theme to be used for sending HTML-formatted emails."
This theme is not intended to be used as your default site theme. If you want to use it for emails, that can be configured in the Mail System module configuration, or in the Drupal Symfony Mailer configuration if you're using that module.
Yes, I agree that we can just remove the file extensions here.
Merged. Thanks!
I think if we remove the zpl, epl, epl2 extensions from this field, we should remove all the extensions from it. Otherwise, I think the shipping label will fail validation on save if you have a zpl, epl, or epl2 file.
If we just remove them all, the field will allow any file to be uploaded, which is probably fine here.
The MR looks good. Merged. Thanks!
zengenuity → made their first commit to this issue’s fork.
@rodrigoaguilera, thanks. Merged.
zengenuity → made their first commit to this issue’s fork.
zengenuity → created an issue.
Okay, sounds good. Merged. Thanks!
Okay, I'm on board with making this change. However, it doesn't seem like it totally works correctly. Here is what I see on the translation form in Drupal 10 now:
Is that correct? Why there is a CkEditor on the left side? It allows you to enter text into it, but it just ignores it. The one on the right seems to work. Is this how it's supposed to be, or is it a core bug?
If this is how these always work, then it's fine. I just want to make sure we're not doing something wrong. I don't work with multilingual sites regularly, and I'm not familiar with what's normal.
Seems reasonable. Merged. Thanks!
zengenuity → made their first commit to this issue’s fork.
I think this is a duplicate of this issue: ✨ Improve Translation User Interface Active . Your mention of CKEditor is more specific, but I intended that as part of the other issue of reusing our existing form for translations.
I'm not managing any multilingual sites at this time, so I'm unlikely to find time to address this anytime soon. But, I will definitely review and accept any patches if someone else wants to tackle the issue.
This would introduce a security vulnerability similar to https://www.drupal.org/sa-contrib-2024-006 → , so I can't accept the patch as it's provided.
When I wrote this check, I broke this functionality into a service so that sites that want to do something different can override it. So, if you want to allow images to be embedded from a theme folder, you can do that by decorating or replacing the EmbeddedImageValidator service in a custom module. I still would advise against removing the folder check entirely in your service, to avoid introducing a vulnerability to your site. Just allow the specific folders you want to allow.
For anyone else looking for this, I figured out how to do it with that event. Here's the important part of my subscriber.
<?php
/**
* {@inheritDoc}
*/
public static function getSubscribedEvents() {
// Run this with low priority so that other subscribers can add their templates first.
return [
LayoutParagraphsAllowedTypesEvent::EVENT_NAME => ['filterTemplates', -100],
];
}
/**
* Filter templates to the allowed types.
*
* @param \Drupal\layout_paragraphs\Event\LayoutParagraphsAllowedTypesEvent $event
* The allowed types event.
*/
public function filterTemplates(LayoutParagraphsAllowedTypesEvent $event) {
$template_types = $event->getTypes();
if (($layout = $event->getLayout()) && ($entity = $layout->getEntity())) {
$entity_type = $entity->getEntityTypeId();
$bundle = $entity->bundle();
// Your logic here to remove items from $template_types
$event->setTypes($template_types);
}
}
?>This all looks good now. I tested it manually on D10 and D11, and it worked in both places.
I've merged the MR and created a new release: 3.0.1. Thanks for your work on this!
Today, I also released a new version of Drupal Symfony Mailer Lite → that is D11-compatible. So, we have a full D11 solution for emails on day 1. (currently using dev branches for Mail System and Token, which are D11 compatible)
I published the 2.0.0 release today, which is D11 compatible. Thanks!
The addPart() method wasn't added until symfony/mailer 6.2, so the dependencies are not correct in the current MR. Since we're dropping support for D9, and symfony/mailer 5, I think we should bump the major version number. I've opened a new 2.0.x branch.
Okay, I'm also fine with coding the header into this module, given that $langcode should always be present in the $message array. We should just have a check to make sure it's not LANGUAGE_NONE. In that case, we should skip the header.
Do $message arrays typically have a langcode key in them, or is that something that you're going to add on your site manually with hook_mail_alter or in the hook_mail? If so, I think you should be able to just add $message['headers']['X-Langcode'] right there, and it wouldn't require any changes to the module. I think it would only make sense to change the module if Drupal was automatically adding langcode and we're currently ignoring that.
Also, it appears there is an official header for language, and it's Content-Language: https://www.rfc-editor.org/rfc/rfc4021.html#section-2.2.10. So, if we add something to the module, we should probably try to use that.
This module doesn't force a change to the content type of your email unless you check the box to always use the default content type.
The contact form must be sending a plain text email, and this module is dutifully passing it along in the specified content type. Check the box to always use the default, and it will force a change to the content type. However, note that this can lead to formatting issues. It will use the Plain Text text format to convert plain text to HTML, so you can adjust that format if you're unhappy with the results of the conversion.
zengenuity → created an issue.
Looks good. Merged. Thanks.
@mandclu, this looks good except the switch from fnmatch() to glob(). That code crashes when I test it.
I also made a few additional changes to the handling of dependencies in easy_email_commerce to make sure we don't crash from missing modules there.
zengenuity → made their first commit to this issue’s fork.
I've added Commerce Shipping Colissimo to the project page.
This looks good. Merged. Thanks!
zengenuity → made their first commit to this issue’s fork.
zengenuity → created an issue.
The code looks fine at first glance. However, when does a PaymentIntentEvent fire? Do we need to check the status of the event to make sure we're only recording the fee when the payment has actually succeeded? In the Commerce Stripe code, I see that the TransactionDataEvent is only dispatched when the status of the PaymentIntent is REQUIRES_CAPTURE and SUCCEEDED, and when count($intent->charges->data) !== 0.
https://git.drupalcode.org/project/commerce_stripe/-/blob/8.x-1.x/src/Pl...
Do we need a similar check to make sure we're not importing the fee when the charge was declined?
Looks good. Merged. Thanks!
zengenuity → made their first commit to this issue’s fork.
I think CkEditor will mess up the tokenized link if you use Basic HTML or some other limited HTML format. Try using Full HTML or another format without tag filtering.
We can't include that file for licensing reasons, but we should add instructions and a check for it before installing to prevent the crashing.
zengenuity → created an issue.
Email tokens only appear in the context of an easy email entity. If you're viewing the token browser from another page, not the edit template page, then I would not expect easy email tokens to be available. There would be no email for them to refer to.
If you're having an issue on the email template edit page, then you can feel free to reopen this issue, but for now I'm going to close it.
Hi, I'm the maintainer of the Commerce Shipping Label module. Please let me know if you need any help integrating with it. The module currently only works with Commerce EasyPost, but we're using that combination in production without any issues. I'm confident recommending it for other modules to adopt.
Commerce Shipping Label provides you with a user interface for generating a remote shipment and optionally scheduling a pickup. (It's an extension of the current Shipments tab on an order.) It also provides the storage for the label files and customs documents. There's a submodule that integrates with Zebra Browser Print (https://developer.zebra.com/products/printers/browser-print), that allows you to print ZPL files to a connected printer directly from the Drupal web interface.
If you were to adopt Commerce Shipping Label as a base, you would only need to implement some interfaces that it provides, and you could focus on the UPS API rather than doing all that user interface work. The interfaces that are there now were designed to work with EasyPost, so please let me know if they are incompatible with how the UPS API works in some way. I'm sure we can adjust them to work.
Looks good. Committed. Thanks!
Just to clarify this, before closing this issue: This issue is Acquia-specific. They appear to be altering the symfony mailer transports at a platform level, and following the specific steps outlined in #9 avoids problems caused by this. Ideally they would document this better.
As for the other comments about sendmail not working in XAMPP or other dev environments: Everyone needs to understand the requirements for sending email from their chosen development or production environment. These requirements will not be the same between different environments, so what solves the problem for XAMPP is not going to fix your problem in DDEV or something else. Please don't blindly adopt the solutions provided by other commenters without understanding what you're doing.
Specifically to address the comment in #14 about installing the SMTP module: This module allows you to send with SMTP if you like. You just need to configure SMTP as your transport. I would not recommend combining the SMTP module and this module together. Not only is it redundant, but it could cause unpredictable problems in the future if the modules do things differently.
We have a solution to the original Acquia-specific problem, so I'm going to mark this as Fixed.
I tested a fresh install of this module with the settings you show configured. When I created a new user account, I received the email notifications fine. The body had the standard text in it, converted to HTML.
<p>testcreate,</p>
<p>Thank you for registering at Drupal 10. Your application for an account is currently pending approval. Once it has been approved, you will receive another email containing information about how to log in, set your password, and other details.</p>
<p>-- Drupal 10 team</p>Perhaps you should check your Plain Text text format to make sure there's nothing in there that could be interfering with the conversion of the text.
Looks good. Merged. Thanks!
zengenuity → made their first commit to this issue’s fork.
This looks good. I switched it to casting as string instead of using __toString(), just to be consistent with other places we're doing this in the same file. This is merged in.
zengenuity → made their first commit to this issue’s fork.
zengenuity → created an issue.
I think you could also use Config Ignore module to ignore the local SMTP transport configuration.