Magento2: Confirmation emails have no FROM or FROM email address 2.2.4

Created on 3 May 2018  Â·  258Comments  Â·  Source: magento/magento2

Preconditions

Magento 2.2.4
PHP 7.1
Cpanel Server

Steps to reproduce

Production Mode
Single Store Mode
Add product to cart
Checkout

Expected result

Order confirmation email with FROM name and email address sent to customer per settings from store email addresses in config

Actual result

Order confirmation email contains no FROM or FROM EMAIL address.

Email Fixed in 2.2.x Fixed in 2.3.x Clear Description Confirmed Format is valid Ready for Work PR Created Reproduced on 2.2.x Reproduced on 2.3.x

Most helpful comment

Guys I made quick extension and forced it to be used only on Magento 2.2.4 version assume that bugfix will be in the next release.
I tested and it works on my websites. I hope it can help you as well:
https://github.com/sashas777/bug-from-email

You can install it using composer and then remove when will be new Magento 2 release. If you will forget to remove then you will have version compatibility error with any other Magento 2 release.

All 258 comments

I can confirm I am also seeing this issue. In order to work around the problem I have had to force the FROM header from the php.ini file.

sendmail_path= "/usr/sbin/sendmail -t -i -f [email protected]"

Have the same issue: Ticket #14945

@SamB-GB So need to add the mine mail in the php.ini ?thank you

Hi @SambB-GB,
I guess this is a misunderstanding. gwharton closed my issue "Store Email Adresses are not used anymore" because it is the same as this one. It does not mean, that there will be no soultion for it.

Correct gwharton ?
BR Chequille

@chequille yes. The solution to both will be tracked under this issue. Having it tracked in two places will just lead to confusion.

Yes thats correct @rigu12

This is the commit that introduced this bug.

https://github.com/magento/magento2/commit/f2bfdd941c0c8c6c7c745156d1ce206e38c76820

Broken during fix applied for #11740

If you manually revert the changes in files according to that commit, you can get back to pre bug status.

app/code/Magento/Sales/Model/Order/Email/SenderBuilder.php
lib/internal/Magento/Framework/Mail/Template/TransportBuilder.php

@RomaKis What was this commit trying to achieve?

Facing the same issue here in Magento 2.2.4. We have one website with 2 stores (Thai + English).

I had the same issue. after 2.2.3 >2.2.4 update. We have 4 websites with 2 stores each.

I did as gwharton suggested, I used the 2 files from 2,2,3 and it's working correctly now from what I can tell.

Thank you!

so 2.2.4 recover 2.2.3 this file?? @ozziel
app/code/Magento/Sales/Model/Order/Email/SenderBuilder.php
lib/internal/Magento/Framework/Mail/Template/TransportBuilder.php

You will have to recover them from their source folders:
NOTE: if you can't tell your restore function where to restore files and it restores them to the original path BE SURE TO BACKUP ORIGINALS ALREADY THERE FROM 2.2.4 before restoring
vendor/magento/module-sales/Model/Order/Email/SenderBuilder.php
vendor/magento/framework/Mail/Template/TransportBuilder.php

and then create the above folders and put them there
app/code/Magento/Sales/Model/Order/Email/SenderBuilder.php
lib/internal/Magento/Framework/Mail/Template/TransportBuilder.php

Keep in mind that this overrides magento default functions so if and when the corrections are made, you will need to remove these to use default functions again.

Hope this helps.

I did as ozziel suggested (thanks for pointing to the vendor folder where my files were) and it fixed the problem.

Correct. The fix by @ozziel worked for me too.
I hope there will come up a patch for this issue.

Have you tried to switch to any SMTP module if it would fix the issue until Magento patch will be available?

I have installed the module "Mageplaza_Smtp" and i tried "MagePal_GmailSmtpApp". Both gave me a blank from-sender. But that is obvious, because the problem is much further in the procedure. See answer from ozziel, the paths.

Guys I made quick extension and forced it to be used only on Magento 2.2.4 version assume that bugfix will be in the next release.
I tested and it works on my websites. I hope it can help you as well:
https://github.com/sashas777/bug-from-email

You can install it using composer and then remove when will be new Magento 2 release. If you will forget to remove then you will have version compatibility error with any other Magento 2 release.

The problem is they created a new class

MagentoFramework\Mail\Template\TransportBuilderByStore

and correctly added FROM header to member "message" of the class.

But the "message" member of TransportBuilderByStore never used. Instead, the member "message" of the class TransportBuilder is getting used(which never updated with FROM email).

Moral of the story, they added FROM email correctly but never used it while sending the email.

The tiny extension by @sashas777 does the required job as of now.

@sashas777 Good Job!! Just one suggestion, it would be better if you can rename the folder 'Plugin' to 'Rewrite' or something else. Because the fix is done using class rewrite instead of the plugin. The folder name "Plugin" misleads ;-)

@sashas777 I did the required change and created a pull request. Please merge it if it makes sense :smiley:

@ravinders-121

Thanks - I updated the package.

@sashas777 fixed it for me too - weird how such an important part can break so easily! No Sender means you get bounce-backs from any Gmail account at the very least

Hi guys,

a small module to fix it without touching the core:

https://github.com/pfortin-expertime/MageFix-Misc

A simple fix instead of installing a module is to do like below until fixed in next release:

Goto >. ..../vendor/magento/module-sales/Model/Order/Email/SenderBuilder.php
Edit function configureEmailTemplate() and add this line $this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());
to show like below:
protected function configureEmailTemplate()
{
$this->transportBuilder->setTemplateIdentifier($this->templateContainer->getTemplateId());
$this->transportBuilder->setTemplateOptions($this->templateContainer->getTemplateOptions());
$this->transportBuilder->setTemplateVars($this->templateContainer->getTemplateVars());
$this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());

//the below are commented
//$this->transportBuilderByStore->setFromByStore(  
//    $this->identityContainer->getEmailIdentity(), 
//    $this->identityContainer->getStore()->getId()

// );
}

Ive removed this revert from my store and gone back to the release version and it is now working fine. I have no idea why so many are seeing this issue anymore. However leaving the release code in place causes any function that sends multiple emails in one operation to send only the first, the remaining emails fail with exception.

@msawyers
Edit the core

@sashas777

I did this:
copy from the previous version to:
app/code/Magento/Sales/Model/Order/Email/SenderBuilder.php
lib/internal/Magento/Framework/Mail/Template/TransportBuilder.php

If anyone can reproduce this issue on demand, could they please attempt to diagnose/trace this issue by debug as I am no longer able to reproduce it. If anyone has this fault on a dev install, and would be ok with me connecting remotely to their install to debug then that would be great also. Get in touch.

I have deployed various test stores, vanilla 2.2.4, and 2.2.3 upgraded to 2.2.4 and all work faultlessly.

@gwharton sorry, but on my page when I use the code for app/code/Magento/Sales/Model/Order/Email/SenderBuilder.php from the release, the problem still exists.

Why should it work now, if nothing was changed in the code?

There is no new release, therfore, I really do not understand what you are talking about.
Fact is: 2.2.4 is not using Store Email Adresses and Names when sending EMails.

BR
Chequille

