This is a major enhancement of the Content Moderation Notifications (CMN) module allowing complete control of TO, CC, BCC, FROM, REPLY-TO, SUBJECT, and MESSAGE fields, adding full Twig support to all fields, changing Token support, allowing dynamic messages to be displayed, improved support for hook_mail_alter(), intelligent non-sending of notifications if no recipients or if a specified "Abort" email is found, expanded help text on fields, a VERY helpful debugging mode (no more switching back and forth between email and web a zillion times) and on-screen list of commonly used {{ variables }}.
- Add Twig support
- Working patch in #2953489: Add Twig support in Subject, Email, and Message fields, which is being dropped in favor of this expanded module.
- All text fields are now draggable-expandable textarea fields
- Helpful UI feature auto-expands all fields (on page load) to show full contents of all fields without having to manually resize them
Change Token support
- (Left this as is and expanded Token support to all fields for better compatability)We could add direct parsing of tokens as well, but I think using the Twig Tweak module's drupal_token() function is
sufficient, as it allows the use of all tokens within Twig's frameworkSupporting both Twig and Token could result in unwanted tokenizing of Twig output (or vice versa)Using token filtering could result in the stripping of token-like text from fields, such as "[DRAFT] {{ title }}" in a Subject field
- Replace "Recipients" (in #2946360: Make the recipient configurable) and "Adhoc Email addresses" fields with more standard TO, CC, BCC, FROM and REPLY-TO
fields. (high priority)- This would allow people to form the emails however they want, particularly if we include the Twig templating
logic on all of them.
- This would allow people to form the emails however they want, particularly if we include the Twig templating
- Prevent sending emails if no recipients
- No email will be sent if there are no recipients specified in the TO, CC and BCC fields.
- Allow an Abort ("kill-switch") email address (maybe "abort@example.com" or "noemail@example.com") that, if found in any
address or message field, will cause the module to NOT send a notification message. (Medium Priority)- This would be useful in use cases such as "if the editor is also the author, don't send them an email (since
they already know it's reviewable or published)", and the twig logic could return the abort@example.com email in
this case to prevent emails from being sent. - The current module would still send the email to the Recipient (site email address) even if no other
recipients are specified.
- This would be useful in use cases such as "if the editor is also the author, don't send them an email (since
- Allow Dynamic messages to be displayed on-screen after notifications are sent by using Twig Tweak module's drupal_set_message() function. For example, in any field you can add the Twig code:
- {{ drupal_set_message( ':author has been notified of this edit'|t({':author' : user.displayName})) }}
- Add a "Debug Mode" checkbox that would display all the fields (To, Cc, Bcc, From, Message, etc.) to the screen via
drupal_set_message() and NOT send out any emails.- This will make debugging messages and Twig code much simpler and much less spammy.
- Debugging can be done without switching between Drupal and email apps.
- Pass mail key containing Notification.id instead of module name
- This would allow hook_mail_alter() calls to be able to target specific notifications
- Add an expandable "Common Replacement Patterns" section to the Edit Notification page
- Include a list of the most common tags, such as {{title}}, used in the messages
to make life easier for admins
- Include a list of the most common tags, such as {{title}}, used in the messages
- Figure out a decent way of having non-WYSIWYG Twig code in the Message value (Lower Priority)
- Putting Twig code in the WYSIWYG can be challenging as it adds DIV, SPAN and NBSP in the code
- Working in Source view defeats the point of having the WYSIWYG
- Simple solution would be to include an external template. Examples:
- {% include('cmn--editorial--draft.twig.html') %}{# have the template do all logic and output #}
- {% include('cmn--editorial--draft.twig.html') %}{# have the template do only logic and put output after here #}{{ user.email }} Edited this Draft
- Any better ideas on how to do this?
- Figure out a better way of handling Twig errors than WSOD and having to look at the logs for the error
message- Maybe wrap in try..catch and display an error (at least if in Debugging mode)
These updates aren't perfect yet but I wanted to get it up ASAP to gather any feedback before final polishing. Any help (particularly with writing tests) is welcome!
The existing patch is fully functional and is in production use now.
Things Still To Do (that I know of):
Fix ConfigFactory dependency injectionCurrently getting settings directly
Remove Token processing code - Decided against. Added Token processing to all fields for compatibility.
Make Token's context a Twig variable so it can be passed via drupal_token() if neededRemove token processing call where used in module
Update/Create Tests
Update existing tests to work with new fieldsCreate new tests to validate new functionality
- Update README.txt
- Update for the new features
- Provide examples
- Clean up code
- Remove commented debugging/obsolete code
- Conform to Coding Standards
| Comment | File | Size | Author |
|---|---|---|---|
| #44 | cmn-twig-2959026-44.patch | 55.1 KB | khaled.zaidan |
| #37 | preview.png | 152.72 KB | letrollpoilu |
| #36 | cmn-twig-2959026-36.patch | 54.82 KB | hgupta28 |
| #35 | cmn-twig-2959026-35.patch | 54.98 KB | hgupta28 |
| #32 | cmn-twig-2959026-32.patch | 59.14 KB | el1_1el |
Comments
Comment #2
diamondseaScreenshot of updated Notification Listing Page
Added additional column for debugging and showing the various fields/templates used for each notification

Screenshot of updated Notification Edit Page
Added new fields and updated help text for previous fields (roles, author) to describe how they will interact with the new fields. Fields will automatically expand to show all text within them (at least according to the number of newlines, could be off if lines are longer than the field width).

Screenshot of updated Notification Edit Page with expanded Help section
Shows the expanded "Common Replacement Patterns" fieldset with the most-used codes provided.

Screenshot of Notification Debugging output and Dynamic Message
The first line "admin has been notified of this edit" is custom drupal_set_message() output defined in the twig template. Any template can output messages to the user to appear on the screen, including identifying them as "warning" or "error" if desired.
The Twig Tweak module is needed for the drupal_set_message() and drupal_token() functions, if needed.
Below the message is the notification's debugging output, showing all the templates and resulting output for each field, as well as diagnostic information if a message would not be sent for any reason.
The final message is the standard message Drupal provides when a node is updated.

Comment #3
diamondseaComment #4
diamondseaInitial monster patch updating everything
Comment #5
diamondseaNote: the above patch should install properly and be fully functional despite any test failures.
See the "Things to Do" section at the bottom of the Issue Summary for details.
Comment #6
2phaThese additions are great.
Thanks a lot.
I did have a bit of a problem though.
I am wanting to send html emails.
I removed the line:
$email_message = PlainTextOutput::renderFromHtml($email_message);And I also had to set the content-type header:
$data['params']['headers']['Content-Type'] = 'text/html; charset=UTF-8';Comment #7
diamondsea@2pha The updated patch should work better. You'll probably want to use the https://www.drupal.org/project/swiftmailer module with https://www.drupal.org/project/mailsystem for HTML emails and not put the headers in this module. The next patch should work better with it as well.
Comment #8
diamondseaUpdated patch adding Token support for all fields, improved test coverage.
Needs install script to update existing schemas/configs.
Uninstall/Reinstall until then to get it to work on a system with existing CMN module.
Comment #9
diamondseaComment #10
dhumed commentedThank you for your great work on this @diamondsea ! This should definitely be part of the CMN module. I am using SMTP for the email functionality. Emails are sent out successfully after I edit content. After I edit content however, I get this error:
Notice: Undefined variable: content_type in Drupal\smtp\Plugin\Mail\SMTPMailSystem->mail() (line 294 of modules/contrib/smtp/src/Plugin/Mail/SMTPMailSystem.php).After digging into that part of the SMTP module's code, it seems that the error is related to headers.
Adding
$data['params']['headers']['Content-Type'] = 'text/plain; charset=UTF-8';to the Notification.php file solved that issue.Comment #11
diamondseaI'm not sure about the effects of adding the Content-Type header - wouldn't adding that break mail for people using MIME emails?
Comment #12
2phaAdding a text/plain content-type header will break it for mime mail users, notice I had to hard code it to text/html as I am using mime mails.
It somehow needs to be dynamic or selectable.
Comment #13
diamondseaI would think that this header should be added by one of the mail-handling modules depending on what is being sent, not by this module.
Anybody have more insight into this than I do?
Comment #14
khaled.zaidan commentedJust one thing with replacing the headers in content_moderation_notifications_mail(), as this seems to replacing a bunch of headers set in core that we'd like to keep.
Can instead do this:
CODE
so we're only adding/replacing the ones in our $params['headers'], without affecting any extra headers in $message['headers'] that we're unaware of.
Patch attached.
Comment #15
diamondseaCan you add an interdiff for your patch so we can see what you changed?
Comment #16
dhumed commentedHere is my patch describing what I added in comment #10
Comment #17
Anonymous (not verified) commentedre-roll patch #14 to work with latest dev version.
Comment #18
jhedstromComment #19
jhedstromI wonder if we could split the Twig support out into a separate issue? This patch is attempting to change quite a bit all at once.
Comment #21
diamondseaThe Twig support part of it is actually pretty trivial (and the conditional logic it allows critical for my use-case).
I think the test is failing because I'm not modifying the schema in the upgrade process (but works great if you enable the already-patched version), but I haven't had a chance to fix it yet (I got moved to a new project).
Comment #22
netsliverIn Content Moderation Notifications, which token is efficient for the contributor to be notified ? (we do not want to notify the original author but the person who edited and modified the content after) we tested with those token : {{ user.email }}, [latest_revision_author:mail], [latest_revision_author:email], {{ revision-user:mail }}, [current-user:mail]
(even though after installing the patch https://www.drupal.org/project/content_moderation_notifications/issues/2...), but no one work. An idea ?
Comment #23
diamondseaFrom https://drupal.stackexchange.com/a/258937:
If you need the user who created the revision, you need to use $node->getRevisionUser(), or $node->getRevisionUserId() for the user ID.
I'm not sure offhand if you can get that directly from the Twig node object or if you'd need to create a twig function to return it.
Comment #24
diamondseaComment #25
anruetherI just want to mention that this patch blocks other patches like 3015276. I guess it's because it changes so much code of the original module...
Comment #26
anruetherWith #17 installed I get this error on every attempt to create node or block. The creation fails with a WSOD. It goes away after removing the patch.
Comment #27
el1_1el commentedseems to be working for me. Thanks all!
Comment #28
mattsqd commentedI updated patch 17 to:
Comment #29
mattsqd commentedUpdated #28 so that the body of the email created was still an array.
Comment #30
avpadernoComment #31
el1_1el commentedpatch in 17 and 29 no longer applied to latest version. rerolling
Comment #32
el1_1el commentedreroll for 3.2 only
this patch does not apply to dev
Comment #33
caspervoogt commentedI couldn't get any of the patches from 2019 to apply, and didn't try any of the 2018 ones. I'm running 3.x-dev on Drupal 8.8.1.
Comment #34
Adamation commentedAny update on re-rolling this patch? Patch 32 failed for me too.
Comment #35
hgupta28 commentedUpdated the patch to work with Version 8.x-3.3.
Comment #36
hgupta28 commentedUpdated the patch to work with Version 8.x-3.3. Resolved multiple notifications not being generated.
Comment #37
letrollpoilu commentedI could apply #36 with the 3.3 version. I cleared the caches, ran cron and did the db updates.
I still don't have all the fields, this is pretty strange. Here is what I have:
Comment #38
avpaderno@hgupta28 The patch needs to be provided for the 8.x-3.x branch (the one used for the 8.x-3.x-dev development snapshot). When fixing bugs or implementing code for a feature request, it's the branch code that is changed.
Comment #39
anruetherNot sure if this patch will ever be committed. @jhedstrom suggested in #19 (3 yrs ago) to split off the twig functionality.
Comment #40
rob holmes commented@anruether the scope of this issue is too wide to really be able to be properly reviewed, tested and committed as a whole. It would have to be split out into much smaller patches each focusing on specific elements to be dealt with in isolation to get to the point where it can be added to a release etc.
Once aspects are completed separately they can be removed from this patch until this patch is no longer necessary.
Comment #41
avpadernoI agree: A 54 KB patch is too wide to be properly handled.
I would split the issue and keep in this the code that is common to all the issues, if such code exists.
Comment #42
dwwAgreed with #19 and #39-#41. This patch is way too big and changing way too many things to be reviewed, tested and committed in one shot. We need to split this up into child issues of more manageable scope. As-is, this will never be committed. Tagging for rescope and summary update.
https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... for the interested reader. 😉 While that's specific to core, the principles are generally applicable.
Thanks,
-Derek
Comment #43
dwwFor starters, I re-opened #2953489-13: Add Twig support in Subject, Email, and Message fields and posted a patch there (with tests) for Twig support in body, subject and to (adhoc 'emails') fields. Reviews most welcome!
Thanks,
-Derek
p.s. Turning this issue into an active 'plan', and put #2953489 as a child. This summary/issue still needs major help, so leaving it tagged for such.
Comment #44
khaled.zaidan commentedJust re-uploading the patch from #36 with deprecated code replaced (for D9-compatibility).
Comment #45
avpaderno@khaled.zaidan See the previous comments: Patches should not be provided for this issue, which is categorized as plan.
Comment #46
avpadernoComment #47
teknocat commentedAll of this stuff would be ideal - especially being able to use twig in the message body.
Comment #48
dwwRe #47: you already can. See #2953489: Add Twig support in Subject, Email, and Message fields
Comment #49
bkosborneSince Twig support was already added, the next step here would be to split out more of this work into additional separate issues to make them easier to review and merge in.
Note that there's another issue for adding support for more control of the To, Cc, Bcc, etc. headers: #3273627: Provide full to/cc/bcc email configuration. I haven't compared the implementation details of that issue with this one yet but I plan to.
The other functionality of this (abort support, debugging, tips, etc.) should all be split out into separate issues.