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

Use Symfony's mime classes to do the encoding.. See #195

Remaining tasks

Review
Commit

stackoverflow.com/help/someone-answers

User interface changes

none

API changes

none

Data model changes

none

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Bug because sending mail breaks (in easily reproducible situations)
Issue priority Major because same
Unfrozen changes No.
Prioritized changes Improves stability; fixes clear bug; backport to D7/D6
Disruption No
CommentFileSizeAuthor
#216 84883-216.patch13.06 KBalexpott
#209 84883-209.patch14.12 KBquietone
#209 interdiff-205-209.txt1.17 KBquietone
#205 84883-205.patch14.14 KBalexpott
#205 203-205-interdiff.txt766 bytesalexpott
#203 84883-203.patch14.07 KBalexpott
#203 202-203-interdiff.txt1.17 KBalexpott
#202 84883-202.patch13.96 KBquietone
#202 interdiff-196-202.txt907 bytesquietone
#196 84883-196.patch13.6 KBalexpott
#196 195-196-interdiff.txt1.97 KBalexpott
#195 84883-195.patch13.94 KBalexpott
#182 84883-182.patch7.64 KBquietone
#182 interdiff-181-182.txt1.45 KBquietone
#181 84883-181.patch7.58 KBquietone
#181 interdiff-178-181.txt1.54 KBquietone
#178 84883-178.patch7.54 KBayushmishra206
#178 interdiff_176-178.txt2.01 KBayushmishra206
#176 interdiff-175-176.txt1.19 KBTR
#176 84883-176-mime-header-encode.patch7.94 KBTR
#175 interdiff-166-175.txt6.65 KBTR
#175 84883-175-mime-header-encode.patch7.94 KBTR
#166 84883-166.patch3.93 KBHardik_Patel_12
#160 interdiff-84883-152-160.txt1.02 KBroderik
#160 drupal-8.0.x-mime_header_encode-84883-160.patch3.79 KBroderik
#156 drupal-8.0.x-mime_header_encode-84883-152.patch3.92 KBDuaelFr
#152 interdiff.84883.144.152.txt1.83 KBDuaelFr
#152 drupal-8.0.x-mime_header_encode-84883-152.patch3.92 KBDuaelFr
#144 interdiff-84883-140-144.txt2.18 KBroderik
#144 drupal-8.0.x-mime_header_encode-84883-144.patch4.01 KBroderik
#140 interdiff.84883.138-140.txt3.75 KBroderik
#140 drupal-8.0.x-mime_header_encode-84883-140.patch3.45 KBroderik
#138 interdiff.84883.136-138.txt1.75 KBDuaelFr
#138 drupal-8.0.x-mime_header_encode-84883-138.patch2.5 KBDuaelFr
#136 drupal-8.0.x-mime_header_encode-84883-136.patch2.5 KBDuaelFr
#136 drupal-8.0.x-mime_header_encode-tests_only-84883-136.patch1.06 KBDuaelFr
#126 84883-126.patch856 bytesAnonymous (not verified)
#106 mime_header_encode-84883-106-D7.patch1.13 KBAnonymous (not verified)
#106 mime_header_encode-84883-106-D6.patch1.12 KBAnonymous (not verified)
#105 mime_header_encode-84883-105.patch836 bytesAnonymous (not verified)
#95 remove_linefeeds_from_subject-84883-95-D6.patch966 bytespillarsdotnet
#95 remove_linefeeds_from_subject-84883-95.patch1.11 KBpillarsdotnet
#87 84883_subject_newline_d7_4.patch797 bytesscor
#85 84883_subject_newline_d7_3.patch709 bytesscor
#77 84883_subject_newline_d7_2.patch860 bytesscor
#60 84883_subject_newline_d7_1.patch865 bytesscor
#50 84883_subject_newline_2.patch848 bytesscor
#49 84883_subject_newline.patch1017 bytesgreggles
#27 unicode.inc-chunkseparator.patch411 bytesximo
#15 mail-error-screenshot.JPG73.52 KBnetbjarne
#9 workaround.JPG127.47 KBnetbjarne
#8 phpinfo.htm.txt45.7 KBnetbjarne
#7 shot-2-error.JPG116.69 KBnetbjarne
#6 shot-1-succes.JPG99.68 KBnetbjarne

Issue fork drupal-84883

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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drewish’s picture

What version of PHP are you using?

huss’s picture

Title: warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module on » PHP Version 4.3.11

PHP Version 4.3.11

huss’s picture

Title: PHP Version 4.3.11 » warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module on

Sory! In the previous message I changed the title of the issue and couldn't restore it. But now the issue has the same title.

netbjarne’s picture

Oh man - just spend 6 hours on a day off to narrow this down.

I can confirm that there indeed is a bug somewhere.

Symptom:
If sitename in /admin/settings contains national characters, in my case "æ", mailing of login info etc from the user module fails with this error:

mail(): Bad parameters to mail() function, mail not sent. i /hsphere/local/home/oldrup/kegnaes-friskole.dk/modules/user.module på linje 430.

User.module version info:

// $Id: user.module,v 1.612.2.16 2006/08/02 18:13:27 killes Exp $

PHP Version: 4.4.4

Workaround:
Avoid using national characters in sitename. If I replace "æ" with "ae" in my sitename, the user module can once again email.

I can reproduce this error on several installations. Any help is greatly appreciated.

netbjarne’s picture

A small side note, the contact module has not got the same problems with national characters - I have been sending several messages using the contact module, which included "æøå" and such in the subject line - all went through fine.

Please let me know if I can provide any useful info to help get this fixed. I'd really like my site to have the correct name ;-)

netbjarne’s picture

FileSize
99.68 KB

Screenshots and phpinfo attachments for more details

netbjarne’s picture

FileSize
116.69 KB

Here the second screenshot where mailing fails due to national characters in sitename.

netbjarne’s picture

FileSize
45.7 KB

Lastly, phpinfo dump.

netbjarne’s picture

FileSize
127.47 KB

More diagnostic results and a better workaround.

I found out that BOTH the user.module AND the contact.module, uses the user_mail function from the user.module to send emails. The contact.module succeeds, the user.module fails - sending emails the email subject includes national characters.

The subject line of emails sent by the user.module, can be modified in the administer >> settings >> users menu. If having a sitename with national characters, you can replace every instance of %site in the text fields, with plain ascii instead.. Please see screenshot.

greggles’s picture

Following on netbjarne's work...

In contact.module we have this subject:

383 : dries 1.65 $subject = '['. variable_get('site_name', 'drupal') .'] '. $form_values['subject'];

In user.module we have a subject that depends on the reason it is being sent, but they all looks similar to this:

1513 : unconed 1.655 return t('Account details for !username at !site', $variables);

Note that I'm pasting from annotate view so we know which line/commit is involved.

So, it seems to me that by using different methods of variable insertion into the email subject we are getting this different behavior of the mail succeeding in one case and failing in another.

In both cases we use drupal_mail to send the messages. Perhaps some cleanup of the subject would be appropriate in there, but I'm not sure what kind of cleanup is necessary.

scor’s picture

Title: warning: mail(): Bad parameters to mail() function, mail not sent » warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module on
Version: 5.x-dev » 4.7.3
Assigned: » Unassigned

Hi,
I have the same problem on a unix php 4.4.3 server. I recently migrated from php 4.4.1. which never caused this problem.
This problem occurs whenever the subject of the email sent by the server is longer than 46 characters and contains national characters. I also managed to get this message with contact module, when the subject of the email is long enough.
In the mime_header_encode function, when the subject of the email contains national characters, the subject is encoded in base64 by chunks of 47 characters. If there is only one chunk, there is no problem, the email is sent with the encoded subject. But if there are more than one chunk, a line break is put at the end of each chunk. I guess it's to comply with the RFC2047 :

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.

Now, this is what the php mail function says about the subject of the email :

subject

Subject of the email to be sent.

Caution

This must not contain any newline characters, or the mail
may not be sent properly.

and it doesn't mention anything about the encoded subjects.

When I look at the source of some emails sent from a config which works (unix php 4.3.11) with a long subject with national characters, the line breaks of the subject have been deleted (by the mail function I assum). All the base64 chunks of the subject end up on the same line with a SPACE between each of them, so I figured there was no point to have the line break in the mime_header_encode function and decided to remove it.
The line break is added in unicode.inc, line 232:

      $output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n";