I upgraded from 2.2.3 to 2.2.4 and it stopped working. I reverted the code to 2.2.3 and it started working again. I changed code back to 2.2.4 and it still works. I deploy fresh 2.2.4 and it works.

I dont know whats going on either.

@gwharton

You can use temporary patch https://github.com/sashas777/bug-from-email
It easy to install and it will ask you to do uninstall after the upgrade

@gwharton, just guessing here: you didn't apply any other patches for 2.2.4 which might seem unrelated to this one? Maybe one of those other patches fixes this issue as well somehow ...

Same issue here,from address blank in sales email and SMTP server is not allowing to relay.

Sales email blank from address

Please help to fix the issue

Thanks

Encountered this issue as well in a 2.2.4. Fixxed with the solution from @gwharton .

@sashas777 Great job on the little plugin. Only problem is: Mageplaza PDF invoices breaks after installing the fix.. :-(

@Goeny
What error does it give?

@sashas777
It doesnt give an error. It simply does not send the PDF's along with the mail anymore. Can't see any error's in logs anywhere.

@gwharton:

I upgraded from 2.2.3 to 2.2.4 and it stopped working. I reverted the code to 2.2.3 and it started working again. I changed code back to 2.2.4 and it still works. I deploy fresh 2.2.4 and it works.
I dont know whats going on either.

Have you by any chance disabled the Amazon Pay module in 2.2.4? There is a report which claims that the Amazon Pay module causes this problem.

I really wonder why reverting to 2.2.3 and upgrade to 2.2.4 worked.
Not on my site.
Disabling Amazon Payment is causing an error, therefore cannot be the case why it is working.

@chequille: I just tested this myself, and you are right, only disabling Amazon_Payment causes a problem, because the Amazon_Login module also references the payment module in its config.xml file.

So then I tried the same with disabling both: Amazon_Payment & Amazon_Login as follows:

bin/magento module:disable Amazon_Payment Amazon_Login

And now my sales emails have a correct sender set:
screen shot 2018-06-24 at 17 29 04

So it looks like this bug has appeared since those Amazon modules got included by default in Magento 2.2.4, the question is: is it because the thing @kingyond mentioned:

vendor/amzn/amazon-pay-and-login-magento-2-module/src/Payment/etc/di.xml
find this line 63
<type name="Magento\Framework\Mail\MessageInterface" shared="false" />
remove the shared string
<type name="Magento\Framework\Mail\MessageInterface" />

Or is it because when those Amazon modules do this, that it triggers a previously hidden bug in Magento itself...

This does make sense come to think of it. I recently moved from composer install to github install. When installing via github, you don't seem to get any of the amazon modules by default in 2.2.4 which explains why I can no longer reproduce this issue.

Hi Again,
disballed Payment and Login and as expected: it is working again correct.
So, question is now, Where is the bug, in Magento or Amazon ?

The poorly implemented fix in #11740 exposed the bug in the Amazon module.

Should this bug be mentioned in both 2.2.4 and 2.2.5 release notes known issues? And work-arounds?

this Issue exist in magento 2.2.5

https://github.com/sashas777/bug-from-email

@sashas777 its not working in magento 2.2.5. good for magento 2.2.4
on magento 2.2.5 Your module says require magento 2.2.4

@vivekaris. Disable the amazon payments module as a workaround.

@vivekaris packaged version updated

Had this same problem in 2.2.5, I was able to get around it by disabling Amazon Pay with the following:

php bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment

I wish Magento would stop preinstalling stuff we might not need!

@paul-blundell Don't hold your breath. This is obviously a change of direction in order to monetise Magento. They've got to do it some how, and we as a community keep on creating extensions that make the enterprise features seem a little minimal for the fee.

In the meantime, it looks like the https://github.com/sashas777/bug-from-email module has been updated to allow the module to run in 2.2.5.

If you really want to stop modules being included when pulling in via composer, you can add something like this to your composer.json (untested for this specific modue btw):

"replace": {
      "amzn/amazon-pay-and-login-magento-2-module": "*"
}

YES, it is confirmed that problem resolved by disabling Amazon Payment.

I can confirm doing the same has resolved the problem for me too on v2.2.5

Yes mail is ok when Amazon Payment is disabled.

We confirmed this with upgrade from 2.2.3 to 2.2.5

So can we close this issue then?

Id be tempted to leave this open for now. For aslong as the bug exists in the amazon module and the module is installed by default by magento, this remains an issue with the stock magento install. Others may disagree.

yes, I agree...until amazon module problem is resolved, leave this open.

To close this issue i would say one of the follwoing needs to happen.

  1. Composer.lock is updated to point to a version of amazon module that has the fix applied.
  2. Amazon module is removed from default install.
  3. PR #16461 is merged.

yes, I agree...until amazon module problem is resolved, leave this open.

Ok.

Magento isn't going to fix this until a future release unless you are paying them for EE

https://twitter.com/richbaik/status/1017151928701104128

Magento isn't going to fix this until a future release unless you are paying them for EE

twitter.com/richbaik/status/1017151928701104128

This is not completely true, I think you misunderstood this a bit. This is an opensource project so we need the help of contributors.

@DanielRuf

I think I tried to do PR for this but we couldn't agree with @RomaKis if its a right way to fix the issue

Oh my good!!!
All this discusions are driving me to think about Magento is the right solution to go with?
Is it OpenSource or not?
If yes, such mandatory functions/features must work.
If not, cancel the open source.

If I have a look at all issues here with problems and bugs, I really wonder if these are all solved in the EE version. I doubt, it is the case.

My opionion, but sorry, I can not and do not want to go online with such a version. I stay with 1.9.x which is ok with me for the moment. We will see what happens in the future, but I think many others think like I do.

Best regards
Chequille

Oh my good!!!
All this discusions are driving me to think about Magento is the right solution to go with?
Is it OpenSource or not?
If yes, such mandatory functions/features must work.
If not, cancel the open source.

It is a big project and there are also the enterprise editions of Magento.
There are many contributors, ecommerce is not (so) simple and Magento is a powerful ecommerce framework.

If I have a look at all issues here with problems and bugs, I really wonder if these are all solved in the EE version. I doubt, it is the case.

Every software has bugs. Big projects often have more. This is not specific to Magento.

Yes, that is ok what you are saying in some point of view.
But as an Example: Typo3, a powerfull framework as you said about Magento, is Open Source since years and it does not have so many bugs as Magento. Sorry, this is the truth.
Specially bugs which occure after new releases as this one with the email sender and name and the Amazon stuff which I do not need!!!!!!!!!!!!!!!!!!!!!!!
Sorry, this is not acceptable.
Features, which are only available in the EE version, I can agree with. But mandatory features should work as well in the Open Source version and should not break in new releases of the system.

By the way, is it working with the EE version?

This is not the way OpenSource should work. Do not forget, that I spend as well time to report bugs and try to find solutions. As well time and money!!!!

BR
Chequille

I forgot to ask:
Are the bugs solved in the EE version?
Or let me ask: which of the 1284 issues are solved in the EE version?

Typo3, a powerfull framework as you said about Magento, is Open Source since years and it does not have so many bugs as Magento

Sorry but I have to disagree. I work at a TYPO3 digital agency and they have many open bugs. Also take a look at contributor counts, ease of contribution, open/closed issue ratio, ...

Your point is not valid. Also enterprise CMS (TYPO3) !== eCommerce framework (Magento 2 / Varien).

Regressions can always happen, in any software (eg Chrome and Firefox where I reported some).

This is not the way OpenSource should work.

Sorry but this is how opensource works, we are just humans. The enterprise edition has some extra modules but shares the same core and many of the same modules. It is one product in the end.

Are the bugs solved in the EE version?
Probably not.

Or let me ask: which of the 1284 issues are solved in the EE version?

As EE user you have some extra support, we can not answer this.

To be fair this project is provided free so wether the bugs are quashed in the FREE version apposed to the paid version is pretty irrelevant, of course the EE customers are going to be looked after before OpenSource customers. Thing is I think you will find that the OpenSource version you will often get a patch or a workaround that someone else will contribute and this can often be much faster than if the source code was closed.

All of the bugs I have had to deal with (No sender in e-mail, area not set when changing template, date issues when saving products have all had workarounds that I could put in place). That said many of the issues I am seeing cropping up recently are due to 3rd party modules being included with the products and there has to be much more stringent checks of these modules as I have had to disable at least three of them to correct bugs they introduced.

area not set when changing template

I created a PR / patch for it, it will land in 2.2.6.

I disabled Amazon module for now as I understand that it was that causing it.

I never had a feature not working anymore in a new release of Typo3.
You might have to adapt extensions when fluid or vhs changed functionality, but mandatory functions are never broken ( on my sites definetely).

I just read the new comments while I am writing :-)
Of course we are all humans and as well software is never bug free. But at the moment, I see only problems with Magento. Maybe I am wrong, but it is my feeling.

