I'm using Simplenews + cck + Nodereference + Mimemail for sending newsletters in plain text (Mimemail because a custom module uses it to attach files to other mails).
Everything works fine except the transformation "html mail" -> "plain mail".

Given:
<h2>Band name</h2>

Result:

-------- Band name  
-----------------------------------------------------------

As you can see there is a linebreak in the headline. I figured out that the core helper function _drupal_html_to_text_pad() adds one '-' too much. After changing line

$n = max(0, 79 - (strlen($text) - $p) - strlen($prefix));

to

$n = max(0, 78 - (strlen($text) - $p) - strlen($prefix));

everything works fine.

Are there other people out there with this problem? If not - do you have any ideas what's going wrong?

A little debug information:

$n = max(0, 79 - (strlen($text) - $p) - strlen($prefix));
  dpm(strlen($text)); // 783
  dpm($p); // 766
  dpm(strlen($prefix)); // 1
  dpm($n); // 61

PHP Version: 5.2.6-1+lenny9

When creating a new account, the welcome email is not sent to the user. An error is given that the reply-to was not set.

The expected behavior is that the welcome email is successfully sent with a proper reply-to header.

From the New User's POV:
- create a new account.
- On success I receive an error:

Unable to send e-mail. Contact the site administrator if the problem persists.

- Confirmed. The email is not received by the newly registered user.

As an administrator the error in the log is:

Error sending e-mail (from user1@example.com to user2@example.com with reply-to not set).

Severity Error

I confirmed a proper administrator email is set at:
http://drupal8.dev/admin/config/system/site-information

Environment Details:
Up-to-date d8.dev version running on http://drupal.org/project/vdd

Problem/Motivation

The drupal_html_to_text function removes images throwing away the alternate text. This is arguably bad from an accessibility perspective. Images could contain semantically meaningful information which is expressed in the alt attributes. In addition, I did a quick comparison and mailchimp appears to add alt attributes from images to their plain text versions by default. It is a little different with them as their plain text is editable. However, if the industry leader is doing it by default, it's probably a good idea.

I suggest replacing images with alt text when alt text exists. Below is one proposed solution (patch coming d7/d8).

include/mail.inc (d7)

401: $supported_tags = array('a', 'em', 'i', 'strong', 'b', 'br', 'p', 'blockquote', 'ul', 'ol', 'li', 'dl', 'dt', 'dd', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'hr', 'img');
...
414:  // Replace images with alternate text
415:  $string = preg_replace('@<img[^>]+?alt="([^"]*)"[^>]*?>@i', '$1', $string);

Note, there is a related 250 commenter, but it seems to be inactive (2011) and didn't appear to mention image/alt handling.
See #299138: Improve \Drupal\Core\Utility\Mail::htmlToText()

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

D7 and D8 currently invoke hook_mail_alter() before calling MailInterface::format(). From drupal_mail():

  // Invoke hook_mail_alter() to allow all modules to alter the resulting e-mail.
  drupal_alter('mail', $message);

  // Retrieve the responsible implementation for this message.
  $system = drupal_mail_system($module, $key);

  // Format the message body.
  $message = $system->format($message);

MailInterface::format() is at the least responsible for taking $message['body'], which is an array at this point, and imploding it into a string. See PhpMail::format().

This means that hook_mail_alter() implementations can't be sure of what the "final" state of the message body will be. Spam has been on my mind recently, and I ran into this problem when probing if it would be possible to use hook_mail_alter() to add DKIM headers to a message. Since this requires hashing the message body, and we can't be sure of what the message body is when this hook is invoked, it is not possible. If we can assume that MailInterface::mail() won't alter the message body, then moving the hook invocation after the ::format() call would make adding DKIM headers and similar things possible in hook_mail_alter() implementations.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Unicode::mimeHeaderEncode() is used to make sure that strings used with MIME headers are within 7-bit ASCII, by encoding strings according to the MIME standards (RFC 2047). The method folds (wraps) long lines to adhere to the MIME-recommended 78 char line length limit. But it does not account for the field name that normally precedes the string name, so the length limit is easily exceeded anyway.