I deleted the "\n" and it worked. The only thing is that the email sent doesn't comply with the rfc2047 since all the chunks of the subjects are on the same line, but it was already like that before on the working config. Try to send a message with contact module with a long subject like this :
Le sujet de ce message est très long!
even drupal.org puts all the chunks on the same line!

I'm not sure what triggers this problem (version of php, mb_string settings) but check your config and post more details about it!

killes@www.drop.org’s picture

Version: 4.7.3 » 5.x-dev

moving to HEAD since user_mail hasn't changed. But apparently PHP has(?).

greggles’s picture

Version: 5.x-dev » 4.7.x-dev

Steps attempted:
1. send a message on the sitewide contact with subject containing: på and æ.
2. set sitename to contain æ
3. send message on user personal contact form

Expected results:
Error messages

Actual results:
Mails went through, no errors printed to screen nor watchdog.

My tests were only on Drupal5.x head as of today, so I imagine this is Drupal4.7 related. If my means of testing were wrong or if someone else can confirm it in 5.x then please comment and change the version back to Drupal5.x.

killes@www.drop.org’s picture

Priority: Critical » Normal

I've tried to repro this on 4.7-x running on php 5.1 and couldn't reproduce it. Downgrading.

netbjarne’s picture

FileSize
73.52 KB

On my host, surftown, the problem still exists. Also in 5.0 beta 2 - see attached screenshot.

Needless to say, that if in the "request new password" text, replace !site (that contains national characters), with !uri (that only contains ascii), the problem goes away.. Same ol' I

Bjarne

greggles’s picture

Version: 4.7.x-dev » 5.x-dev

So, I'd say this is a combination of national characters in the subject AND a certain configuration of PHP. I agree with Killes on priority, but move it back to 5.x since it affects that and should get attention there.

@netbjarne - the problem only affects the per user contact page, right? And since you are one of the few who can test this, would you be willing to try out a patch if one is provided?

Steven’s picture

This is really a bug in PHP that should be addressed. Removing the linebreak means disobeying the RFC.

scor’s picture

I had the same problem that I solved with the solution above. I think this issue concerns only a few PHP configurations and is not related to the version of drupal. I'd say it's directly related to the mail function of PHP, and maybe to the national settings. The problem does not only appear in the contact page, but as I stated previously

This problem occurs whenever the subject of the email sent by the server is longer than 46 characters and contains national characters.

I first notice this problem with subscriptions.module which was not sending the emails to the users who had a username containing national characters... Try as an example to create an account with a long user name containing national characters. The subject of the resulting email has to be longer than 46 characters. This will force the subject of the email to be encoded and several chuncks will be generated... and the bug should appear... at least on the buggy PHP configurations.
Greggles, have you tried that? Does the encoded email subject in the email header contain any line break ?
I can also try a patch if provided.
Steven, I agree that the RFC is disobeyed, but shouldn't it be PHP that should add these linebreaks instead, since the PHP documentation requires no linebreak in the email subject ?

Steven’s picture

PHP should not be adding the linebreaks, unless PHP were to actually accept a random unicode string and do the encoding itself.

PHP requires us to do the encoding, and separating chunks on lines is an essential part of this.

scor’s picture

This is what the php mail function says about the subject of the email :

subject

Subject of the email to be sent.

Caution

This must not contain any newline characters, or the mail
may not be sent properly.

and it doesn't mention anything about the linebreaks in the case of an encoded subject.
Is there an exception for the encoded subjects ?

Moreover, when I send a message through drupal.org, the encoded subject chunks are all on the same line:

Subject: =?UTF-8?B?W2RydXBhbC5vcmddIHTDqXN0IHBvdXIgdm9pciBzaSBsZXMgc3VqZXQgcGxhbnQ=?=  =?UTF-8?B?ZW50IGNoZXogZHJ1cGFsLm8=?=
netbjarne’s picture

More info on this bug.

I wrote messages on the contact form. Some went through. Some didn't. I can confirm, that subject messages have to be of a certain lengt (46 has been mentioned, that looks about right) - AND that national characters must be present in the final subject of the email (for instance, if the sitename contains them).

Heres the subject of a message that passed through the user_mail function:
[Kegnæs Friskole] 0123456789012345678901234567

Add another "8" to the subject, and the mail fails.

I will try the hack of removing newline characters of in the subject, and return with additional info.

Bjarne

netbjarne’s picture

I found me another workaround (gotta make a list of drupal workarounds, it gets hard to remember to re-apply them all every time a new version is installed ;-))

in include.inc, the mime_header_encode function, i replaced

    $chunk_size = 47; // floor((75 - strlen("=?UTF-8?B??=")) * 0.75);

with

    $chunk_size = 400; // floor((75 - strlen("=?UTF-8?B??=")) * 0.75);

Its an overly big chunk size, since the mail form does not allow lengthy subjects, however, utf-8 encoding seems to lengthen things a low...

Now - mail passes through just fine - no linebreaks in the subject (who came up with that idea anyway) - and no lost messages.

Bjarne

netbjarne’s picture

Mistake in last post. The edited file was not include.inc, but unicode.inc. Sorry..

yasenp’s picture

I had the similar problem, but "$chunk_size = 400;" solved it. Many thanks to netbjarne!

ximo’s picture

What's the story on this bug? Has it been fixed in another issue, or is this bug still hanging around? This should be fixed for Drupal 6.

ximo’s picture

I just got this error without having any national characters in the subject line. I was creating a new user from admin/user/user/create, and the subject of the email message to be sent out was En konto har blitt opprettet for deg på !site where !site = Wannabe. I tried some of the mentioned workarounds, but found simply removing the \n</codefrom the end of <code>$output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n"; did the trick. Why is the newline there in the first place? It's looks like it's the newline that breaks the mail() function.

I'm not sure why I got this error when I had no national characters in the subject line or the site name. This was on Drupal 5.1, PHP 4.4.6, Apache/1.3.37 (Unix).

ximo’s picture

I'm obviously blind, I did have an å in the subject line!

I looked into the background of this issue, and found these links:
http://www.php-security.org/MOPB/MOPB-34-2007.html
http://bugs.php.net/bug.php?id=15841

Didn't make me any wiser though..

Then I saw this note in the mime_header_encode() function_

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

Changing \n to \r did the trick, Drupal could now send the mail with a subject containing å. I know this doesn't follow the RFC, but it works with the mail() function and I believe that's more important. Having to manually change this deep inside the core shouldn't be necessary, why can't the chunk separator be \r by default? See the attached patch.

Anonymous’s picture

Perhaps the following would take care of the issue? I don't have a good scenario to test with.

-      $output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n";
+      $output .= ' =?UTF-8?B?'. base64_encode($chunk) .utf8_encode("?=\n");
siammoney.net’s picture

Title: warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module on » warning: mail(): Bad parameters to mail() function, mail not sent
Version: 5.x-dev » 5.2
Assigned: Unassigned »
Priority: Normal » Critical

warning: mail(): Bad parameters to mail() function, mail not sent. in /home/content/p/u/r/purihostsiam/html/includes/common.inc on line 1979.

this message occurs when create a new account . somebody help me please!.

scor’s picture

siammoney.net: are you using accented characters in your username when creating your account?

siammoney.net’s picture

Component: user.module » aggregator.module

yes I have test create a new account for quest by use accented characters in username

scor’s picture

Version: 5.2 » 5.x-dev
Component: aggregator.module » user.module

aggregator???
can you check that you don't have the problem with non accented chars.