@DanielRuf: I do not know if you are part of Magento, but to be honest: bugs are normal, no software without these little bad things, but I cannot understand and accept features in new versions not working anymore. That's all what I do not like currently.

BR
Chequille

@chequille

I disabled Amazon module for now as I understand that it was that causing it.

Thirdparty code.

@DanielRuf
Question if you work at Magento: Is there a way to have 3rd party modules which included in core being QA'd and checked by Magento before they added into the new release? There are two of them at least added and both seem like wasn't checked. I was developing at some time one of them for 2.0 and I don't see that code was adapted to the newest versions.

It is the same for EE.

I am on Magento 2.2.5 EE and I am having the same issues.

Using 2.2.5 CE plain vanilla. Amazon Pay has NEVER been enabled. Problem still exists.

@DanielRuf

I disabled Amazon module for now as I understand that it was that causing it.

Thirdparty code.

That Magento forced upon us.

@JosiahCarberry make sure to run

bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment

I have disabled a lot of these extra plugins that have come with Magento recently and added this to composer.json

"replace": {
"dotmailer/dotmailer-magento2-extension": "",
"klarna/module-core": "
",
"klarna/module-kp": "",
"klarna/module-ordermanagement": "
",
"shopialfb/facebook-module": "",
"temando/module-shipping-m2": "
",
"vertex/module-tax": "",
"amzn/amazon-pay-and-login-magento-2-module": "
"
}

@SamB-GB
the replace in composer did not work on my site.
Error: Could not parse version constraint : Invalid version string ""
Any idea?

@chequille which composer version do you use?

Hi Daniel,
it is the one coming with magento installation.
I typed all versions as of the composer.json file of each module into the replace statement mentioned above.
It worked after this.

Which version of composer is accepting the empty version definition as in the replace array above?

Regards,
Chequille

No I mean composer --version.

Hi Daniel,
as I said, I am running composer version which is under vendor/composer/composer/bin coming with magento installation.

It returns with --version "Composer version 1.4.1 2017-03-10 09:29:45"

Related issue on Amazon...

https://github.com/amzn/amazon-payments-magento-2-plugin/issues/274

Module: Amazon_Payment
File: etc/di.xml
Line: 63
Code: <type name="Magento\Framework\Mail\MessageInterface" shared="false" />

Reason:
This is set in the global scope and makes every DI create a new version of message.

bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment

solved that problem for me

Magento 2 2.2.5

Thanks to @JosiahCarberry

Still a problem in 2.2.5
Going to try @sashas777 's work around, but I'm not installing via composer....
https://github.com/sashas777/bug-from-email

Using Magento2 SMTP module.
https://github.com/mageplaza/magento-2-smtp

Using Community Edition of 2.2.5 and my issue is fixed now! Thanks @ralfblask ! and the original poster who I didn't mention - you know who you are. :-))

Once again;
bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment

WORKED for me.

Cheers

This DI in the Amzn module looks like a pretty major violation of the Magento code API to me. You can't just change the core behavior like that to suit your needs on a module that's going to be force installed on every instance of the framework.

We've hit a number of bugs in M2 recently that have lead back in some way to these third party vendor modules that are now being included in the core product (see also Temando). These modules seem to be operating outside Magento's own code quality directives and are allowed to update independently of Magento's point releases potentially dragging in bugs at any time on a stable build.

How are other people dealing with this? Is disabling these modules actually safe, or are they potentially tied in to the core now in a way that removal may cause a dependency issue? I assume that as the modules are not under the Magento vendor they should be safe to remove without affecting the core. @SamB-GB how have you been finding it with those modules dropped from the build?

I run from github, where you don't seem to get any of those "optional" modules installed by default. I certainly don't even have temando or any amazon modules installed, let alone disabled.

I know previous to these modules causing issues, I ran from composer, which did seem to install both Temando and Amazon modules by default.

It does seem rather odd that the majority of testing on magento, including all automated testing, is done from a github deployment which means that there is 0% code coverage for these modules in question.

They really shouldnt have been enabled in the composer installs and not in github installs. Perhaps if they were deployed in github installs, then some of these issues may have been picked up in Travis.

@chris-pook: for all shops we maintain which run on Magento 2.2.4 and higher, we have this part added to our composer.json file (was already mentioned above by @SamB-GB).

    "replace": {
        "amzn/amazon-pay-and-login-magento-2-module": "*",
        "dotmailer/dotmailer-magento2-extension": "*",
        "klarna/module-core": "*",
        "klarna/module-kp": "*",
        "klarna/module-ordermanagement": "*",
        "shopialfb/facebook-module": "*",
        "temando/module-shipping-m2": "*",
        "vertex/module-tax": "*"
    },

It makes sure none of these CBE's (Core Bundled Extensions) get installed. They are by no means tied to the core, so you can safely ignore them.

I agree with everyone in here which thinks they should either:
a) be disabled by default
b) get tested by default

I assume there is some kind of financial deal made between those vendors and Magento, and they probably can't disable them due to legal obligations, but that's only guessing here, since there is not really an official public statement about why these things got included and enabled by default.

Same issue.
Updated to 2.2.5 → All Emails where getting sent from my www-data user instead of the correct emailadress.
Disabled amazon modules and ran bin/magento s:d:c → worked, using correct emailadress now

Thanks @hostep @gwharton @SamB-GB , good to see the community is hot on this sort of thing.

Great shout removing these via composer. I wonder if we could perhaps start a movement for this to be the de facto install method, forcing the hand of Magento to incorporate these vendors in core somewhat? Most importantly then having to include them in testing. I appreciate that this is a free software product and inclusion of these third parties is likely leveraging some profit but if they are poorly implemented then the lifetime of the core product is going to be limited as devs start walking away to alternatives.