E.g. PhpMail:

foreach ($message['headers'] as $name => $value) {
  $mimeheaders[] = $name . ': ' . Unicode::mimeHeaderEncode($value);
}

For $message['headers']['Subject'] = 'Alle Menschen sind frei und gleich an Würde und Rechten geboren.'; this gives:

Subject: =?UTF-8?B?QWxsZSBNZW5zY2hlbiBzaW5kIGZyZWkgdW5kIGdsZWljaCBhbiBXw7xyZGUgdW4=?=
 =?UTF-8?B?ZCBSZWNodGVuIGdlYm9yZW4u?=

where the first line is 86 characters long.

Proposed resolution

Add a $field_name_length = 0 argument to Unicode::mimeHeaderEncode(), and subtract that number from $chunk_size for the first line. (Subsequent lines do not include the field name.)

Remaining tasks

User interface changes

API changes

Problem/Motivation

We always assume that mail sends successfully, so when it fails, we give the user confusing messages.

drupal_mail() returns the $message with the send results in $message['result'], we should check this before displaying any message that says something like "Your mail has been sent". The assumption is that the underlying mail system displays it's own error message on failure. So, on failure, the underlying mail system might say "Your message has NOT been sent", and then Drupal comes over that and says "Your message has been sent." ... bad, confusing.

Would be nice to get some fix in quickly ... and then have further discussion about what is the right way of handling these failures.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Sister issue to #1047814: Create a centralized e-mail template configuration interface

