Confirmation emails have no FROM or FROM email address 2.2.4

[tstamplis]

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.

[SamB-GB]

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

[kervin]

Yes mail is ok when Amazon Payment is disabled.

[ghost]

We confirmed this with upgrade from 2.2.3 to 2.2.5

[DanielRuf]

So can we close this issue then?

[gwharton]

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.

[rishabhchd19]

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

[gwharton]

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.

[DanielRuf]

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

Ok.

[ghost]

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

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

[DanielRuf]

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.

[sashas777]

@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

[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.

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

[DanielRuf]

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.

[DanielRuf]

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.

[chequille]

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

[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?

[DanielRuf]

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).

[DanielRuf]

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.

[DanielRuf]

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.

[SamB-GB]

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.

[DanielRuf]

area not set when changing template

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

[SamB-GB]

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

[chequille]

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

[DanielRuf]

@chequille

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

Thirdparty code.

[sashas777]

@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.

[kervin]

It is the same for EE.

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

[JosiahCarberry]

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

[paul-blundell]

@DanielRuf

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

Thirdparty code.

That Magento forced upon us.

[SamB-GB]

@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": "" }

[chequille]

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

[DanielRuf]

@chequille which composer version do you use?

[chequille]

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

[DanielRuf]

No I mean composer --version.

[chequille]

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"

[JeroenBoersma]

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.

[ralfblask]

bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment

solved that problem for me

Magento 2 2.2.5

Thanks to @JosiahCarberry

[LiamKarlMitchell]

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

[profiVideos]

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

[chris-pook]

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?

[gwharton]

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.

[hostep]

@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.

[IIxauII]

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

[chris-pook]

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.

[ankit1388]

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() // ); }

[DanielRuf]

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

[hanhpv]

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

[ramindas]

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...

[ankit1388]

@DanielRuf I accept your answer. thanks

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

[gwharton]

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

[DanielRuf]

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.