Provide content formatting settings and integrate token support

Configuration options look good, but I'm not seeing any emails making it through. Logged in DANSE ok, but nothing coming out of Push Framework as near as I can tell. But I don't see how to troubleshoot further for you I'm afraid. I've enabled the Email options under Push Framework but nothing is coming across. No log entries either?

Ok, emails are working again.

I very much like the token support for setting the subject of the email by adding the [push-object:label] into the other text that I want there. Perfect.

For the body of the emails, I'm struggling a little. I see that it is technically doing what is expected - embedding the content using the display chosen. And I can see that I can add in my own header or footer for example and that gets passed along when I also include [push-object:content]. So good job so far.

What is tripping me up though is that when this is sent in an email, the content of this is actually displayed as HTML code. Like it has been put through a Plain Text -> HTML conversion twice. Or something like that. Probably because it has. I'm using Mail System and Swift Mailer to do that part of it. Swift Mailer I think is the piece that does the conversion and in-lines all the CSS which seems to work great in other cases. So I have to try and see if changing text formats or something will allow the conversion to happen properly? If I don't do any conversion, it doesn't pass any tags through so no theming really possible.

I'll post again if I get it sorted, but if you can suggest how you envisioned the body field working in the config, that might help as well.

Alright. Apologies in advance as I don't always get the terminology correct (not a Drupal developer, remember!) so maybe this is more confusing than it needs to be.

I guess the issue is that whatever I put into the body field gets sent out to the mail system as a plain text "content type"? If there are links embedded, they get converted to text and ultimately are converted to links when the email is generated. But if it is a link to something, like for a tag, for example, only the tag comes out and the link is removed? That's what I'm seeing, anyway.

So what I think might be missing is that the output from your module on its way to the mail system needs to have an option of setting the content type to "text/html" or whatever the proper convention is, so that (1) this plaintext conversion doesn't happen here, and (2) the plaintext conversion doesn't happen there either. I tried tinkering at the other end, but it is already plain text by the time the mail system gets it, near as I can tell?

I've tried a bunch of different things, including using Layout Builder and so on (which is preferred I think - if you're testing it yourself...) to get the formatting right, but the output is just not containing all the detail needed in the first place.

I'm nowhere near competent enough to write a test for this sort of thing, but if I had a content item that had a title, a URL field, a body and a bunch of tags, I'd like to think that the title would come across with the full link to the content item, the URL would come across as a link with the associated description if present, the body would come across with any images/content/links etc. in the same format that the body itself is stored in (IE, html), and the tags would come across with the links as well. And Layout Builder could be used to arrange these as needed. Likewise, that is all that should be there... The "submitted by" piece that appears at the top shouldn't be included or if it is there (I've long forgotten whether it is always there?), it should be tagged so that the CSS can deal with it appropriately.

Hope this helps, I think this is the last little nugget from me!

Sounds good. Looking forward to giving it a try. Does not seem to work in the version updates today, but I could be missing out on something, so looking forward to those details next week. Presumably related to either the Text Format or an option you can specify.

As for the content itself, that sounds good as well. I think it was already doing that, but losing it all in the plain text conversion. I've got a Layout Builder format ready to go as soon as the content header update is in place.

Thanks so much!

Well this is proving difficult to sort out. The short version is that Swift Mailer still escapes everything, so the HTML is visible rather than the properly rendered content. It isn't clear to me why this is the case when I see other modules that don't seem to have this problem.

To begin with, the good. Your module does indeed put out a pretty good HTML page with your UI providing the means to add extra content to the output. Not really an issue there, but perhaps there's a question of when that HTML page is rendered.

Swift Mailer does a little work to convert incoming emails to inline CSS, adjust to use URLs and likely other things.

But naturally you don't want to have to do that in your module, nor do you particularly want to do anything specific for Swift Mailer. So I'm at a bit of a loss of how to deal with this. I muddled through trying to understand how this all works, and Swift Mailer is by no means problem-free in this kind of thing. What I don't get, and where my lack of Drupal talent is likely an issue, is how your module doesn't work as expected, but another doing a similar thing seems to work better?

The Digest module sends out a block. So rather than having a UI like you do to configure the email content with replacement tokens, they just have a UI where you select a block that you can then populate as you like. In any event, when they send an email from this block, their code does this (I've trimmed out the uninteresting bits):

  public function send(UserInterface $user) {

    $block = $this->getDisplayBlock();
    $block_build = $block->build();

    $this->mailManager->mail(
        'digest',
        $this->id(),
        $user->getEmail(),
        $user->getPreferredLangcode(),
        [
          'subject' => $this->getTitle(),
          'body' => $this->renderer->renderPlain($block_build),
        ]
      );
  }

No magic here as near as I can tell. So they didn't do anything Swift Mailer-specific nor did they even bother with content types or text formats.

(As a side note, using the Block I can add headers and footers, with the content specified in the view. Different than what you're doing as there'd have to be a way to get the entity id being pushed into the view in some way to be able to incorporate it into the block, for example? Likewise when creating a Block without a view, not sure how that push notification information is included. So the display route you've taken certainly has some advantages here).

I'm guessing that their block > build > renderer > renderPlain sequence is outputting something different than what you're doing but I'm at a loss as to what that may be as I see a similar chain of calls in your code, just using a display/view rather than a block?

Yes, a quick check seems to indicate that this fixes the problem!

HTML now comes through, full paths are visible, and tags added through the display/Layout Builder appear in the output and thus can be themed.

You're welcome. Happy to help.