It is actually insanely hard to "unsubscribe" from a typical Drupal site, because every module can send e-mail, and needs to provide its own interface for opting in/out of e-mail notifications (and some, like User module, don't).

hook_mail() knows about all the mails that are registered with the system, at least in theory. So it seems like it would be possible to create a single interface that let people selectively subscribe/unsubscribe to certain system mails.

For this interface to not be ungodly awful (14,000 checkboxes to things like "User ban notification", "User approval notification", etc.) we probably need some mechanism to group mail keys together under a single checkbox, and possibly also put them in "packages" of sorts.

Problem/Motivation

The MailManager is accessing the $message array after the mail was sent in case there was error during sending to create log entry:

// Format the message body.
    $message = $system->format($message);

    // Optionally send email.
    if ($send) {
      // The original caller requested sending. Sending was canceled by one or
      // more hook_mail_alter() implementations. We set 'result' to NULL,
      // because FALSE indicates an error in sending.
      if (empty($message['send'])) {
        $message['result'] = NULL;
      }
      // Sending was originally requested and was not canceled.
      else {
        // Ensure that subject is plain text. By default translated and
        // formatted strings are prepared for the HTML context and email
        // subjects are plain strings.
        if ($message['subject']) {
          $message['subject'] = PlainTextOutput::renderFromHtml($message['subject']);
        }
        $message['result'] = $system->mail($message);
        // Log errors.
        if (!$message['result']) {
          $this->loggerFactory->get('mail')
            ->error('Error sending email (from %from to %to with reply-to %reply).', array(
            '%from' => $message['from'],
            '%to' => $message['to'],
            '%reply' => $message['reply-to'] ? $message['reply-to'] : $this->t('not set'),
          ));
          drupal_set_message($this->t('Unable to send email. Contact the site administrator if the problem persists.'), 'error');
        }
      }
    }

    return $message;

I have AmazonSES mail plugin and the AWS API require various formats that are not aligned with what the basic PhpMail plugin does. Especially, some values have to by changed into arrays.

When this happens the watchdog entry will be missing information since MailManager expects form, to and reply-to to be all strings which may not be the case. It also parses the subject string on its own for some reason.

This is simply wrong since the MailManager is calling the format() method on the plugin ad therefore it has no place in working with that message array anymore.

If there should be watchdog message logged it should be done with values that are present in the original message array before it was formatted by the active mail plugin. It should also not touch the subject line at all.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The static method MailFormatHelper::htmlToMailUrls uses global variables $base_url and $base_path. This prevents the method from being unit tested.

Proposed resolution

See #7

Remaining tasks

Problem/Motivation

Plain text email constructed with mail.inc will trigger several SpamAssassin mixed case URI tests. Any MTA that has those filters enabled will flag mail from Drupal as spam (if they are all enabled, it can add up to a very, very high spam score); some of those tests are HTTP_MIXC BODY, URI_TLD_MIXC URI, and URI_PROTO_MIXC URI.

These tests are not enabled by default, and it is possibly a questionable decision to have them enabled, at all, but some relatively large mail servers do (I get bounces every few days due to it, when I forget the patch my mail.inc after a Drupal update; we send out a few thousand notification emails a day).

The offending lines are:

// Fancy headers
        case 'h1':
          $indent[] = '======== ';
          $casing = 'drupal_strtoupper';
          break;
        case 'h2':
          $indent[] = '-------- ';
          $casing = 'drupal_strtoupper';
          break;

Simply removing the "$casing = 'drupal_strtoupper';" lines resolves this problem. It also makes plain text email slightly less ugly (all caps is obnoxious, regardless of its problems triggering spam filters).

Note that this also overrides templates and such, without any configurable options to avoid it, which seems unfriendly.

The problem has been present for most of forever. It is in both our 6.x production site and 7.x development site.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Blocked behind #3053887: Add test coverage and document why inline blocks require a new revision to be created when modified, regardless of whether a new revision of the parent has been created

Problem/Motivation

When reverting a parent entity revision, the parent/child relationship looks like:

 +------------+   +------------+   +------------+
 |Host Entity |   |Host Entity |   |Revert VID 1|
 |VID: 1      |   |VID: 2      |   |VID: 3      |
 |Timestamp: 1|   |Timestamp: 2|   |Timestamp: 3|
 +------------+   +------------+   +------------+
       |                |                |
       v                v                |
 +------------+   +------------+         |
 |Block Entity|   |Block Entity|         |
 |VID: 1      |   |VID: 2      |         |
 |Timestamp: 1|   |Timestamp: 2|         |
 +------------+   +------------+         |
       ^                                 |
       +---------------------------------+

 Custom block entity form
 +-----------------------------+
 |$saved_entity change time: 2 |
 |$new_entity change time: 1   |
 |Validator throws error       |
 +-----------------------------+

When block entity VID 1 is loaded into the custom block form, the validator compares it against VID 2 as the "saved entity". The validator sees that a new revision has been created since VID 1 and throws an error.

Node handles this by updating the changed timestamp in \Drupal\node\Form\NodeRevisionRevertForm::submitForm when a node is reverted, but there isn't currently a process to create new entity revisions of custom blocks when a host entity is reverted.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Mail%21Pl...

Form submission was taking too much time on our server (about 30 sec)
and after lots of debugging. it turned out that the code of mail function in TestMailCollector.php was causing this slowness
we have a very long list of emails on our website
so loading the emails list and adding an item to it and storing the new value back was time-consuming
I commented this code and the form submission became fast on our server

I think there should be an option somewhere to turn this operation on or off
with adding a note that this operation could take time if the list of emails gets very long

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Suggested commit message (feel free to change / doublecheck contributors, I scanned manually):

#84883 by earnie, ximo, netbjarne, scor, greggles, pillarsdotnet, DuaelFr, roderik: make Unicode::mimeHeaderEncode() conform to RFC 2047.

Problem

1)
Drupal\Component\Utility\Unicode::mimeHeaderEncode() ( mime_header_encode() in Drupal < 8) does not conform to RFC 2047 standards, particularly to one bit in section 2:

An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.