@ximo: whether you use \r, anything else or nothing at all, it's the same as long as it's not \n (see #11)

siammoney.net’s picture

thank you, but when I use a common chars such as puri007 that always show this errors.How 's about syntax in line 1976 on common.inc? I confuse in $mimeheaders and $subject.

siammoney.net’s picture

thank you for suggestion,I try new install drupal 5.2 that good work.I think it 's cloud be errors about theme or module that after install. so happy

scor’s picture

a simple username like puri007 should not give you any error. did you modify the code of the core? I suggest you install a fresh drupal-5.3 on the same server without any contributed module to see if you still get the error when creating an account with puri007.

siammoney.net’s picture

thank you, I use to drupal-5.2 because it's no error after new install.Now,I have suspect to log in of drupal members why accept a cookies because another's website had not to opened the cookie.

drumm’s picture

Title: warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module on » warning: mail(): Bad parameters to mail() function, mail not sent
Version: 4.7.3 » 5.2
Assigned: Unassigned »
Status: Active » Postponed (maintainer needs more info)

Please reopen when this has been tested with a current version of 5.x. 5.2 is now an older release.

yraffah’s picture

I'm having the same issue with D6.1. my site phsite.org/main is using an Arabic name in it's site name, I tried to change !site by explicitly defining it but that didn't help :(
I used to overcome this with the smtp.module, but it is not ported to 6.x yet, not sure if it even will be ported!

Server PHP version is 4.4.6

scor’s picture

Version: 5.2 » 6.x-dev
Assigned: » Unassigned
Priority: Critical » Normal
yraffah’s picture

I'm still having the same issue, does any one know of a solution?

scor’s picture

@liquid crystal: can you try the fix I described in #11 http://drupal.org/node/84883#comment-449438
it's not ideal, but it might help you. please report whether it works for you or not.
also, how many characters does the subject of the email contain?

yraffah’s picture

Hi scor,

It seems Drupal 6 is a lot different than Drupal 5 in terms of the unicode.inc. I'm not a programmer by any mean but at least that how it looks to my eyes:

279 function mime_header_encode($string) {
280 if (preg_match('/[^\x20-\x7E]/', $string)) {
281 $chunk_size = 47; // floor((75 - strlen("=?UTF-8?B??=")) * 0.75);
282 $len = strlen($string);
283 $output = '';
284 while ($len > 0) {
285 $chunk = drupal_truncate_bytes($string, $chunk_size);
286 $output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n"; <--- should I remove this \n?
287 $c = strlen($chunk);
288 $string = substr($string, $c);
289 $len -= $c;
290 }
291 return trim($output);
292 }
293 return $string;
294 }

The subject is 69 characters long, do you think I should try and make it less than 64?

yraffah’s picture

Hi scor,

Removing the \n from that line solved the problem, thanks a zillion time :D

Pr0v0dn1k’s picture

I've solved the problem on v6.2, PHP 4.4.7 in the following way:

in file 'includes/mail.inc', in line 186 replaced

mime_header_encode($message['subject']),
with
str_replace("\n", ' ', mime_header_encode($message['subject']) ),

It just replaces LF with SPACE in the subject after it is received from the mime_header_encode.

jcnventura’s picture

Component: user.module » base system
Status: Postponed (maintainer needs more info) » Needs work

This problem is encountered by all modules that send e-mail, including the contact module.

In the print module, a user was unable to send a message with the subject:
"admin has sent you a message from Urduseek.com انگریزی اردو لغت"

He later tried the same in the contact module, and it also failed. However, I have tried it in my system and it works fine.. He tried it in another system and was it was also fine.. The original print module issue is : #290517: bad parameters in mail() function.

João

yuREKLI’s picture

I encountered this error in a site which is hosted by Godaddy. I have solved this error by using SMTP Module: http://drupal.org/project/smtp.

Anonymous’s picture

Version: 6.x-dev » 7.x-dev
Status: Needs work » Active

There is no patch so setting back to active. Also bumping to 7.x since the problem still exists. Should we consider that Drupal core should use the logic from smtp module?

jcnventura’s picture

Status: Active » Needs work

There is a patch (in #44). It's not a machine-readable patch to use with the patch program, but it is a patch anyway.

João

greggles’s picture

Status: Needs work » Needs review
FileSize
1017 bytes

Which makes it not a patch. We only set the status to patch (code needs review) when there is a machine readable patch.

This patch was rolled against 6.x but also applies to 7.x.

scor’s picture

FileSize
848 bytes

note that this breaks the RFC2047, but seems to be the only way to fix the problem, unless it is fixed on a PHP level (as suggested by Steven).
patch documented.

Anonymous’s picture

The patch looks pretty. I don't have a means to test it though.

Anonymous’s picture

Status: Needs review » Needs work

The last submitted patch failed testing.

manoloka’s picture

This worked for me :-)

Thanks

Anonymous’s picture

Status: Needs work » Needs review

Resetting for the testbot one more time.

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community
Dries’s picture

Status: Reviewed & tested by the community » Needs work

Instead of writing 'see #84883', please reference the correct article in the RFC. Thanks.

apaderno’s picture

Title: warning: mail(): Bad parameters to mail() function, mail not sent » Bad parameters to mail()
scor’s picture

so far this issue has not been reproduced on PHP 5 so it might NOT be necessary to commit it to HEAD (and just to 6.x and 5.x). I'll try to reproduce on PHP 5.
EDIT: missed the NOT

apaderno’s picture

I tried to send an email from Drupal 6 installed in a local web site using PHP5, but I didn't have any problems. I changed the user name to Espero ååå, and then I sent a message using the contact form; Drupal didn't return any error messages.

I must then say that the local web site is running on a Mac using Mac OS X 10.5.6.

scor’s picture

Status: Needs work » Needs review
FileSize
865 bytes

rerolling patch against HEAD with link to this issue. I wasn't able to reproduce the issue on PHP 5, therefore I'm not convinced this needs to go into HEAD.
Would this issue deserve a test?

scor’s picture

@kiamlaluno the subject of your email must be at least 46 character long to reproduce the error. Try with the following subject:

Le sujet de ce message est très très très long!
apaderno’s picture

I tried it, and it didn't receive any error message.
I also tried it on Drupal 6.9 on my web site, running on Apache/1.3.41 (Unix) with PHP 5.2.6; the result didn't change.

It seems the problem is not present in PHP5.

yraffah’s picture

I still have the same problem on Drupal 6.9 PHP 5.2.6 when I send mail through the printmail functionality of Printer-friendly pages module.
Please try it here:
http://yousef.raffah.com/printmail/node

yraffah’s picture

Anybody else is still affected by this problem except me? :(

jcnventura’s picture

Status: Needs review » Fixed

Hi,

I have just used Drupal 5.15 to send a mail with subject "Le sujet de ce message est très très très long!Le sujet de ce message est très très très long!Le sujet de ce message est très très très long!" (3x the subject in #61) and it made it across OK..

I was using the print_mail module to send the message. I do notice that the contents of the message arrive as:

Subject: =?UTF-8?B?TGUgc3VqZXQgZGUgY2UgbWVzc2FnZSBlc3QgdHLDqHMgdHLDqHMgdHLDqHMgbG8=?=  =?UTF-8?B?bmchTGUgc3VqZXQgZGUgY2UgbWVzc2FnZSBlc3QgdHLDqHMgdHLDqHMgdHLDqHM=?=  =?UTF-8?B?IGxvbmchTGUgc3VqZXQgZGUgY2UgbWVzc2FnZSBlc3QgdHLDqHMgdHI=?=
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8Bit
X-Mailer: Drupal
Errors-To: me@example.com
Sender: me@example.com
Reply-To: =?UTF-8?B?Ikpvw6NvIENhcmxvcyA1ZWdyw6NvIFZlbnR1cmEgYSB2ZXIgc2UgaXN0byBkw6E=?=@example.com,
  =?UTF-8?B?IHByb2JsZW1hcyIgPGpjbnZABB12LmVzPg==?=@example.com
From: =?UTF-8?B?Ikpvw6NvIENhcmxvcyA1ZWdyw6NvIFZlbnR1cmEgYSB2ZXIgc2UgaXN0byBkw6E=?=@example.com,
  =?UTF-8?B?IHByb2JsZW1hcyIgPGpjbnZABB12LmVzPg==?=@example.com

Anyway, if this seems to with both Drupal 5.15 and Drupal 6.9 (both on PHP5), and it didn't work with another Drupal 6.9 in PHP5, it must be something outside of Drupal.. I am moving this to fixed status, unless liquid crystal can pinpoint the problem.

@liquid crystal: does applying this patch solve the problem for you??

João

scor’s picture

Status: Fixed » Needs review

this is not fixed yet!

yraffah’s picture

I just tried the patch in #60 and didn't get the error message I used to get earlier, however, I will still investigate further and report back if I stumbled upon any issue.
Thanks for the tip jcnventura

kenorb’s picture

Status: Needs review » Needs work

The last submitted patch failed testing.

mdupont’s picture

Any confirmation of #68?

Rafael Cansinos’s picture

Version: 7.x-dev » 6.9

Languaje: Spanish, with letters like ñ á é í ó ú.

Drupal 6.9

PHP Version 5.2.6

The problem begins when I installed the es.po for Spanish. I think (?) before it works properly.

Now, even if I come back to English languaje the problems is there.

Rafael Cansinos’s picture

I can confirm: this issue happens to me when I installed the Spanish translation for drupal (es.po). Before it works properly.

I have solved this error by using SMTP Module: http://drupal.org/project/smtp.

See #46.

Bairnsfather’s picture

Version: 6.9 » 6.10

I'm on Drupal 6.10 using php 5.2.8 and the problem(s) described above apply to me too. (In case it matters, I also have this on the Status page: Unicode library PHP Mbstring Extension.)

Here is the issue. When the title of a node (book page) has "curly quotes" aka "smart quotes" in it, there is an error after submitting a comment to the page:

Unable to send e-mail. Please contact the site admin, if the problem persists.

Appears at the top of the page upon comment submission.

In the Recent Log entries (/admin/reports/dblog) there are two errors:

  • php error: mail() [function.mail]: Bad parameters to mail() function, mail not sent. in /html/includes/mail.inc on line 193.
  • mail error: Error sending e-mail (from Admin @ domain.org to Admin @ domain.org).

If I go in to the book page, and edit the title and put plain quotes in place of the curly quotes, the email is sent without an error.

Best I can tell, my specific issue is in /includes/mail.inc on line 186. But I don't know enough to know how to address the issue, except for the workaround of not using fancy quotes.

scor’s picture

@hayworth and @Bairnsfather could you try with the patch at #60 and see if you still have the same problem?

josepvalls’s picture

Version: 6.10 » 6.12
Component: base system » language system

Same issue.
I've been looking at some transliteration implementation to replace those characters with either plain english or the html entities (preferred).
I'm new to drupal and not a php expert so any help would be appreciated.

magnjorg’s picture

I too had this issue. Patch in #60 did not work. Workaround in #22 works.

Using drupal 6.12, php 5.2.6.

scor’s picture

rerolling

PetrL’s picture

I had the same problem. In my case it was solved by solution sugested in comment #22. (drupal 6.11 , php 5.2.5)

czoper’s picture

#22 + #23 works just fine and solves the problem

THANKS netbjarne!!!

avillager’s picture

Version: 6.12 » 6.13

One more thing. To debug this I changed mail.inc to send mails with a fixed subject of "test" and put the encoded subject in the body so I can see what's output by the function.

It is:
=?UTF-8?B?W9Ce0LHRidC90L7RgdGCINCW0LjQstC+0YLQstC+0YAg0L7RgiDQoNC+0LTQvg==?=
=?UTF-8?B?0LLQviDQodC10LvQuNGJ0LVdINGC0LXRgdGC0LLQsNC5INGC0L7QstCw?=

As you can see, the first encoded word is 76 characters long which is one more than what the RFC allows. I tried to reduce chunk to 39 and now encoded word is less than 70 characters but it doesn't help at all.

One more thing against the RFC is that multiple lines in the RFC are separated by CRLF and in mime_header_encode it is only \n

avillager’s picture

I can confirm that patch from #77 works for me:
godaddy linux hosting vs PHP 5.2.8 (ask if you need more details)
drupal 6.13

The issue that encoded_word is 76chars is still worrying me though.

Thanks!

mics.programming’s picture

Patch from #77 works also for me.

I uses Hebrew lang.,
hosting - GoDuddy.

Thanks!

kenorb’s picture

Status: Needs work » Reviewed & tested by the community

#77 working fine.
Hosting: home.pl

Gábor Hojtsy’s picture

Version: 6.13 » 7.x-dev
Status: Reviewed & tested by the community » Needs work

1. Bugfixes are first committed to Drupal 7 to ensure we do not introduce regressions.
2. Dries already asked above to reference the proper RFC instead of this issue in the comment.

scor’s picture

Status: Needs work » Needs review
FileSize
709 bytes

rerolling just in case. The php mail function specs have changed and there is no such warning about the newlines in the subject anymore, and all it requires is to comply with RFC 2047. I'm tempted to close this issue except that some people have reported the same problem on PHP 5 (while I'm not able to reproduce it on my dev laptop). I'm leaving this open until they report back. Again, as a reminder, the problem occurs when the subject of the email is more than 46 characters and contains national characters like

Le sujet de ce message est très long!

Status: Needs review » Needs work

The last submitted patch failed testing.

scor’s picture

Status: Needs work » Needs review
FileSize
797 bytes

I was working on an outdated mail.sending.inc

jdeg’s picture

"$chunk_size = 400;" solved my problems :D

Dries’s picture

If this problem is not supposed to happen with modern versions of PHP, we should at least add a @todo.

Dave Reid’s picture

Component: language system » mail system
LatinBoy’s picture

I have a spanish site (6.14) n' had the same problem. "$chunk_size = 400;" worked for me!!! thanks netbjarne!!!

klausi’s picture

#87: 84883_subject_newline_d7_4.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 84883_subject_newline_d7_4.patch, failed testing.

ecedenyo’s picture

Version: 7.x-dev » 6.20

$chunk_size (./includes/unicode.inc) to 400, solved my problem. PD: I got the spanish translation

pillarsdotnet’s picture

Re-rolled patch from #87.

pillarsdotnet’s picture

Status: Needs work » Needs review
MichaelP’s picture

Patch at #95 [remove_linefeeds_from_subject-84883-95.patch] worked for me on godaddy hosting a non-english d7 site for user registration e-mails (contact form e-mails were working OK).

Tks @pillarsdotnet.

pillarsdotnet’s picture

Version: 7.x-dev » 8.x-dev
Assigned: Unassigned » pillarsdotnet
Issue tags: +Needs backport to D6, +Needs backport to D7

Bumping and tagging as per standards.

pillarsdotnet’s picture

You can help this issue by posting a review:

  • Decide whether all code and comments comply with Drupal coding standards.

  • Decide whether any included tests are necessary and sufficient.

  • Decide whether the patch actually solves the problem. There should be a reproducible test where the current code fails and the patched code succeeds.

A review that affirms success in all of the above should also:

  • Change the issue status from "Needs Review" to "Reviewed and Tested By the Community".

Otherwise, the review should:

  • Explain what is wrong with the proposed patch and/or supply a corrections to it.

  • Change the issue status from "Needs Review" to "Needs Work".

pillarsdotnet’s picture

Perhaps this issue is doomed to failure, since there has only been one patch against Drupal core mail system that ever became RTBC or fixed.

EDIT: Correction. There have been two. The other one is a four-year-old patch against D5.

Dave Reid’s picture

It's a relatively new component for issues...

pillarsdotnet’s picture

pillarsdotnet’s picture

Title: Bad parameters to mail() » Remove linefeeds from subject line to ensure that emails get sent properly.
Priority: Normal » Major

Better title.

Since this bug results in data loss (lost emails), does it qualify as "Major" ?

Anonymous’s picture

Title: Remove linefeeds from subject line to ensure that emails get sent properly. » mime_header_encode doesn't correctly follow rfc2047.
Priority: Major » Normal
Status: Needs review » Needs work

The patch supplied will break subject lines longer than 75 characters since \r\n can be inserted. The problem is actually in mime_header_encode(), the appended \n to the chunks should be \r\n as per http://www.faqs.org/rfcs/rfc2047.html.

Anonymous’s picture

Status: Needs work » Needs review
FileSize
836 bytes

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.

The patch removed a comment concerning the chunk separator because I don't see any relevance to it. All systems compliant with rfc2047 must use CRLF SPACE as the chunk separator and since we use PHP mail() function it is a requirement to follow rfc2047. The patch in #27 was almost correct but didn't follow rfc2047 either.

Anonymous’s picture

Here is the same patch for D7 and D6.

pillarsdotnet’s picture

Passing the torch to earnie. Somebody who has gained more respect than I (@sun? @Damien Tournoud? @Dave Reid?) should review the patch. Also, it should come with tests.

EDIT: Webchick says she'd accept an RTBC from scor. And instead of "gained more respect", I should have said "established a pattern of being really knowledgeable about this area of code."

Anonymous’s picture

Assigned: pillarsdotnet » Unassigned
Issue tags: +Needs tests

Add the test is a different issue and one I don't have time to do. The patch is simple and if the testing doesn't exist it should be handled separately IMO.

pillarsdotnet’s picture

The usual practice for urgent fixes is that the fix is committed first, then the issue changes back to "needs work" while tests are added. I'd be willing to write tests myself, but first I want to see a review from someone who is qualified to get this thing approved. I'd mark this issue RTBC myself except that I'm absolutely sure that webchick would bump it back to "Needs review" with a note that a core developer should look it over.

noomz’s picture

"$chunk_size = 400;" worked for me too. Thanks so much

emmene-moi’s picture

Version: 8.x-dev » 6.22

mime_header_encode should not encode Content-type definition... even if there's CRLF.

Why?
multipart/mixed; can add CRLF for boundary definition.

Check: http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

Thanks!

pillarsdotnet’s picture

Version: 6.22 » 8.x-dev

Please don't change the version.

Anonymous’s picture

This indicates that the entity consists of several parts, each itself with a structure that is syntactically identical to an RFC 822 message, except that the header area might be completely empty, and that the parts are each preceded by the line

--gc0p4Jq0M2Yt08jU534c0p

Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain).

NOTE: The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.

The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line -- that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. This is indeed how such entities should be composed. A tolerant mail reading program, however, may interpret a body of type multipart that begins with an encapsulation line NOT initiated by a CRLF as also being an encapsulation boundary, but a compliant mail sending program must not generate such entities.

Encapsulation boundaries must not appear within the encapsulations, and must be no longer than 70 characters, not counting the two leading hyphens.

The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line:

--gc0p4Jq0M2Yt08jU534c0p--

I don't see this as having anything to do with the change purposed in #106 which has to do with encoding and not mixed/multipart. In fact the two can co-exist in the same email, i.e. I can encode a multipart part.

As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The multipart delimiters and header fields are always 7-bit ASCII in any case, and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part.

apaderno’s picture

Title: mime_header_encode doesn't correctly follow rfc2047. » mime_header_encode() doesn't correctly follow the RFC 2047
Devin Carlson’s picture

Status: Needs review » Needs work

The last submitted patch, mime_header_encode-84883-106-D6.patch, failed testing.

Anonymous’s picture

Status: Needs work » Needs review

This issue is 6 years old and getting older. The patch is simple. Should we bump to major just to get a few core maintainer eyes this way?

klausi’s picture

No, it would be better to provide a working patch first + tests + reviews from people that set it to RTBC.

apaderno’s picture

Status: Needs review » Needs work
Anonymous’s picture

Status: Needs work » Needs review

The problem exists that the RFC 2047 is not followed. Per PHP documentation this is the RFC that they use. Therefore Drupal is broken.

klausi’s picture

Status: Needs review » Needs work

No patch for D8 here, so needs work.

apaderno’s picture

"needs work" is used when a patch has not been provided, or when the current patch needs to be changed. In this case, there isn't a patch that applies for Drupal 8.
"needs review" would say to the users "there is something to review," which is not true as there isn't a patch that applies to the current Drupal version.

Anonymous’s picture

klausi’s picture

Anonymous’s picture

FileSize
856 bytes

Rerolled patch.

apaderno’s picture

@earnie That proves my point: The test bot was not able to apply that patch; ergo, that patch needs to be re-written. "needs work" is the right status, in such case.
If somebody submitted a different patch, then "needs review" should be the correct status; differently, the test bot would not test the new patch.

mzwyssig’s picture

Is this going to be ported to D7 ?

pillarsdotnet’s picture

kscheirer’s picture

Status: Needs review » Needs work

We're going to need a test to prevent future regression, marking as "needs work". If you don't have time to write the test (totally understandable), then just describing how to test it would be very helpful. If it's simple enough, we might even be able to put a Novice tag on this and get a new test-writer to take a crack at it. The patch itself looks sane enough.

Anonymous’s picture

Status: Needs work » Needs review

Yes, I agree that we need a test but that can be a separate issue. This is a long standing bug that never had a test before and it needs to get fixed regardless of the testing. The RFC specification is clear and Drupal is not following it.

kscheirer’s picture

Issue tags: +Novice

Well, you can try for sure! :)