Solution is work perfectly here

A simple fix instead of installing a module is to do like below until fixed in next release:

Goto >. ..../vendor/magento/module-sales/Model/Order/Email/SenderBuilder.php
Edit function configureEmailTemplate() and add this line $this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());
to show like below:
protected function configureEmailTemplate()
{
$this->transportBuilder->setTemplateIdentifier($this->templateContainer->getTemplateId());
$this->transportBuilder->setTemplateOptions($this->templateContainer->getTemplateOptions());
$this->transportBuilder->setTemplateVars($this->templateContainer->getTemplateVars());
$this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());

//the below are commented
//$this->transportBuilderByStore->setFromByStore(
// $this->identityContainer->getEmailIdentity(),
// $this->identityContainer->getStore()->getId()
// );
}

@ankit1388 this is not a good practice. Better use composer-patches.

This is the patch file I was given from Magento support
MDVA-10993_EE_2.2.4_v1.composer.patch.zip

Hi Hans,

It worked for me now I can see from address applied below patch as you mentioned

https://github.com/magento/magento2/files/2309277/MDVA-10993_EE_2.2.4_v1.composer.patch.zip

Thanks...

@DanielRuf I accept your answer. thanks

Can you tell me how we use this patch in magento2.2.5

The Magento Patch MDVA-10992_EE_2.2.4_v1.composer.patch implements the same solution that is waiting to be merged in PR #16461

I think we have some article / guide somewhere.

There are some instructions at https://magento.stackexchange.com/questions/175598/how-to-apply-the-magento-2-patches.

Composer has to know where the needed patches are.

support.magento.com/hc/en-us/articles/360005484154-Create-a-patch-for-a-Magento-2-Composer-installation-from-a-GitHub-commit

Ah right, this article is the one that I meant.

The issue affects 2.2.4 and 2.2.5 - we have resolved it for 2.2.6 and later versions. Fix: https://github.com/amzn/amazon-payments-magento-2-plugin/pull/288

Just upgraded to 2.2.5 and have run into this issue.

@prayagr, When will 2.2.6 be released?

Hi @inkobject , I am not sure of the exact release date, but to implement this change for your current setup, you only have to make a minor change as seen here: https://github.com/amzn/amazon-payments-magento-2-plugin/pull/288/files

the issue is still present in 2.2.6
@ankit1388 solution worked for me

the issue is still present in 2.2.6
@ankit1388 solution worked for me

Only the soln is - disable amazon pay.

Solution is work perfectly here

A simple fix instead of installing a module is to do like below until fixed in next release:

Goto >. ..../vendor/magento/module-sales/Model/Order/Email/SenderBuilder.php
Edit function configureEmailTemplate() and add this line $this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());
to show like below:
protected function configureEmailTemplate()
{
$this->transportBuilder->setTemplateIdentifier($this->templateContainer->getTemplateId());
$this->transportBuilder->setTemplateOptions($this->templateContainer->getTemplateOptions());
$this->transportBuilder->setTemplateVars($this->templateContainer->getTemplateVars());
$this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());

//the below are commented
//$this->transportBuilderByStore->setFromByStore(
// $this->identityContainer->getEmailIdentity(),
// $this->identityContainer->getStore()->getId()
// );
}

Although this is not a good practive, this does fix our problem on Magento 2.2.6.

Hi @Cristiano81 , @rishabhchd19 , @MartinAarts - Sorry to see you are still facing issues with the email address 'From' field. We are not able to reproduce the issue on a fresh 2.2.6 setup, can you confirm that you recompiled and flushed the generated classes?

Also, we would like to observe the issue to debug. If possible, please reach out to us on [email protected] with details.

I'm trying all viewed solutions about this issue, but nothing works on 2.2.6. Many mail from my store are now spam because this issue:
550-5.7.1 'From' header is missing.

@salelsol disabling these modules works for me - obviously not going to help if you're using any of them!

php bin/magento module:disable Klarna_Core Amazon_Core Amazon_Login Amazon_Payment Klarna_Ordermanagement Klarna_Kp Vertex_Tax

The following modules have been disabled:

  • Klarna_Core
  • Klarna_Ordermanagement
  • Klarna_Kp
  • Vertex_Tax
    O.K. now expect all new order.
    Many Thanks for your help.
  • Neither this solutions works for my multistory, is incompatible with One Step Checkout module installed.

@salelsol I have made a PR for your issue. https://github.com/magento/magento2/issues/16355#issuecomment-399668596
PR : https://github.com/magento/magento2/pull/16356

This works for my customers

Just install a small module on your magneto 2.2.5 that will work

https://github.com/manojind/magento2.2.5-email-sender

Hi @manojind: This repository is empty.

ive the same issue on Magento 2.2.6 With 2.3-beta18

but im not using the amazon plugin.

im currently writing my own plugin which sends mail to Postmark of SES. it has worked till 2.2.5 with an 2.3-alpha61 or lower i believe.

On 2.2.6 without amazon module, when Magento sends multiple emails, the first has the correct from address, the second and remaining emails don't.

And on 2.3-develop no emails whatsover have a from address, and even if that is fixed, the core Magento code for sending emails has had the "from name" part of it removed for some crazy reason.

I submitted PR's to magento to fix all of the above but they were rejected. Oh well.

I submitted PR's to magento to fix all of the above but they were rejected. Oh well.

Can you link them here so we can take a closer look?

18471 #18472 #18473

I can't believe this is still an issue in 2.2.6...

The worst part is 2.3.0 is going to launch with it too! Although it looks like I have finally got agreement on a way forward with the PR's. They're gonna be in 2.3.1 and possibly 2.2.7 depending on how quickly I can get em through.

No one will fix this?!

2.3 fix is approved, awaiting merge, due to be in 2.3.1. 2.2 fix is on hold, presumably will be merged after 2.3 fix has been merged.

Has this been fixed in 2.2.7?

This issue still exist in 2.2.7!

I did a composer update to 2.2.7 and this is resolved, this was caused by amzn/amazon-pay-module and in the latest bundle for 2.2.7 the line in di.xml for this module is removed so this should work.

  • After upgraded from Magento 2.2.6 to 2.2.7 and still same issueI´m trying some solutions but for now I can't fix this old issue.

also affected in 2.2.7 with all amazon modules disabled.

Have you tried applying PR #18472

@gwharton , I just modified the 4 files also flushed magento cache, but nothing changes header email without sender. Should we do more ??

php bin/magento setup:di:compile
php bin/magento setup:deploy

Aswell

@gwharton ; thanks for your help but issue still remain the same.

As I am able to see - https://github.com/magento/magento2/pull/18471/files/f171c9d6ab035439ffb6374ec14dd8d51123dcd2#diff-134b78852b9ecf820540911b665d6566 has resolved the problem in 2.3.0.

18471 is fix for 2.3 approved but not merged yet

18472 is fix for 2.2 currently on hold, would imagine will be merged once 2.3 fix is applied.

18471 is fix for 2.3 approved but not merged yet

18472 is fix for 2.2 currently on hold, would imagine will be merged once 2.3 fix is applied.