This non-conformance was apparently introduced on purpose, given the current comments on the method/function (introduced july 2005, commit #11a4aba by Steven):

 * Using \n as the chunk separator may cause problems on some systems and
 * may have to be changed to \r\n or \r.

...so people with problems would have to hack their own solution in case or problems. Which was apparently because of (issues related to) restrictions in PHP's mail() function:

$subject - Subject of the email to be sent.
Caution: This must not contain any newline characters, or the mail may not be sent properly.

This restriction on mail() has by now been removed (as reported around november 2009), however - so we should be able to just conform to RFC 2047.

2)

The 'chunk size' of 47 is not correct, resulting in errors because of the length of encoded lines being longer than 75 characters.

Issue history

The combination of 2 bugs probably contributed to confusion around pinpointing the exact cause(s).

Until #95, people were trying to remove any newlines from the (encoded) subject header, to solve reported problems. (Which does not conform to the RFC). Plus figuring out where they came from.

The separator and chunk size were first introduced in #105, after which there were relatively few diversions.

Proposed resolution

The patch does two things, besides adding a test / changing comments:

• Change the separator for encoded chunks to CRLF SPACE, as per the RFC
• Decrease the chunk size to 45

Remaining tasks

review latest patch.

User interface changes

none

API changes

none

Data model changes

none

Beta phase evaluation

Problem/Motivation

See the test fails in https://qa.drupal.org/pifr/test/937688:

Mail has correct subject Value '[Default newsletter] &s8\\' is equal to value '[Default newsletter] <:i~(>&s8\\'.

In #2572597: Replace !placeholder with @placeholder in mail code, we added a PlainTextOutput::renderFromHtml($message['subject']) but I think that is wrong.

Both plain and mime/uft-8 encoded mail subject are displayed as expected with < > in gmail.

Proposed resolution

Provide a version of renderFromHtml that does not strip tags?

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

While reading documentation on the Mail system, I came across the plugin PHPMail.
I would like you attention on the mail method.

Why is the function mail() silence with @?

$mail_result = @mail($message['to'], $mail_subject, $mail_body, $mail_headers, $additional_headers);

and

$mail_result = @mail($message['to'], $mail_subject, $mail_body, $mail_headers);

Proposed resolution

If they no particular reason to silence the function, we should say good bye to "@"

Problem/Motivation

Required fields are not identifiable on Internet Explorer 11 because the required marker is not visible. This field is supposed to have the required marker:

This is how this field looks like in Edge:

Proposed resolution

Ensure that required fields are identifiable on Internet Explorer 11 high contrast.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

so, I just updated to 8.7.8, and the fixed 3021452 issue is persisting for me. I see a title is provided for my example youtube video.

VIDEO: https://www.youtube.com/watch?v=6X8f9CLBoB8

EMBED JSON URL: https://www.youtube.com/oembed?format=json&url=https%3A%2F%2Fwww.youtube...

EMBED JSON:

{
    "provider_url": "https://www.youtube.com/",
    "author_name": "The Four on KTVU",
    "height": 270,
    "thumbnail_height": 360,
    "provider_name": "YouTube",
    "author_url": "https://www.youtube.com/channel/UCHTnUyoYpA4txfWEVoY1Ysg",
    "width": 480,
    "version": "1.0",
    "html": "<iframe width=\"480\" height=\"270\" src=\"https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen></iframe>",
    "thumbnail_width": 480,
    "thumbnail_url": "https://i.ytimg.com/vi/6X8f9CLBoB8/hqdefault.jpg",
    "type": "video",
    "title": "New Sensor Network Reveals Telltale Patterns in Neighborhood Air Quality"
}

GENERATED IFRAME IN RENDERED DRUPAL 8.7.8 PAGE:

<div class="embed-media embed-media--video-youtube">
<iframe src="https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed" allowfullscreen="allowfullscreen" width=" 480" height="270" frameborder="0"></iframe>
</div>

I've even tried deleting the iframe and re-creating it. No luck. The title just doesn't get appended to an attribute in the <iframe> tag.