For the unit test: call mime_header_encode() and then verify the chunk size (45) and the line endings are \r\n instead of just \n. Does that sound about right?

bgm’s picture

Status: Needs review » Reviewed & tested by the community

I had a few issues related to this, and the patch fixed it for me. Thanks!
Tested on D6 and D7.

catch’s picture

Status: Reviewed & tested by the community » Needs work

Yes this needs a test before it can go in per #130.

stewart.adam’s picture

Note: for those that tried the patches in this issue and still have the 'bad parameter' error, you may want to see #300387: drupal_mail_send with long UTF-8 subject puts \n to subject line, the mail() function won't send it then..

DuaelFr’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs tests, -Novice
FileSize
1.06 KB
2.5 KB

Patch rerolled and test attached (plus a tiny comment improvement)

The last submitted patch, 136: drupal-8.0.x-mime_header_encode-tests_only-84883-136.patch, failed testing.

DuaelFr’s picture

Fixed a double space issue in the separator.
It seems to conform to the RFC's specs and examples now.

roderik’s picture

Done:

  • reviewed the test; I think input/expected-output pairs is indeed what/all we want here
  • changed test values, after wanting to see what exactly happened at the cutoff point. As a result, changed some wording from 'characters' to 'bytes'
  • changed the comment about the formula that results in 45 (and added some extra words to address comment #300387-6: drupal_mail_send with long UTF-8 subject puts \n to subject line, the mail() function won't send it then..) It seems that this formula has always been wrong. However I'm not the best mathematician and manipulating formulas including floor() and ceil() is nontrivial. My explanation of >1 line is the best I could do.
  • issue summary & stuff.

Leaving Needs Review for those changes.

roderik’s picture

DuaelFr’s picture

Thank you Roderik. It's a lot more understandable now :)

roderik’s picture

Hm. One slightly scary thing.

The issue summary now mentions that the restriction of php's mail() function not being able to handle subject lines containing \n, is gone since 2009.

But #300387-13: drupal_mail_send with long UTF-8 subject puts \n to subject line, the mail() function won't send it then. reports (one specific FreeBSD hoster, not FreeBSD in general) not being able to handle subject lines containing \n.... and also the patch (which replaces things by \r\n) not working.... in 2013.

The patch does not make much of a difference (it changes from "not working" to "not working") but also removes the comment that basically says "you may have to hack things yourself, on your own system".

DuaelFr’s picture

I don't know which version of PHP fixed that bug but, even if it's not supported by Drupal anymore we should add a comment that explain what happens.

roderik’s picture

That PHP version is very old. I guess you're still right though. It's a bit hard to decide what to say exactly, but I added a blurb.

Also: my 'formula/calculation' was completely bogus. I guess I finally get it now, and also get what was wrong with the comment (from july 2005):
It's not as the comment basically says

floor ( 63 * 3/4 ) == 47

but should be

floor ( 63 / 4 ) * 3 == 45

DuaelFr’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +D8MI, +email

That looks good to me.
The bug fix respects the RFC, includes tests and is well documented now.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 144: drupal-8.0.x-mime_header_encode-84883-144.patch, failed testing.

roderik’s picture

Status: Needs work » Reviewed & tested by the community

Seems the fail in DownloadTest (returning a 403 in the 2nd test run of 3) was a hiccup.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 144: drupal-8.0.x-mime_header_encode-84883-144.patch, failed testing.

roderik’s picture

Status: Needs work » Reviewed & tested by the community

After 4 days of succesful tests Jenkins says "aborted' (not "failure"). Assuming temporary hiccup again.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/core/lib/Drupal/Component/Utility/Unicode.php
    @@ -601,8 +601,14 @@ public static function strcasecmp($str1 , $str2) {
    +   *   able to deal with "\n" in subject lines, whose source (php or mailer) was
    

    It'd be could to have a test with \n in.

  2. +++ b/core/lib/Drupal/Component/Utility/Unicode.php
    @@ -601,8 +601,14 @@ public static function strcasecmp($str1 , $str2) {
    +   *   not confirmed. See https://www.drupal.org/node/300387#comment-7701323
    +   *   and please report details there in case of problems.
    

    Linking to an issue and saying reporting there if there are issues is interesting documentation. I'm not sure that this is the correct instruction or even if we should be making an instruction at all.

  3. +++ b/core/tests/Drupal/Tests/Component/Utility/UnicodeTest.php
    @@ -89,9 +89,16 @@ public function testMimeHeader($value, $encoded) {
    -      array('tést.txt', '=?UTF-8?B?dMOpc3QudHh0?='),
    

    Why remove this test? I don't think there is any harm in keeping this text to prove that the changes have not changed this.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

DuaelFr’s picture

New patch according to #150

DuaelFr’s picture

Issue tags: +DevDaysMilan

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

DuaelFr’s picture

Retesting in progress.
Let's try to awake this issue a bit :)

DuaelFr’s picture

Reuploading the patch to run the tests against 8.2.x

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

roderik’s picture

Re #150.2 removing the link to the other issue in comments is fine. I just think that my sentence "there have been occasional problem reports" gets strange then (because we effectively decide to ignore them. Which IMHO is fine). So I reworded that to an assertion about what the code does.

Sorry for still making a change so I can't officially set RTBC. Changes since #152:

  • reroll for 8.3.x array syntax
  • comment change.

(Changes since alexpott last saw it in #150: the interdiff in #152 + the interdiff in this comment.)

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

jungle’s picture

Version: 8.9.x-dev » 9.1.x-dev
Status: Needs review » Needs work
Issue tags: +Needs reroll

The current dev branch is 9.1.x.

Hardik_Patel_12’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
3.93 KB

Re-rolling patch for 9.1.x.

Status: Needs review » Needs work

The last submitted patch, 166: 84883-166.patch, failed testing. View results

jungle’s picture

+++ b/core/tests/Drupal/Tests/Component/Utility/UnicodeTest.php
@@ -39,6 +39,16 @@ public function providerTestMimeHeader() {
+      // Long ASCII string (more than 45 bytes).
+      ['1234567890abcdefghij1234567890abcdefghij123456', '1234567890abcdefghij1234567890abcdefghij123456'],

Comments could be transferred to keys. For example:

'Long ASCII string (more than 45 bytes)' => ['1234567890abcdefghij1234567890abcdefghij123456', '1234567890abcdefghij1234567890abcdefghij123456'],
TR’s picture

That's a real test fail in #166 - it happens because this patch changes the chunk size from 47 to 45. That matters in the failed test because mimeHeaderEncode() is called with $shorten = TRUE in the test, which truncates the string before encoding. When you truncate at a different place, the expected return value is different. The failed test needs to be fixed in this patch.

Also, the shorten option is not tested - a test is needed to ensure it does the right thing.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

larowlan’s picture

kim.pepper’s picture

Assigned: Unassigned » kim.pepper

Taking a look.

kim.pepper’s picture

Assigned: kim.pepper » Unassigned

Ran out of time.

anmolgoyal74’s picture

Should we update the expected string in tests or the mimeHeaderEncode() ?

TR’s picture

Here's a new patch. Changes from #166 are:

  1. Re-rolled against 9.2.x HEAD
  2. Formatting of data provider changed as per #168
  3. Test failure fixed as per #169
  4. New test added to test the 'shorten' parameter to mimeHeaderEncode() as per #169

Note that this patch also applies to 9.1.x, so it can be safely committed to that branch as well.

TR’s picture

Again, with coding standards fixed.

quietone’s picture

Status: Needs review » Needs work
  1. +++ b/core/lib/Drupal/Component/Utility/Unicode.php
    @@ -372,7 +372,7 @@ public static function strcasecmp($str1, $str2) {
    +   * Encodes MIME/HTTP headers containing characters that should be encoded.
    

    Can't this just say, 'Encodes MIME/HTTP headers.'?

  2. +++ b/core/lib/Drupal/Component/Utility/Unicode.php
    @@ -383,8 +383,12 @@ public static function strcasecmp($str1, $str2) {
    +   * - According to RFC 2047, we split long lines using CLRF SPACE as separator.
    

    It is CRLF and the 'we split' sounds wrong when we are complying with an RFC. I suggest, '- According to RFC 2047, long lines use CRLF SPACE and the separator.'

  3. +++ b/core/lib/Drupal/Component/Utility/Unicode.php
    @@ -383,8 +383,12 @@ public static function strcasecmp($str1, $str2) {
    +   * - PHP's mail() function (http://php.net/manual/en/function.mail.php) used
    +   *   to have an explicit restriction that subject lines could not contain LF.
    +   *   This restriction has been lifted since November 2009 or earlier, so we
    +   *   assume that systems having problems with them are extinct by now.
    +   *   See https://www.drupal.org/project/drupal/issues/84883.
    

    Do we need to keep a comment that refers to changes in PHP made 11 years ago? I don't think so, and it is not adding anything that helps understand the code as it is now. I think this can be deleted.

  4. +++ b/core/lib/Drupal/Component/Utility/Unicode.php
    @@ -396,13 +400,17 @@ public static function strcasecmp($str1, $str2) {
    +      // => ceil($chunk_size / 3) must be <= 63 / 4
    +      // => $chunk_size must be <= floor(63 / 4) * 3
    

    I think that => here means 'therefor' here? If so, let's use therefor instead of two characters. And for the final equation add the solution so that it is even clearer, 'floor(63 / 4) * 3' to 'floor(63 / 4) * 3 which is 45'.

  5. +++ b/core/lib/Drupal/Component/Utility/Unicode.php
    @@ -410,6 +418,7 @@ public static function mimeHeaderEncode($string, $shorten = FALSE) {
    +      // Remove \r\n from the end of the encoded string.
    

    Let's be consistent with other comments and use CRLF here.

  6. +++ b/core/tests/Drupal/Tests/Component/Utility/UnicodeTest.php
    @@ -21,21 +21,89 @@ class UnicodeTest extends TestCase {
    +    // The second parameter ($shorten) is set to FALSE, which is the default,
    +    // to ensure we do not truncate the result.
    

    Why is setting $shorten to FALSE needed? As the comment says it is the default. Is there some reason to think that the mimeHeaderEncode will not work if this is not set? There are other examples of this in the file that do not set the default. I'd say remove it.

ayushmishra206’s picture

Status: Needs work » Needs review
FileSize
2.01 KB
7.54 KB

I have addressed #177.1,2,3 and 4 in this patch. Attached is an interdiff to reflect that, please review.

quietone’s picture

Status: Needs review » Needs work

Patch didn't pass core/scripts/dev/commit-code-check.sh .

apaderno’s picture

core/scripts/dev/commit-code-check.sh is checking the word spelling. Two failures are caused by CLRF, which has been reported in comment #177 as typo for CRLF.

quietone’s picture

Status: Needs work » Needs review
FileSize
1.54 KB
7.58 KB

Let's get this moving again.

Making the changes to pass commit-code-check.

quietone’s picture

What I hope are improvements to commetns.

longwave’s picture

+++ b/core/lib/Drupal/Component/Utility/Unicode.php
@@ -396,13 +395,19 @@ public static function strcasecmp($str1, $str2) {
+      // The calculation is as follows:
+      // ceil($chunk_size / 3) * 4 <= 75 - strlen("=?UTF-8?B??=")
+      // ceil($chunk_size / 3) <= 63 / 4
+      // chunk_size <= floor(63 / 4) * 3.
+      $chunk_size = 45;

Instead of explaining it we could just do the calculation in PHP, ie.

$chunk_size = floor((75 - strlen("=?UTF-8?B??=")) / 4) * 3;
apaderno’s picture

I would not replace $chunk_size = 45 with $chunk_size = floor((75 - strlen("=?UTF-8?B??=")) / 4) * 3; but I would rather replace the calculation shown in the comment with that.

Kristen Pol’s picture

Status: Needs review » Needs work

Moving back to needs work.

jungle’s picture

Status: Needs work » Needs review

Change made per #184

longwave’s picture

Looks good - the tests are comprehensive and it will be nice to close a 14 year old bug!

Fixing the title as the original function is long gone.

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

alexpott’s picture

We should work on deprecating our mime encoding and use https://www.php.net/manual/en/function.iconv-mime-encode.php instead. We've got Symfony's polyfill in place so this code is not that useful. Also the implementation is still incorrect as you can't actually get the length correct unless the function also takes the field name. PHP's built-in mb_encode_mimeheader() suffers from the same problem which is why the Symfony polyfill does

    public static function mb_encode_mimeheader($s, $charset = null, $transferEncoding = null, $linefeed = null, $indent = null)
    {
        trigger_error('mb_encode_mimeheader() is bugged. Please use iconv_mime_encode() instead', E_USER_WARNING);
    }

or perhaps even better we should be using Swiftmailer and leave all this complexity to someone else.

The big problem is that in order to correctly mime encode a header and set it to the correct length we need to know the length of the field name as that is included in the length. Compare:

>>> iconv_mime_encode('a_header', 'Drépal this is a very long test sentence to encode did not attempt to chase down the use of this function any further, but it appears to be intended to check whether');
=> """
   a_header: =?UTF-8?B?RHLDqXBhbCB0aGlzIGlzIGEgdmVyeSBsb25nIHRlc3Qgc2U=?=\r\n
    =?UTF-8?B?bnRlbmNlIHRvIGVuY29kZSBkaWQgbm90IGF0dGVtcHQgdG8gY2hhc2U=?=\r\n
    =?UTF-8?B?IGRvd24gdGhlIHVzZSBvZiB0aGlzIGZ1bmN0aW9uIGFueSBmdXJ0aGU=?=\r\n
    =?UTF-8?B?ciwgYnV0IGl0IGFwcGVhcnMgdG8gYmUgaW50ZW5kZWQgdG8gY2hlY2s=?=\r\n
    =?UTF-8?B?IHdoZXRoZXI=?=
   """
>>> \Drupal\Component\Utility\Unicode::mimeHeaderEncode('Drépal this is a very long test sentence to encode did not attempt to chase down the use of this function any further, but it appears to be intended to check whether')
=> """
   \n
    =?UTF-8?B?Y29kZSBkaWQgbm90IGF0dGVtcHQgdG8gY2hhc2UgZG93biB0aGUgdXNlIG9mIHQ=?=\n
    =?UTF-8?B?aGlzIGZ1bmN0aW9uIGFueSBmdXJ0aGVyLCBidXQgaXQgYXBwZWFycyB0byBiZSA=?=\n
    =?UTF-8?B?aW50ZW5kZWQgdG8gY2hlY2sgd2hldGhlcg==?=
   """

The important part of the RFC is:

While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.

The line includes the field name.

quietone’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review
Related issues: +#1803948: [META] Adopt the symfony mailer component

@alexpott, thanks for the review.

So, this should either work on switching to use https://www.php.net/manual/en/function.iconv-mime-encode.php or use SwfitMailer. There is an issue in Drupal core ideas project, that started as a move to SwiftMailer but is now about using the Symfony mailer #1803948: [META] Adopt the symfony mailer component. It is not yet an approved plan though. Not sure what the next step here is.

If it were up to me I would postpone this and put effort in getting a decision on moving to Symfony mailer and only fix critical bugs in the current mail system.

Changing to NR for ways to keep this moving.

quietone’s picture

Asked in #bugsmash for ideas on what to do next here. longwave responded with "hard to say when both issues have been open a very long time!" I couldn't agree more.

In an effort to make a decision I decided to see what breaks if iconv_mime_encode is used. I wonder what will break?

alexpott’s picture

@quietone this needs a bit more than direct replacement in the Unicode::mimeHeaderEncode() code. I think we need a completely new method that takes the field name and value. The output of iconv_mime_encode() includes the field name because the only way you can get the length correct is by including the field name in the encoding.

I think maybe we can explore swapping out some of our functionality for symfony/mime and then build on that to use symfony/mail. In the mime package there is the Symfony\Component\Mime\Header namespace full of stuff we should be using.

quietone’s picture

Status: Needs review » Needs work

Arg another bad fix. I think I will give up.

Darn, I didn't see #193 before I made the coding standard fix.

@alexpott, I didn't expect this to be a good solution. Frankly, I was just curious to see what breaks and since at least one mail related test fails locally when on HEAD I can't find out otherwise. But it seems I am just making bad MRs right now so I should stop :-) I'll see if I can make sense of Symfony\Component\Mime\Header namespace.

alexpott’s picture

Status: Needs work » Needs review
FileSize
13.94 KB

So here's how I think we can leverage Symfony's mime classes without having to re-write the mail sub-system and solve a few mime encoding bugs. I do agree with others that want to replace some of the Mail ArrayPI with objects from Symfony mail and mime but this is a small step in that direction which solves bugs we have now and deprecates APIs that don't conform to the RFCs and can't. No interdiff because a new approach.

alexpott’s picture

#195 incorrectly adds the subject to the headers... fixing that.

longwave’s picture

+1 to the approach in #195.

+++ b/core/modules/file/file.module
@@ -594,10 +594,10 @@ function file_save_data($data, $destination = NULL, $replace = FileSystemInterfa
-  $type = Unicode::mimeHeaderEncode($file->getMimeType());
+  $type = new UnstructuredHeader('Content-Type', $file->getMimeType());
...
-    'Content-Type' => $type,
+    'Content-Type' => $type->getBodyAsString(),

I was looking at this earlier and wondered if this is actually correct. Is a Content-Type ever a non-ASCII string? Why do we do this here, for this header only, and nowhere else in our HTTP output? Shouldn't Symfony handle this encoding if it's necessary?

edit: traced the source of this line back 15 years to https://git.drupalcode.org/project/drupal/-/commit/0f6067fc849f749ca4356... but that doesn't help explain why it's needed or if it's actually correct nowadays.

edit 2: https://tools.ietf.org/html/rfc2047 says

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field, or in any structured
     field body except within a 'comment' or 'phrase'.

so I think this should be removed, let's do that in a separate issue.

The last submitted patch, 195: 84883-195.patch, failed testing. View results

alexpott’s picture

@longwave fwiw I think we can fix that before or after - the change included here is a like-for-like.

alexpott’s picture

We don't have a direct dependency of symfony/mime in HEAD - even though we should as we use it already in core. See #3207456: Drupal 9 is dependent on symfony/mime directly

Status: Needs review » Needs work

The last submitted patch, 196: 84883-196.patch, failed testing. View results

quietone’s picture

FileSize
907 bytes
13.96 KB

How ironic that the two failing tests are migration tests. So, I took a look and learned that \Symfony\Component\Mime\Header\Headers::addHeader will call other methods and they expect the data to be of particular types. And sure enough converting the header data to an array when needed allows the tests to pass. I just used a simple switch statement for the header types that will use \Symfony\Component\Mime\Header\MailboxListHeader. I've posted the work but not testing because it doesn't cover all possible header values and there is probably a more robust way to handle the problem.

alexpott’s picture

Status: Needs work » Needs review
FileSize
1.17 KB
14.07 KB

@quietone based this on your work in #202. There's not much we can do nice here... but we can assume that comma is the expected separator and trust \Symfony\Component\Mime\Address::__construct() to trim as appropriate and \Symfony\Component\Mime\Address::createArray() to work out which bit is an address and which is the name.

alexpott’s picture

I used a really really long site name full of greek characters. It generated the following headers. The longest line is 75 characters (not including the carriage returns)! Yay.

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8Bit
X-Mailer: Drupal
Sender: admin@example.com
From: =?utf-8?Q?=CE=89=CF=84=CE=B1=CE=BD_=CE=BC=CE=B9=CE=B1?=
 =?utf-8?Q?_=CF=80=CE=B1=CF=81=CE=AC=CE=BE=CE=B5=CE=BD=CE=B7_=CE=B9=CE=B4?=
 =?utf-8?Q?=CE=AD=CE=B1=2E_=CE=93=CE=B9=CE=B1=CF=84=CE=AF_=CE=B8=CE=B1?=
 =?utf-8?Q?_=CE=AD=CF=80=CF=81=CE=B5=CF=80=CE=B5_=CF=80=CF=81=CE=B1=CE=B3?=
 =?utf-8?Q?=CE=BC=CE=B1=CF=84=CE=B9=CE=BA=CE=AC_=CE=BD=CE=B1_=CE=B4=CE=B7?=
 =?utf-8?Q?=CE=BC=CE=B9=CE=BF=CF=85=CF=81=CE=B3=CE=AE=CF=83?=
 =?utf-8?Q?=CF=89_=CE=BC=CE=B9=CE=B1_=CF=84=CF=85=CF=87=CE=B1=CE=AF=CE=B1?=
 =?utf-8?Q?_=CF=80=CE=B1=CF=81=CE=AC=CE=B3=CF=81=CE=B1=CF=86=CE=BF=3B_?=
 =?utf-8?Q?=CE=98=CE=B1_=CE=BC=CF=80=CE=BF=CF=81=CE=BF=CF=8D=CF=83=CE=B1_?=
 =?utf-8?Q?=CE=BD=CE=B1_=CE=BC=CE=AC=CE=B8=CF=89_=CE=BA=CE=AC=CF=84=CE=B9?=
 =?utf-8?Q?_=CE=B1=CF=80=CF=8C_=CE=B1=CF=85=CF=84=CF=8C=3B_=CE=8C?=
 =?utf-8?Q?=CE=BB=CE=B5=CF=82?= <admin@example.com>

On head this header looks like:

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8Bit
X-Mailer: Drupal
Sender: admin@example.com
From: =?UTF-8?B?zonPhM6xzr0gzrzOuc6xIM+AzrHPgc6szr7Otc69zrcgzrnOtM6tzrEuIM6Tzrk=?= <admin@example.com>

Where we are shortening the sitename - even though we don't actually need to... but even with the shortening the line length is 102 not including the carriage returns

alexpott’s picture

So one problem with #203 is that we're now mixing line endings since Symfony obeys the RFC line endings ie "\r\n" internally but then will replace these with \n when using the sendmail transport (see https://github.com/symfony/symfony/blob/5.x/src/Symfony/Component/Mailer... ). So we need to do the replace too and keep using \n - there's some discussion of this fun here - https://stackoverflow.com/questions/4415654/which-line-break-in-php-mail....

quietone’s picture

Issue summary: View changes

Updated proposed resolution and added examples to the change record.

quietone’s picture

dww’s picture

The new approach looks very promising! Thanks to everyone who's worked on it.

A few final concerns / nits before RTBC:

  1. +++ b/core/lib/Drupal/Component/Utility/Mail.php
    @@ -29,8 +31,15 @@ class Mail {
       public static function formatDisplayName($string) {
    +    @trigger_error('\Drupal\Component\Utility\Mail::formatDisplayName() is deprecated in drupal:9.2.0 and is removed from drupal:10.0.0. Use \Symfony\Component\Mime\Header\MailboxHeader instead. See https://www.drupal.org/node/3207439', E_USER_DEPRECATED);
    
    +++ b/core/tests/Drupal/Tests/Component/Utility/MailTest.php
    @@ -21,6 +24,7 @@ class MailTest extends TestCase {
       public function testFormatDisplayName($string, $safe_display_name) {
    +    $this->expectDeprecation('\Drupal\Component\Utility\Unicode::mimeHeaderEncode() is deprecated in drupal:9.2.0 and is removed from drupal:10.0.0. Use \Symfony\Component\Mime\Header\UnstructuredHeader instead. See https://www.drupal.org/node/3207439');
    

    Slightly confused by this deprecation test. On a quick glace, it seems like calling Mail::formatDisplayName() is supposed to trigger a different deprecation error. Probably outside the patch context, Mail::formatDisplayName() ends up calling mimeHeaderEncode(), but it seems a bit less magical to check for the direct deprecation message about the function we're calling, not relying on "side effect deprecations" like this.

    Can/should we expected both deprecation errors? If not, I think I'd prefer testing for the explicit deprecation we added for that method...

  2. +++ b/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php
    @@ -75,13 +83,17 @@ public function mail(array $message) {
    +        $value = explode(',', $value);
    

    Does this want to explode with ', ' (with the trailing space)?

  3. +++ b/core/modules/system/tests/src/Kernel/Mail/MailTest.php
    @@ -147,9 +146,9 @@ public function testFromAndReplyToHeader() {
    -    $this->assertEquals('=?UTF-8?B?RHLDqXBhbCB0aGlzIGlzIGEgdmVyeSBsb25nIHRlc3Qgc2VudGVuY2UgdG8gdGU=?= <mailtest@example.com>', $sent_message['headers']['From']);
    +    $this->assertEquals('=?utf-8?Q?Dr=C3=A9pal?= this is a very long test sentence to test what happens with very long site names <mailtest@example.com>', $sent_message['headers']['From']);
    ...
    -    $this->assertEquals('Drépal this is a very long test sentence to te <mailtest@example.com>', Unicode::mimeHeaderDecode($sent_message['headers']['From']));
    +    $this->assertEquals('Drépal this is a very long test sentence to test what happens with very long site names <mailtest@example.com>', iconv_mime_decode($sent_message['headers']['From']));
    
    @@ -179,9 +178,9 @@ public function testFromAndReplyToHeader() {
    -    $this->assertEquals('=?UTF-8?B?RHLDqXBhbCwgInNpXHRlIg==?= <mailtest@example.com>', $sent_message['headers']['From']);
    +    $this->assertEquals('=?utf-8?Q?Dr=C3=A9pal=2C_=22si=5Cte=22?= <mailtest@example.com>', $sent_message['headers']['From']);
    

    I need to re-read all the recent comments to understand why these changes in behavior are now expected and legit. ;)

Otherwise, looks great! Test coverage seems pretty solid.

Thanks again,
-Derek

quietone’s picture

#208
1. Yes, that does seem odd. I've changed the deprecation message in the test.
2. RFC 5322 just says a comma separated list.
3. I wish you happy reading.

longwave’s picture

Re #208.2/#209.2 if so do we need to trim() the exploded values before passing to addHeader()?

alexpott’s picture

@longwave - nope we don't need to do that. Ensuring the address matches the RFC spec already happens in \Symfony\Component\Mime\Header\MailboxListHeader and \Symfony\Component\Mime\Address::__construct() - there's a trim in there...

alexpott’s picture

Re #209.3 these changes are because we've moved from base64 encoding to Q-encoding - both are valid for mime headers and because we now correctly support long display names in email addresses. As you can see one other benefit from moving to the Symfony component is only the necessary words are encoded and more is left in plain ascii which makes debugging and reading raw emails much simpler.

longwave’s picture

Status: Needs review » Reviewed & tested by the community

> one other benefit from moving to the Symfony component is only the necessary words are encoded and more is left in plain ascii which makes debugging and reading raw emails much simpler

+1 to changing it for this alone, I'm sure I've run into this before when trying to debug email output.

All nits were addressed. I also opened #3207476: file_get_content_headers() does not need to encode the Content-Type header as a followup to #197.

This both solves the problem at hand (after 14 years!) and also removes our custom implementations of something handled better by third party code, so to me this is RTBC.

dww’s picture

@quietone: Thanks for fixing the deprecation test, definitely looks better now.
@alexpott: Thanks for the explanation re: #209.3, makes sense.
@longwave: Agreed on RTBC!

Thanks everyone,
-Derek

longwave’s picture

Status: Reviewed & tested by the community » Needs work
alexpott’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
13.06 KB

Rerolled - considering we're only removing change - back to rtbc.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 216: 84883-216.patch, failed testing. View results

catch’s picture

Status: Needs work » Reviewed & tested by the community

Restoring status after HEAD was broken.

larowlan’s picture

I've asked if it's too late for this to go into 9.2. If it is, we'll need to re-roll so the deprecation messages say 'in 9.3' instead of 'in 9.2'

Will report back.

larowlan’s picture

@catch and @effulgentsia were ok with this going into 9.2

Updating issue credits

  • larowlan committed cb266b8 on 9.2.x
    Issue #84883 by quietone, alexpott, DuaelFr, scor, roderik, TR,...
  • larowlan committed ab49a62 on 9.3.x
    Issue #84883 by quietone, alexpott, DuaelFr, scor, roderik, TR,...
larowlan’s picture

Version: 9.3.x-dev » 9.2.x-dev
Status: Reviewed & tested by the community » Fixed

Committed ab49a62 and pushed to 9.3.x. Thanks!

Backported to 9.2.x

To the Bug-Smash folks and TR who breathed life back into this 5-digit NID issue from 15 years ago and alexpott for the final solution 🏆 - thank you

Published the change notice.

Status: Fixed » Closed (fixed)

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

super_romeo’s picture

super_romeo’s picture

tsuyopin’s picture

How to apply a patch to Drupal 9.2.6 ?

I could not apply "84883-216.patch" at #216.

"composer"
composer require cweagans/composer-patches:~1.0 --update-with-dependencies

"composer.json"

        "patchLevel": {
            "drupal/core": "-p2"
        },
        "enable-patching": "true",
        "patches": {
            "drupal/core": {
                "#84883 conform to RFC 2047." : "https://www.drupal.org/files/issues/2021-04-16/84883-216.patch"
            }
        },

"composer"

C:\xampp\htdocs\drupal>composer update drupal/core
Gathering patches for root package.
Removing package drupal/core so that it can be re-installed and re-patched.
  - Removing drupal/core (9.2.6)
Deleting core - deleted
Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing drupal/core (9.2.6): Extracting archive
  - Applying patches for drupal/core
    https://www.drupal.org/files/issues/2021-04-16/84883-216.patch (#84883 conform to RFC 2047.)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2021-04-16/84883-216.patch

Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
45 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Cleaning installed packages.
mdupont’s picture

It's already included in Drupal 9.2.6, it has been committed to the 9.2.x branch 4 months ago, nothing to do on your side.

tsuyopin’s picture

Thanks, mdupont.