I have tried backing up the files and merged manually to the original source in 2.3. As it is verified & approved, I can rely on this fix. My testing is positive after making changes to all these 7 files. Haven't tested "Order emails not send to Admin in BCC" yet.

"Order emails not sent to admin in Bcc" was fixed in this commit. https://github.com/magento/magento2/commit/9a7c9e553b1c9814907105388bffc2e8a91353a5#diff-dfb3ee5a7f863458afea75f5524cd2e5

That fix is present in 2.2.7 and 2.3.0.

Note, that 2.3.0 also has a separate email issue where the from address is set, but not the from name. If you run into that, then the fix for that is included in #18471 which is scheduled to be included in 2.3.1.

  • After upgraded from Magento 2.2.6 to 2.2.7 still worse, Inputbox mail plenty of returned order confirmation mails due to this older issue:

Mail delivery failed: returning message to sender This message was created automatically by mail delivery software.

  • Need any provisional solution, I'm thinking in change SMTP provider ??
  • At end I'm fixed this provisional issue just changing this function in file: vendor/magento/module-sales-Model/Order/SenderBuilder.php

protected function configureEmailTemplate()
{
$this->transportBuilder->setTemplateIdentifier($this->templateContainer->getTemplateId());
$this->transportBuilder->setTemplateOptions($this->templateContainer->getTemplateOptions());
$this->transportBuilder->setTemplateVars($this->templateContainer->getTemplateVars());
$this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());

//the below are commented
//$this->transportBuilderByStore->setFromByStore(
// $this->identityContainer->getEmailIdentity(),
// $this->identityContainer->getStore()->getId()

It looks like this issue is missing again from the "known issues" section in the release notes for 2.2.7 and 2.3.

Please do not directly change core files and create and apply patches with composer-patches.

When will this bug be fixed? I am getting this in 2.3.0.

According to the PR. Should be in 2.3.1

When will 2.3.1 be available? Looking to get this fixed in a month or so.

Someone quick fix for Magento 2.2.7?

I am on 2.3 and still having this, any solution without additional modules please.

As previously stated

18471 is fix for 2.3 approved but not merged yet

18472 is fix for 2.2 currently on hold, would imagine will be merged once 2.3 fix is applied.

You can manually apply these PR's to your install and they will get overwritten on the next release (which will hopefully have the fix)

I am on 2.3 I disables all Amazon modules but still having this problem,

php bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment
I don't find the trick to make it work

@Socix, i have tried making changes with PR as stated above by gwharton but not the Patches to see if this resolve the problem or not. Whoooola! it worked. Now i am going to revert back the changes and apply patches with .diff. I hope 2.3.1 will release soon.

@rishabhchd19 thank You, I'm going to try it now

@SoCix, there are 7 files related to this issue. Better you apply patches rather making changes directly to core files. Your composer need to update to work with Patches.

There are solutions like composer-patches and you can add .patch to a commit or PR URL.

https://patch-diff.githubusercontent.com/raw/magento/magento2/pull/18471.patch is what you get when you go to https://github.com/magento/magento2/pull/18471.patch

Just migrate from M2.2.7 to M2.3.0 at issue continue, but I don't find file: vendor/magento/module-sales-Model/Order/SenderBuilder.php and change that I was working correctly in version 2.2.7:

protected function configureEmailTemplate()
{
$this->transportBuilder->setTemplateIdentifier($this->templateContainer->getTemplateId());
$this->transportBuilder->setTemplateOptions($this->templateContainer->getTemplateOptions());
$this->transportBuilder->setTemplateVars($this->templateContainer->getTemplateVars());
$this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());

//the below are commented
//$this->transportBuilderByStore->setFromByStore(
// $this->identityContainer->getEmailIdentity(),
// $this->identityContainer->getStore()->getId()

Sorry, found.

Hi @rishabhchd19 ,can i ask you what file you changed?thank you!

h3y @andy17612, as already stated above "there are 7 files related to this issue as mentioned in the PR by gwharton. Better you apply patches rather making changes directly to core files. "
With a work to patch, you have a procedure to apply .patch file.

I had made changes directly to core files by making a backup before just to test the resolution provided in PR. The files have now revert back to original and i have applied patches finally with a proper patch process.

Hi @rishabhchd19 are you meaning there? https://github.com/magento/magento2/pull/18471/files thank you!

as per previous response by gwharton "As previously stated

18471 is fix for 2.3 approved but not merged yet

18472 is fix for 2.2 currently on hold, would imagine will be merged once 2.3 fix is applied."

if you are required for 2.3 #18471 is the resolution.

@rishabhchd19 thank you!
And do you have this bug on 2.3 , i am getting this bug again https://github.com/magento/magento2/issues/18150

@DanielRuf Using composer patch is not a option here... there's any release date for the 2.3.1?

@DanielRuf Using composer patch is not a option here

Why not?
And normal patches? It's just a patch file in both cases, just the path is different.

@hazzan3li with composer-patches or patch -p0 18471.patch.

Or search for "how to apply patch file" + your OS (should be some Linux) at Google.

Thank you
I applied the patch with patch.php method but I don't know if it's applied or not
the screen only shows **done
my website hosted in shared hosting

patch -p0 18471.patch ????

Not sure what you mean with patch.php. You have to check the files if they contain what you see in the patch file (the changes with + at the beginning).

patch.php method to patch magento
Make one file with the name of patch.php, write the following code in it,
php print("<PRE>"); passthru("/bin/bash abcd.patch"); print("</PRE>"); echo "Done";

replace the file name in it, upload it in the root and run the file from the browser.
Name should be abcd.patch

This is not needed. You can do the same with SSH. In this case rename the file to abcd.patch or similar.

Where is this from? Our official docs?
passthru() is often disabled as this is not a secure way and the patch files are not bash scripts.

@hazzan3li : this sound like how patches are applied for Magento 1 shops. Those were bash scripts, but the patches for Magento 2 shops are pure git diff files which won't work if you execute them with bash.

If you use composer to install Magento, it's best to follow something like mentioned in this article: https://support.magento.com/hc/en-us/articles/360005484154-Create-a-patch-for-a-Magento-2-Composer-installation-from-a-GitHub-commit (if you never done something like this before, it might take you a while until you've figured it out how to make this work best, but then you'll also be able in the future to more quickly incorporate other patches, so it's very beneficial to understand how this works in the long run)

it is too hard to understand all of these complex thinges I am a begginer
THANK YOU ALL

@hazzan3li : this sound like how patches are applied for Magento 1 shops. Those were bash scripts, but the patches for Magento 2 shops are pure git diff files which won't work if you execute them with bash.

If you use composer to install Magento, it's best to follow something like mentioned in this article: https://support.magento.com/hc/en-us/articles/360005484154-Create-a-patch-for-a-Magento-2-Composer-installation-from-a-GitHub-commit (if you never done something like this before, it might take you a while until you've figured it out how to make this work best, but then you'll also be able in the future to more quickly incorporate other patches, so it's very beneficial to understand how this works in the long run)

what changes I have to make in json file
Module: ??
Title: ??
_Path to patch_: "patches/composer/18471.diff" +1:

Just migrate from M2.2.7 to M2.3.0 at issue continue, but I don't find file: vendor/magento/module-sales-Model/Order/SenderBuilder.php and change that I was working correctly in version 2.2.7:

protected function configureEmailTemplate()
{
$this->transportBuilder->setTemplateIdentifier($this->templateContainer->getTemplateId());
$this->transportBuilder->setTemplateOptions($this->templateContainer->getTemplateOptions());
$this->transportBuilder->setTemplateVars($this->templateContainer->getTemplateVars());
$this->transportBuilder->setFrom($this->identityContainer->getEmailIdentity());

//the below are commented
//$this->transportBuilderByStore->setFromByStore(
// $this->identityContainer->getEmailIdentity(),
// $this->identityContainer->getStore()->getId()

It's work. Thank You @salelsol

Hi
how to edit composer json file to fit for patching (problem 18471)
"extra": {
"composer-exit-on-patch-failure": true,
"patches": {
"?????": {
"??????????????????": "patches/composer/18471.diff"
}
}
}

@hazzan3li : here's is how we do it, but this is using #18472, because we have no shops on Magento 2.3 yet, only on 2.2.

We split the patch in 2 parts, because it affects 2 different Magento modules: magento/module-sales and magento/framework, and change the paths in the diff files so they are relative against the module filestructure.

So in your composer files, you add something like this:

    "patches": {
        "magento/module-sales": {
            "PR-18472: Alternative fix for Multi Store Emails issue, Fix Async Emails issues, Fix Multiple Email issues": "PR-18472-Sales.diff"
        },
        "magento/framework": {
            "PR-18472: Alternative fix for Multi Store Emails issue, Fix Async Emails issues, Fix Multiple Email issues": "PR-18472-Framework.diff"
        }
    }

And the diff files themselves in this zip file:
PR-18472.zip

Please try to understand how the cweagans/composer-patches package works, so you can try to do the same using #18471

If you have further questions around how to apply patches, it might be best to go to https://magento.stackexchange.com/ or https://community.magento.com/, because Github isn't really ment for questions and answers like this.

Thanks and good luck! :)

Much-appreciated, @hostep -- what a killer module!

Thanks @hostep, this made things so much easier! Works in both my 2.2.5 and 2.2.7 environments.

Here is a patch for Magento 2.3.0:

PR-18471.zip

One more query...is this patch replace file/entire coding or just the code
on the line no . ?

On Thu 24 Jan, 2019, 6:42 PM Craig Carnell <[email protected] wrote:

Here is a patch for Magento 2.3.0:

PR-18471.zip
https://github.com/magento/magento2/files/2791807/PR-18471.zip

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/14952#issuecomment-457191280,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Adg8baJCghOKGQ8sSLnXJex1NBtpjsclks5vGbFGgaJpZM4TwYEs
.

Just the code that needs replacing, it's a diff

Here is a patch for Magento 2.3.0:

PR-18471.zip

I can confirm that it's working on Magento 2.3.0.

Just updated from 2.2.5 to 2.2.7 and the issue is still on, this need to be addressed and fixed ASAP, Team please help how to apply fix.

It will be probably in 2.2.8.

@DanielRuf When is a new release due?

It will be probably in 2.2.8.

But isn't that security concern which is directly displaying our VPS address, so the hackers can manipulate it and hack the VPS or emails address

But isn't that security concern which is directly displaying our VPS address, so the hackers can manipulate it and hack the VPS or emails address

Your answer does not make much sense to me.
You can apply the patch using composer-patches and there were also workarounds mentioned in the collapsed comments (setting the sender for the binary which sends the mails).

@terrybakshi also see #14952 (comment)

Fix: vendor/magento/module-sales/Model/Order/Email/SenderBuilder.php

replace

$this->transportBuilderByStore->setFromByStore(
    $this->identityContainer->getEmailIdentity(),
    $this->identityContainer->getStore()->getId()
);

with

$this->transportBuilder->setFrom(
    $this->identityContainer->getEmailIdentity(), 
    $this->identityContainer->getStore()->getId()
);

vendor/magento/framework/Mail/Template/TransportBuilder.php

replace

/**

  • Set mail from address
    *
  • @param string|array $from
  • @return $this
    */
    public function setFrom($from)
    {
    $result = $this->_senderResolver->resolve($from);
    $this->message->setFrom($result['email'], $result['name']);
    return $this;
    }
    with

/**

  • Set mail from address
    *
  • @param string|array $from
  • @return $this
    */
    public function setFrom($from, $store = null)
    {
    $result = $this->_senderResolver->resolve($from, $store);
    $this->message->setFrom($result['email'], $result['name']);
    return $this;
    }

This is what the linked patches already do ;-) It was already posted a few times before.

composer-patches is recommended, editing the core (manually) is highly discouraged and not recommended. Never touch core files. This is why we have patch.

This is what the linked patches already do ;-) It was already posted a few times before.

composer-patches is recommended, editing the core (manually) is highly discouraged and not recommended. Never touch core files. This is why we have patch.

can you please assist me in how to step by step apply patch as i am new so not sure how to do if you can tell me the commands would be much appreciated.

Thanks

Hi guys,

I figured before I go the patch route I'd give Terrybakshi's solution a try. Seemed easy enough.
But after backing up the two files and making the changes, I get the following error everywhere I go in the site including the admin module.

There has been an error processing your request
Exception printing is disabled by default for security reasons.
Error log record number: 376655659721

I restored the original files and everything worked again.
I tried the changes once more and started getting this fat one instead.

Fatal error: Uncaught Error: Call to undefined method MagentoFramework\Mail\Template\TransportBuilder\Interceptor::___init() in /home1/mysite/public_html/generated/code/Magento/Framework/Mail/Template/TransportBuilder/Interceptor.php:13 Stack trace: #0 /home1/mysite/public_html/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(111): MagentoFramework\Mail\Template\TransportBuilder\Interceptor->__construct(Object(MagentoFramework\Mail\TemplateFactory), Object(MagentoFramework\Mail\Message\Interceptor), Object(Magento\Email\Model\Template\SenderResolver), Object(MagentoFramework\App\ObjectManager), Object(MagentoFramework\Mail\TransportInterfaceFactory)) #1 /home1/mysite/public_html/vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(66): MagentoFramework\ObjectManagerFactory\AbstractFactory->createObject('Magento\Framewo...', Array) #2 /home1/mysite/public_html/vendor/magento/framework/ObjectManager/ObjectManager.php(70): MagentoFramework\ObjectManagerFactory\Dyn in /home1/mysite/public_html/generated/code/Magento/Framework/Mail/Template/TransportBuilder/Interceptor.php on line 13

Again, the problem seems to be here because if put the original 2.5 code back for this function only, keeping the changes in place for SenderBuilder.php, everything works again but no emails are sent of course.

public function setFrom($from, $store = null)
      {
      $result = $this->_senderResolver->resolve($from, $store);
      $this->message->setFrom($result['email'], $result['name']);
      return $this;
      }

I fear the patch will do the same thing if I run it. Any ideas?

@winstonojeda after adding the code did u run the commands
php bin/magento setup:upgrade

php bin/magento cache:clean

php bin/magento setup:di:compile

php bin/magento setup:static-content:deploy

No. I did not.

No. I did not.

so after adding code you have to run commands to get it working

Your stack trace is showing an interceptor problem. This is because you havent rerun php bin/magento setup:di:compile