My CKEditor Media Embed module is configured to use Provider Url: //noembed.com/embed?url={url}&callback={callback}, which does show an iframe without a title, but does include the title data in the json:

GENERATED IFRAME URL: https://noembed.com/embed?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%...

EMBED JSON:

{
    "html": "\n<iframe width=\" 480\" height=\"270\" src=\"https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"></iframe>\n",
    "version": "1.0",
    "height": 270,
    "thumbnail_url": "https://i.ytimg.com/vi/6X8f9CLBoB8/hqdefault.jpg",
    "thumbnail_width": 480,
    "title": "New Sensor Network Reveals Telltale Patterns in Neighborhood Air Quality",
    "author_name": "The Four on KTVU",
    "url": "https://www.youtube.com/watch?v=6X8f9CLBoB8",
    "width": 480,
    "provider_name": "YouTube",
    "thumbnail_height": 360,
    "provider_url": "https://www.youtube.com/",
    "type": "video",
    "author_url": "https://www.youtube.com/channel/UCHTnUyoYpA4txfWEVoY1Ysg"
}

If I am missing something about how the 13282573 fix is supposed to work, can someone please walk me through it?

P.S. My Basic HTML editor has the title attribute enabled for iframes, so I doubt its being filtered out (and wouldn't expect it to be anyways):

P.S.S. For what it is worth, I have also tested using iframe.ly as the source and also am not getting a title in that case.

<iframe src align frameborder height width scrolling type title bgcolor allowtransparency>

The new design looks great, but why change the arrow orientation for closed-state?
As seen in the evolvingweb blog:

The new arrows seem to try follow the logic of the arrows for accordions in the content area. But as is standard in menus, being placed right vs. left.

This takes some meaning out of the right-pointing closed-state arrow i think, because it points away from the box, giving some "forward", or "go somewhere" notion, as it is present in the Navigation-PAGES:

Sometimes menu designs use up-down arrows, sometimes down-up arrows, so there's quite some inconsistency, non-standardness on how to use arrows.
Why did you dismiss the logic from before?
Did you also considerk the + - (or + x)scheme? Seems this has less ambiguity and more logic to it (increase/decrease no. of menu items).

\Drupal\Core\Mail\MailManager::doMail should be protected since it does not implement any interface, and its main entry point is supposed to be \Drupal\Core\Mail\MailManager::mail.

Method introduced in #2663270: MailManager::mail() should run inside its own render context: it sends e-mails, not (cacheable) responses

Problem/Motivation

Spun off from this request for Drupal 7 (token module): #823780: Add site logo token, where a token for the logo and logo-url have been proposed. However, since all site:* tokens are in core, I feel this belongs to core as well. Therefore I am proposing it here for Drupal 8.

Proposed resolution

The new tokens are [site:logo] and [site:logo-url] and they provide a rendered image and a local path respectively. In addition to that, both tokens also take a theme parameter ([site:logo:?], [site:logo-url:?]) to fetch a logo for a specific theme.

Steps to reproduce:
- without applying patch, install and enable 'token' module (so you can easily browse the list of available tokens)
- edit Article content type, go to manage fields, edit Body
- click "Browse available tokens" link underneath Help text, to open Available tokens popup
- verify no site logo tokens in the Site information list

- now apply patch
- drush cr
- reload Available tokens popup, verify [site:logo] and [site:logo-url] added
- insert them into help text and create or edit an article to verify the Drupal logo and standard URL (/core/themes/bartik/logo.svg) are now visible
- configure a different logo for another theme (seven)
- insert [site:logo:seven] and [site:logo-url:seven] to have the logo show up.
- [site:logo:non-existing-theme] should not be replaced

Remaining tasks

Review.
Resolve #2855653: FilterHtmlImageSecure filters out valid local svg images so the default logo's work as well (user uploaded png/jpg files already work).

User interface changes

None.

API changes

None.

Data model changes

None.