Do this and then run the static deploy command after.

Great! I wasn't sure about that step. Thanks!

After applying patch #18471 on M2.3 we still get no valid From Name and also no valid To name.
So on transactional M2.3 emails both ->setFrom and AddTo only set emailaddress and not the Name part.
Has the way ->addTo($email,$customername) changed since 2.2.7 ( works there ) in 2.3 or after applying 18471 patch?

magento what's wrong with you? 9 months to fix such a simple bug

i try above all solution non of working for me, i am using magento 2.2.7
After apply patch i am not able to receive email

@ravinders-121

Thanks - I updated the package.

not working for me , if apply ur solution then stop email :(

@ravinders-121
Thanks - I updated the package.

not working for me , if apply ur solution then stop email :(

After adding the code did u run the commands

php bin/magento setup:upgrade

php bin/magento cache:clean

php bin/magento setup:di:compile

php bin/magento setup:static-content:deploy

yes i run all command

One more workaround suitable for any version. At least i have to use this in my current magento CE 2.3 configuration. Hope EE doing better. Apache config:

    <Directory /srv/www/site_name>
        php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -fsupport@site_name.com"
        ...
    </Directory>

This issue is still present in 2.2.8. I’ve updated from 2.2.7 with the PR-18472 patches applied, but when updating to 2.2.8 I was forced to uninstall them. After uninstalling the patches, confirmation emails were being sent from our server and not our store (as it was prior to patching 2.2.7).

18472 is scheduled for 2.2.9, so yes, this is still broken in 2.2.8. Reapply patches to 2.2.8.

Hi @gwharton,

Unfortunately I'm getting an error when trying to apply the same patch from 2.2.7 to 2.2.8. See error below:

`Could not apply patch! Skipping. The error was: Cannot apply patch patches/composer/PR-18472-Framework.diff

[Exception]
Cannot apply patch PR-18472: Alternative fix for Multi Store Emails issue,
Fix Async Emails issues, Fix Multiple Email issues (patches/composer/PR-184
72-Framework.diff)!
`

@pioneerathletics: can you try the following patches, I just created these by cherry-picking commit dbfeb36a1f95f45d19c9698f996a67a999f4ce4d into 2.2.8, so in theory this should work, but I haven't tested them so far:

PR-18472-for-Magento-2.2.8.zip

@hostep I will try these and let you know if they work. Thank you for the help.

Hi @tstamplis. Thank you for your report.
The issue has been fixed in #18472 by @gwharton in 2.2-develop branch
Related commit(s):

The fix will be available with the upcoming 2.2.9 release.

sir i was installed magento 2 ver. 2.2.6 and i solved my issue by deactivating all amazon module my (The order confirmation email is not sent) problem was fixed and working perfect but before some days i updated magento to 2.3.0 and i am again facing The order confirmation email is not sent) error i tried to deactivate amazon module but problem still not solved as you told problem `ll be fixed in magento 2.2.9 but i am still facing this in 2.2.3 please tell me another solution if you have .

It is fixed in 2.2.9 and 2.3.1. Disabling amazon module was a workaround that worked in some versions of 2.2. Recommend updating to 2.3.1.

I just want to provide some history for this bug:

Magento 2.2.4, (02.05.2018) : Bug firstly encountered, Bugfix provided by community.
Magento 2.2.5, (27.06.2018) : Bug still present
Magento 2.2.6, (18.09.2018) : Bug still present
Magento 2.2.7 (27.11.2018) : Bug still present
Magento 2.2.8 (26.03.2019) : Bug still present
Magento 2.2.9 ( ??? ) : Bug is scheduled for this release.

Looking at this history, i assume that 2.2.9 will not be released before May. And who knows if this bug would not be "resheduled" to another release.

To sum it up: It takes over one year and its still not merged into a current minor release.

A migration from 2.2.x into 2.3.x is from my perspective a huge workaround. It requires a lot of work, because not all the custom extension are compatible with 2.3. Its a workaround like: "Please buy a new car, because the ashtray needs to be emptied"

Can someone from Magento explain me why something like that happening? I understand that you need to deliver some new Features, but taking care about Bugs with over 215 Comments should also be a priority. At least once a year :)

I am not from Magento, but I can add these two comments.

It is now merged into 2.2-develop so will be in 2.2.9

It seems to me that magento are prioritising bugs for 2.3 over 2.2. This is the reason why it was merged into 2.3 some months back and has already been released in that branch, but is still lagging behind on 2.2. They put the 2.2 fix on hold until the 2.3 fix has been tested and released into the wild, then they 2.2 bugfix is followed up.

Sorry I can't shed any more light on this. It has been super frustrating on my part to get what should have been a simple fix, accepted into the core.

Hi @EliasKotlyar, not sure how this is currently helpful. This is a huge project and the team has to prioritize things. Normally fixed in current develop branch are cut into releases by the scheduled release scripts.

They put the 2.2 fix on hold until the 2.3 fix has been tested and released into the wild, then they 2.2 bugfix is followed up.

This is a true, however M2.3 was released on the same time as 2.2.7 - in November. The bugfix from the community was submitted on 08.05.2018 - long before any minor release for 2.2.

Hi @EliasKotlyar, not sure how this is currently helpful.

I am also not sure how to express my frustration without taking a rant. I have tried to make it as pragmatic as possible, and provided a brief history to sum everything up. Also i have tried to provide a solution for this problem.

This is a huge project and the team has to prioritize things.

.I suppose that everyone would understand, if someone from the core-team would write here from time to time, and say: "yeah, we are not taking this into the next minor release because we are under time pressure etc etc". Not communicating at all, is also a form of communication. And i know and appretiate that there were some comments like "thanks for contributing" etc, but everyone waits for a merge into a current minor version of 2.2. The development work has been done by the community already, it just needs to be merged and tested. If there is a lack resources on testing, its also something which can be communicated to everyone.

By adding the relevant PR's to release milestones, which you can see if you look at the PR's against each issue, you can see when they are scheduled for release. If there is a delay, the milestone is updated. This is only a recent change, so the Magento team ARE communicating the release schedule to you.

I share your frustration though. I have 11 PR's waiting to be merged across both 2.2 and 2.3 branches. Some have been open for over 6 months. To me and everyone else out there, nothing seems to happen for long periods of time, but I'm sure the issues are being regularly looked at.

If you go back 1 year from now, things seemed much quicker. 2.1, 2.2 and 2.3 PRs were being merged in parallel. Things got added much quicker. However I think things were being missed. I was certainly guilty of one of them, but things got committed without proper testing, and things got broke in release versions that never should have been released. I certainly detect an increase in the quality control and testing that is being performed today, and the amount of reviewing taking place. Unfortunately this increase in quality comes at a decrease in speed.

You say this issue was simple. It was far from it.

It was highlighted when the amazon module was updated, which caused the email from addresses to stop working. A workaround was to disable the amazon module. In the meantime, a fix was committed that fixed the underlying issue. Unfortunately the fix implemented was not a great one (in my opinion) and was implemented on 2.2 (which did fix things temporarily with some emails, but completely broke other email functions (multiple emails, cc's etc broke)) and the same broken fix was copied over to 2.3 (which caused the same problems in the release version of 2.3.0!!!). The proposed fix was to revert the changes made in the original poor fix and reimplement in a better way, but as the original fix had been released into the wild, this would have caused backwards compatability issues with the code and couldn't simply be reverted, so additional work was required so as to not break any existing installations. So the 2.3 code was eventually updated in a way acceptable to the Magento team, which then revealed that the rewrite of the Zend mail framework routines in 2.3 had further issues with the From addess routines (not present in 2.2). So these had to be addressed, and finally once the changes were brought together and approved in 2.3, they were backported into 2.2.

I didn't have to step in and do all of this work in preparing the fixes, responding to magento reviews, updating code etc. I don't work for Magento. But I felt I could contribute so stepped in. Like I say, I share your frustration in the time it took to get the fix in. Maybe if I hadn't picked this up and worked on it, someone within Magento may have picked it up and been able to get it through quicker. Who knows!

There isn't much more that I can say.

Hi Everybody,
I was in this task as well sometimes ago. Always looked at the comments and suggestions and patches and whatelse came out here.
As a matter of facts it is a shame for Magento not fixing such a relevant issue as fast as possible. Of course, it is a huge project, but it does not help if first other bugs are fixed before the essential stuff is working. And this is an essential functionality which have to work to use Magento as a shop beeing online !!!!!
Currently, I do not care about this issue, because I did the work updating to 2.3.1 already and got my extensions working. But do not know at the moment if it is working because of the core fix or because I disabled Amazon and Klarna login stuff.
So, it will still be interesting how long it takes till this issued will be closed.
Happy coding !
Jürgen

Not fixed in 2.2.8 - in 2.2.6 it was working I think

I say again. This fix is scheduled for 2.2.9. In the meantime manually apply #18472.

i am getting this issue on magento 2.2.5 version
please help
how to solve that issues ?
please.

@msawyers Thank you so much

I wonder why this issue is closed it's reproducible and has not been actually been fixed in any release.
Thanks to @sashas777, there is a fix https://github.com/sashas777/bug-from-email

But even with it there is no sender name in 2.2.8.

It is fixed in the develop branches.

@xpoback Just read 3 comments back from your comment. It is scheduled for release in 2.2.9.

@gwharton I've been reading comments here since the issue was created almost a year ago.

Magento closed this issue on Jan 7, long before 2.2.8 was released. The 2.2.8 in which the problem is present. So this is why _I wonder why_ (just as I wrote in my previous comment) they close issues, pronouncing them fixed without actually releasing the fix.

It is scheduled for release in 2.2.9.

There has been many fixes and PRs that had been merged to develop and _scheduled_ but didn't get released in the next version. So let's pray they really do it this time. And don't break anything else.

What i expect happens is that prior to a release a release branch is created where a line is drawn in the sand and the code scheduled for that release are fixed. This branch will go forward for extensive testing which may last for several weeks or months. During this time updates are still being made to the develop branch, but none of these changes will make it to the release. This explains why the issue was closed as fixed prior to 2.2.8 release but didnt make the 2.2.8 release.

Hi @gwharton ,

How can I apply the patch #18472, if I installed magento via composer. Is there any easy way to do? or do I have to change everything manually?

Hi @bnymn I'm sorry i can't help with applying patches via composer, as I run from git.

However, if you scroll up through previous comments there is a downloadable patch for 2.2.8 and also some instructions (somewhere) on how to apply these. Unfortunately I can't help with this further.

I look forward to the 2.2.9 release when this issue can finally be put behind us!!! :)

This bug still exists in 2.3.0.

@iKoala Yes, Scheduled for 2.3.1 See https://github.com/magento/magento2/pull/18471

@iKoala Yes, Scheduled for 2.3.1 See #18471

@gwharton Thanks for the reply. Is there any work around at the meantime?

I had the same problem until 2.2.8.
I did an update installing 2.3.1 from scratch, the problem has been solved.

fix ok only sales email, but not working in reset password or new customer or new user store

Please raise new issue to cover those bugs.

Has someone upgraded and verified if the error continues in version 2.2.9?

Yes, it continues and got worse on 2.3.1 and 2.3.2 @salelsol

https://github.com/magento/magento2/issues/14952#issuecomment-504406880

Please raise new issue to cover those bugs.

I upgraded a store from 2.2.7 to 2.2.9 and the issue is fixed for me.

  • It continues to work well and the emails are received correctly after upgraded to Magento 2.2.9 ??

Got this issue after upgrading from 2.2.5 to 2.2.9.

@mike-jianxin-mo it was working before and now you have the issue ? Maybe you should try to open a new issue ?

Guyz, applying the patch resolving the issue.

On Tue, 23 Jul, 2019, 12:46 PM Loïc HALL, notifications@github.com wrote:

@mike-jianxin-mo https://github.com/mike-jianxin-mo it was working
before and now you have the issue ? Maybe you should try to open a new
issue ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/14952?email_source=notifications&email_token=AHMDY3M4TCMSFU2IFUBL3NLQA2V37A5CNFSM4E6BQEWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2SE6XQ#issuecomment-514084702,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHMDY3LUHD5O3C53JIV7AEDQA2V37ANCNFSM4E6BQEWA
.

Hi,

I'm using Magento Ver. 2.3.0.
The order confirmation email is coming from a very strange email address.
I have updated all the store email address.
Please advise.

Thank you,
Raman

Hi @ramandhillon31,

Please check the latest releases for the patch.
Also see https://github.com/magento/magento2/issues/14952#issuecomment-492186332

@ramandhillon31

Fix will be in magento 2.3.3 version when it is released

Anyone have a solution for 2.3? I tried overwriting some of the files with ones from 2.3.3 but looks like only option is to upgrade, however that usually means incompatibility with some extensions.

Please check the .patch URL of the linked PR. You may have to scroll a bit up. You can apply it with composer-patches.

Still getting up to speed with M2 and Github, not sure where that is and what I'm looking for.

@maxq, a lot of useful comments were already posted above, but I get it that it takes a while to read through them, here are some highlights which might help you further:

For further questions or assistance about how to apply patches, you'd best switch over to https://magento.stackexchange.com/ or https://community.magento.com/

I ended up using the composer patch MDVA-10993_EE_2.2.4_v1.composer.patch from Magento.
It says it's works up to 2.3 (maybe) but it did work for our 2.3 installation.
Thanks

Guys I made quick extension and forced it to be used only on Magento 2.2.4 version assume that bugfix will be in the next release.
I tested and it works on my websites. I hope it can help you as well:
https://github.com/sashas777/bug-from-email

You can install it using composer and then remove when will be new Magento 2 release. If you will forget to remove then you will have version compatibility error with any other Magento 2 release.

Hi @hostep
This is not working for version 2.3.0... can you please help me to work for this version too?

@imebrijesh: if you are able to upgrade to a newer version of Magento, I would strongly recommend it, because this email bug is far from the only serious bug in version 2.3.0, later versions are a lot more stable (even though the still have other email bugs).

If you really need a patch, then I strongly recommend you learn how to create and apply patches, because you will need it a lot in this Magento universe where releases are only created every 3 months and every release contains new bugs.

If you have further questions, please refer to https://magento.stackexchange.com/ or https://community.magento.com/

Was this page helpful?
0 / 5 - 0 ratings