cancel
Showing results for 
Search instead for 
Did you mean: 

Backward-incompatible Changes in the Mail Library for Magento 2.3.3

melnikovi
Adobe Team

This post describes changes made to the Mail library in Magento 2.3.3 and explains the actions that merchants and extension developers need to take to ensure that extensions that use Mail library compatibility with these changes. 

 

Backward-incompatible Changes

The Magento\Email\Model\Transport class has been changed as follows:  

 

  • The type of the $message constructor parameter has been changed from Magento\Framework\Mail\MessageInterface to Magento\Framework\Mail\EmailMessageInterface 
  • The return type of the getMessage method has been changed from Magento\Framework\Mail\MessageInterface to Magento\Framework\Mail\EmailMessageInterface 

 

Recommendations for Merchants 

Merchants should apply the Mail library patch (available from Magento Tech Resources) as soon as possible, especially if their deployments include extensions or customizations that use the Mail library. 

 

This patch fixes the type of the constructor parameter, getMessage method return value and makes EmailMessageInterface extend MailMessageInterface. These changes will be included in Magento 2.3.4.

 

Recommendations for Extension Developers

Extension developers should both advise the merchants who use their extensions to apply the patch as well as update their extensions to be compatible with Magento 2.3.3 and 2.3.3 with the patch.

 

Extension developers should update their extensions to ensure compatibility with Magento 2.3.2, 2.3.3, and 2.3.4 (not yet released) by applying the following changes: 

 

Usage scenarioA custom class inherits from

Magento\Framework\Mail\Template\TransportBuilder  and relies on the protected $message property. 

Solution: Useinstanceof  to determinewhich class is sending $messagebefore using this property. 

 

if ($message instanceof \Magento\Framework\Mail\MessageInterface) {
    // Keep existing behavior here 
} else { 
    // Introduce new behavior here 
} 

 

Usage scenario: The use of MessageInterface in a method signature. 

Solution: Loosen typing by removing  MessageInterface from the method signature and instead use instanceof check. 

 

Usage scenario:  Any plugin for Magento\Framework\Mail\TransportInterface  that uses$subject->getMessage(). 

Solution: Useinstanceof to determinewhich class is sending $messagebefore using this property.

 

Usage scenario: Any client code that usesMagento\Framework\Mail\TransportInterface::getMessage() will now get an instance of EmailMessageInterface instead of MessageInterface. 

Solution: Useinstanceof to determinewhich class is sending $messagebefore using this property. 

 

Usage scenario: Instantiation of Magento\Email\Model\Transport using factory now requires message argument to implement the new EmailMessageInterface. 

Solution:  UseMagento\Framework\Mail\Template\TransportBuilder instead. 

 

Usage scenario: Calling getBody/getMessageBody on  EmailMessageInterface.

Solution: Use instanceof MessageInterface on $message. If $message is an instance of MessageInterface, call getMessageBody. Otherwice call getBody. 

 

Additional Notes

  • MailMessageInterface and Magento\Framework\Mail\Message have been deprecated.
  • EmailMessageInterface temporarily extends MailMessageInterface, but methods that belong to MailMessageInterface may be removed in Magento 2.4.
  • We recommend not to use deprecated methods and use only methods of EmailMessageInterface itself (not inherited methods) to have extensions aligned with changes that may be done in Magento 2.4.
39 Comments
direct_coins
Senior Member

Hello,

We have applied the patch and unfortunately we still get the following:

 

Warning: Declaration of Magento\Newsletter\Model\Queue\TransportBuilder::se
tFrom($from) should be compatible with Magento\Framework\Mail\Template\Tran
sportBuilder::setFrom($from, $store = NULL) in /vendor/magento/module-newsletter/Model/Queue/TransportBuilder.php on
line 29

bcerban
M1 Certified

Hi,

Type checking should not be the solution here. 

This is a huge mess. It's not the first time it happens. 

This change should not have been added to a patch release. 

And this is disrespectful to everyone who lost hours of work trying to extend, fix, and/or workaround Magento's very limited email functionality. 

 

 

melnikovi
Adobe Team

@direct_coins based on the warning it seems that you are applying patch not on 2.3.3. This patch is for 2.3.3 only.

direct_coins
Senior Member

We have upgraded to 2.3.3 on our staging site and the reason we applied the patch is due to the issue. 2.3.2 does not have this issue and is working fine. 

 

We have disabled all 3rd party extensions but the error is still present.

 

Not sure where to go from here. 

AndyAJ
Contributor

I tried downloading the patch

EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-14-03-43-31.patch

...and putting it into my root folder and running the patch command...but it does not work and errors out.

 

patch < EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-14-03-43-31.patch

results in

 

can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/vendor/magento/module-email/Model/Transport.php b/vendor/magento/module-email/Model/Transport.php
|index cbce1682cb5..79ceb56a883 100644
|--- a/vendor/magento/module-email/Model/Transport.php
|+++ b/vendor/magento/module-email/Model/Transport.php
--------------------------

 I'll just copy files from github for now...seems easier and more straightforward than the patching.

melnikovi
Adobe Team

@direct_coins trying to understand why do you get this error. Magento\Framework\Mail\Template\Tran
sportBuilder::setFrom in 2.3.3 has a different signuture. Could you please try on clean installation of 2.3.3?

abscom
Senior Member

@AndyAJ did the patch process promp for "File to patch:" when you ran this?

 

For some reason you have to specify the location of each file in the patch file, despite it being the same path as what is in the patch file. You can just copy paste them in to the interactive patch prompt. See the blue box in the devdocs section:

 

https://devdocs.magento.com/guides/v2.3/comp-mgr/patching.html#command-line

AndyAJ
Contributor

@abscomYes it did prompt me. but i just ended up cancelling the script and assumed it wasnt working correctly....so I went and grabbed files off the 2.3-develop branch on Github.

abscom
Senior Member

Yea this patching process is not great.

 

Even using the Composer method you have to modify the .patch file provided (in this case splitting out to 2 seperate files, one for module-framework, one for module-email).

 

It is certainly not a clean process either way of applying the patch. 

 

Seems this process has come about due to Magento not using semantic versioning. These patches should be patch releases not patch files. Whoever decided the versioning strategy for M2 got it wrong by always keeping "2" at the start. This "2" should be the 'major' version number, incrementing when a breaking change is included (think 2.2.x -> 2.3.x currently). That then leaves the 'minor' version number for non breaking changes such as new features and bug fixes (think 2.3.2 -> 2.3.3 currently). The 'patch' version number is then available for patches such as this email issue to be quickly released as part of the release schedule without convoluted patching strategies.

 

I feel it's not too late to switch to semantic versioning even now. If the version must begin with "2" for some branding reason then make the next release "2.3.4.0", so that we at least then have the ".0" patch version for what is really the 3.4.x release.

bart_cz
Senior Member

@abscomi was thinking about official patch 'EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-14-03-43-31.patch' and how to use it with composer. You suggested that this patch should be splitted to two seperately files: one for module-framework, one for module-email. And what about code that concerns location 'dev/tests/integration/testsuite/Magento/*' in official patch?. How to apply these changes to my repository?

abscom
Senior Member

Hi @bart_cz , yes correct it is actually 3 seperate files I just removed the integration tests from the patch for now. I have successfully applied the patch as follows:

composer.json

 

... 
"extra": {
        "magento-force": "override",
        "patches": {
            "magento/module-email": {
                "2.3.3 EmailMessageInterface backward compatibility issue patch": "patches/EmailMessageInterface_2.3.3_backward_compatibility_module-email.patch"
            },
            "magento/framework": {
                "2.3.3 EmailMessageInterface backward compatibility issue patch": "patches/EmailMessageInterface_2.3.3_backward_compatibility_framework.patch"
            }
        }
    },
...

patches/EmailMessageInterface_2.3.3_backward_compatibility_framework.patch

diff --git a/Mail/EmailMessage.php b/Mail/EmailMessage.php
index aaef9750751..02c75977cd0 100644
--- a/Mail/EmailMessage.php
+++ b/Mail/EmailMessage.php
@@ -10,19 +10,13 @@ namespace Magento\Framework\Mail;
 use Magento\Framework\Mail\Exception\InvalidArgumentException;
 use Zend\Mail\Address as ZendAddress;
 use Zend\Mail\AddressList;
-use Zend\Mail\Message as ZendMessage;
 use Zend\Mime\Message as ZendMimeMessage;
 
 /**
- * Class EmailMessage
+ * Email message
  */
-class EmailMessage implements EmailMessageInterface
+class EmailMessage extends Message implements EmailMessageInterface
 {
-    /**
-     * @var ZendMessage
-     */
-    private $message;
-
     /**
      * @var MimeMessageInterfaceFactory
      */
@@ -64,38 +58,35 @@ class EmailMessage implements EmailMessageInterface
         ?array $replyTo = null,
         ?Address $sender = null,
         ?string $subject = '',
-        ?string $encoding = ''
+        ?string $encoding = 'utf-8'
     ) {
-        $this->message = new ZendMessage();
+        parent::__construct($encoding);
         $mimeMessage = new ZendMimeMessage();
         $mimeMessage->setParts($body->getParts());
-        $this->message->setBody($mimeMessage);
-        if ($encoding) {
-            $this->message->setEncoding($encoding);
-        }
+        $this->zendMessage->setBody($mimeMessage);
         if ($subject) {
-            $this->message->setSubject($subject);
+            $this->zendMessage->setSubject($subject);
         }
         if ($sender) {
-            $this->message->setSender($sender->getEmail(), $sender->getName());
+            $this->zendMessage->setSender($sender->getEmail(), $sender->getName());
         }
         if (count($to) < 1) {
             throw new InvalidArgumentException('Email message must have at list one addressee');
         }
         if ($to) {
-            $this->message->setTo($this->convertAddressArrayToAddressList($to));
+            $this->zendMessage->setTo($this->convertAddressArrayToAddressList($to));
         }
         if ($replyTo) {
-            $this->message->setReplyTo($this->convertAddressArrayToAddressList($replyTo));
+            $this->zendMessage->setReplyTo($this->convertAddressArrayToAddressList($replyTo));
         }
         if ($from) {
-            $this->message->setFrom($this->convertAddressArrayToAddressList($from));
+            $this->zendMessage->setFrom($this->convertAddressArrayToAddressList($from));
         }
         if ($cc) {
-            $this->message->setCc($this->convertAddressArrayToAddressList($cc));
+            $this->zendMessage->setCc($this->convertAddressArrayToAddressList($cc));
         }
         if ($bcc) {
-            $this->message->setBcc($this->convertAddressArrayToAddressList($bcc));
+            $this->zendMessage->setBcc($this->convertAddressArrayToAddressList($bcc));
         }
         $this->mimeMessageFactory = $mimeMessageFactory;
         $this->addressFactory = $addressFactory;
@@ -106,7 +97,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getEncoding(): string
     {
-        return $this->message->getEncoding();
+        return $this->zendMessage->getEncoding();
     }
 
     /**
@@ -114,7 +105,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getHeaders(): array
     {
-        return $this->message->getHeaders()->toArray();
+        return $this->zendMessage->getHeaders()->toArray();
     }
 
     /**
@@ -122,7 +113,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getFrom(): ?array
     {
-        return $this->convertAddressListToAddressArray($this->message->getFrom());
+        return $this->convertAddressListToAddressArray($this->zendMessage->getFrom());
     }
 
     /**
@@ -130,7 +121,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getTo(): array
     {
-        return $this->convertAddressListToAddressArray($this->message->getTo());
+        return $this->convertAddressListToAddressArray($this->zendMessage->getTo());
     }
 
     /**
@@ -138,7 +129,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getCc(): ?array
     {
-        return $this->convertAddressListToAddressArray($this->message->getCc());
+        return $this->convertAddressListToAddressArray($this->zendMessage->getCc());
     }
 
     /**
@@ -146,7 +137,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getBcc(): ?array
     {
-        return $this->convertAddressListToAddressArray($this->message->getBcc());
+        return $this->convertAddressListToAddressArray($this->zendMessage->getBcc());
     }
 
     /**
@@ -154,7 +145,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getReplyTo(): ?array
     {
-        return $this->convertAddressListToAddressArray($this->message->getReplyTo());
+        return $this->convertAddressListToAddressArray($this->zendMessage->getReplyTo());
     }
 
     /**
@@ -163,7 +154,7 @@ class EmailMessage implements EmailMessageInterface
     public function getSender(): ?Address
     {
         /** @var ZendAddress $zendSender */
-        if (!$zendSender = $this->message->getSender()) {
+        if (!$zendSender = $this->zendMessage->getSender()) {
             return null;
         }
 
@@ -178,18 +169,10 @@ class EmailMessage implements EmailMessageInterface
     /**
      * @inheritDoc
      */
-    public function getSubject(): ?string
-    {
-        return $this->message->getSubject();
-    }
-
-    /**
-     * @inheritDoc
-     */
-    public function getBody(): MimeMessageInterface
+    public function getMessageBody(): MimeMessageInterface
     {
         return $this->mimeMessageFactory->create(
-            ['parts' => $this->message->getBody()->getParts()]
+            ['parts' => $this->zendMessage->getBody()->getParts()]
         );
     }
 
@@ -198,15 +181,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function getBodyText(): string
     {
-        return $this->message->getBodyText();
-    }
-
-    /**
-     * @inheritdoc
-     */
-    public function getRawMessage(): string
-    {
-        return $this->toString();
+        return $this->zendMessage->getBodyText();
     }
 
     /**
@@ -214,7 +189,7 @@ class EmailMessage implements EmailMessageInterface
      */
     public function toString(): string
     {
-        return $this->message->toString();
+        return $this->zendMessage->toString();
     }
 
     /**
diff --git a/Mail/EmailMessageInterface.php b/Mail/EmailMessageInterface.php
index 95f83ff679c..93eaa4acde3 100644
--- a/Mail/EmailMessageInterface.php
+++ b/Mail/EmailMessageInterface.php
@@ -9,7 +9,7 @@ namespace Magento\Framework\Mail;
 /**
  * Interface EmailMessageInterface
  */
-interface EmailMessageInterface
+interface EmailMessageInterface extends MailMessageInterface
 {
     /**
      * Get the message encoding
@@ -72,14 +72,14 @@ interface EmailMessageInterface
      *
      * @return null|string
      */
-    public function getSubject(): ?string;
+    public function getSubject();
 
     /**
      * Return the currently set message body
      *
      * @return MimeMessageInterface
      */
-    public function getBody(): MimeMessageInterface;
+    public function getMessageBody(): MimeMessageInterface;
 
     /**
      * Get the string-serialized message body text
diff --git a/Mail/MailMessageInterface.php b/Mail/MailMessageInterface.php
index da010be2702..5179e6057c4 100644
--- a/Mail/MailMessageInterface.php
+++ b/Mail/MailMessageInterface.php
@@ -10,6 +10,8 @@ namespace Magento\Framework\Mail;
  *
  * @api
  * @since 101.0.8
+ * @deprecated
+ * @see \Magento\Framework\Mail\EmailMessageInterface
  */
 interface MailMessageInterface extends MessageInterface
 {
diff --git a/Mail/Message.php b/Mail/Message.php
index b15b75ca9ac..1f423e80108 100644
--- a/Mail/Message.php
+++ b/Mail/Message.php
@@ -10,13 +10,16 @@ use Zend\Mime\Part;
 
 /**
  * Class Message for email transportation
+ *
+ * @deprecated
+ * @see \Magento\Framework\Mail\EmailMessage
  */
 class Message implements MailMessageInterface
 {
     /**
      * @var \Zend\Mail\Message
      */
-    private $zendMessage;
+    protected $zendMessage;
 
     /**
      * Message type
diff --git a/Mail/Template/TransportBuilder.php b/Mail/Template/TransportBuilder.php
index 4a8d6572faa..2d28e2f560a 100644
--- a/Mail/Template/TransportBuilder.php
+++ b/Mail/Template/TransportBuilder.php
@@ -87,7 +87,7 @@ class TransportBuilder
     /**
      * Message
      *
-     * @var EmailMessageInterface
+     * @var MessageInterface
      */
     protected $message;
 

 

patches/EmailMessageInterface_2.3.3_backward_compatibility_module-email.patch

 

diff --git a/Model/Transport.php b/Model/Transport.php
index cbce1682cb5..79ceb56a883 100644
--- a/Model/Transport.php
+++ b/Model/Transport.php
@@ -9,7 +9,6 @@ namespace Magento\Email\Model;
 
 use Magento\Framework\App\Config\ScopeConfigInterface;
 use Magento\Framework\Exception\MailException;
-use Magento\Framework\Mail\EmailMessageInterface;
 use Magento\Framework\Mail\MessageInterface;
 use Magento\Framework\Mail\TransportInterface;
 use Magento\Framework\Phrase;
@@ -62,12 +61,12 @@ class Transport implements TransportInterface
     private $message;
 
     /**
-     * @param EmailMessageInterface $message Email message object
+     * @param MessageInterface $message Email message object
      * @param ScopeConfigInterface $scopeConfig Core store config
      * @param null|string|array|\Traversable $parameters Config options for sendmail parameters
      */
     public function __construct(
-        EmailMessageInterface $message,
+        MessageInterface $message,
         ScopeConfigInterface $scopeConfig,
         $parameters = null
     ) {

 

Ensure you have added the Cweagans dependency for applying patches before runnijng `composer update` to apply them:

 

composer require cweagans/composer-patches
composer update

I'd then suggest committing the composer.json, composer.lock and patches directory in a single commit, referencing the full patch filename (so you can keep track should Magento release subsequent patches for the patches etc as has happened before).

 

I've written a post about applying patches here (in the context of the Elasticsearch hotfix also released for 2.3.3):


https://absolutecommerce.co.uk/blog/fix-elasticsearch-bug-magento-2?utm_source=community_magento_com... 

 

melnikovi
Adobe Team

@AndyAJ@abscom@bart_cz try applying patch as follows

patch -p1 < EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-14-03-43-31.patch

 

It should give the following output

patching file vendor/magento/module-email/Model/Transport.php

patching file dev/tests/integration/testsuite/Magento/Customer/Controller/AccountTest.php

patching file dev/tests/integration/testsuite/Magento/Framework/Mail/EmailMessageTest.php

patching file vendor/magento/framework/Mail/EmailMessage.php

patching file vendor/magento/framework/Mail/EmailMessageInterface.php

patching file vendor/magento/framework/Mail/MailMessageInterface.php

patching file vendor/magento/framework/Mail/Message.php

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

Hunk #1 succeeded at 88 (offset 1 line).

 

Message "Hunk #1 succeeded at 88 (offset 1 line)" means that the content of one of the files is different from what patch expects, but the patch was applied correctly. We are going to update the patch soon and replace it. In the meantime, you can use existing patch, just ignore this message.

 

Let me know if you still have issues applying the patch.

AndyAJ
Contributor

@melnikoviI hadn't tried that parameter because the documentation for applying the patch has the following...so I put '<' and not '-p1'... https://devdocs.magento.com/guides/v2.3/comp-mgr/patching.html#command-line

 

Command line

  1. Upload the local file into the <Magento_root> on the server using FTP, SFTP, SSH or your normal transport method.
  2. Login to the server as the Magento admin user and verify the file is in the correct directory.
  3. In the command line interface, run the following commands according to the patch extension:

    patch < patch_file_name.patch
melnikovi
Adobe Team

@abscom I wanted to clarify that semantic versioning strategy is not the reason of why this fix was released as a patch and how we do versioning.

 

What you are referring to is a product version, it doesn't follow semantic versioning. Patch version (2.3.1,2.3.2, etc) means that release contains bug fixes and in most cases doesn't contain features. Minor version (2.2.0, 2.3.0) means that release contains both features and bug fixes. Major version (2.0.0, 3.0.0) would probably mean that it's completely different platform, we don't have plans on changing this version yet.

 

Product consists of modules that also have versions. Module versions follow semantic versioning. In the patch product releases we try not to release backwards incompatible changes (don't make changes that require minor or major version bump of the module version), but versioning strategy allows it. But it sometimes necessary, for example, for security reasons. Please see more on this topic here.

melnikovi
Adobe Team

@AndyAJ seems that we don’t have consistency in how we generate patches and recommend applying them. Method below should work for you and, I believe, the most straightforward

patch -p1 < EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-14-03-43-31.patch

direct_coins
Senior Member

 

We have successfully applied the patch however we still get the same error when we run compile.

 

Warning: Declaration of Magento\Newsletter\Model\Queue\TransportBuilder::se
tFrom($from) should be compatible with Magento\Framework\Mail\Template\Tran
sportBuilder::setFrom($from, $store = NULL) in /public_html/s
taging/vendor/magento/module-newsletter/Model/Queue/TransportBuilder.php on
line 29

 

I have disabled all 3rd part extensions yet the error still appears.

 

Line 29 class TransportBuilder extends \Magento\Framework\Mail\Template\TransportBuilder

 

Cannot upgrade until we resolve this issue.

secaliskan
New Contributor

hi @direct_coins @melnikovi 

Just upgraded from 2.3.2 to 2.3.3 via composer. Upgrade and database upgrade is successfull.

Now I'm having the same issue, despite applying the patch successfull, still I can not go for production mode.

When I try 

bin/magento s:d:c

I'm getting declaration error below and compile broken at 1/7

Warning: Declaration of Magento\Newsletter\Model\Queue\TransportBuilder::setFrom($from) should be compatible with 
Magento\Framework\Mail\Template\TransportBuilder::setFrom($from, $store = NULL)
in .../vendor/magento/module-newsletter/Model/Queue/TransportBuilder.php on line 29

 

This is 10 years live site. Someone advised to use clean install of 2.3.3, how we can do this?

Even some portion of DB is coming from Magento 1.9 to 2 migration...

 

Styucked there, problem with setFrom funciton incompatibility...

 

Please give hand on this...

 

melnikovi
Adobe Team

@direct_coins@secaliskan please see my comment above. Magento 2.3.3 contains different code. My suspission is that you are installing patch not on 2.3.3.

direct_coins
Senior Member

Hi @melnikovi 

 

I can confirm 100% we have upgraed to 2.3.3 through composer. The admin also states 2.3.3.

 

Dont know how to get around this issue and cannot upgrade due to this, as per secaliskan

secaliskan
New Contributor

@melnikovi @direct_coins 

Yes we have upgraded Magento 2.3.3, and we try to make compile...

I have many client systems and one other system I just upgraded to 2.3.3 and switched to production mode w/o problem.(compile worked as expected)

Seems there's an extension creating problem.

@direct_coins are you using Mageplaza SMTP? it may cause the problem... We have a common extension which causes the case...

melnikovi
Adobe Team

@direct_coins@secaliskan have you tried installing patch on clean installation of Magento 2.3.3? Does it work for you? I'm not sure why are you getting this warning as Magento\Framework\Mail\Template\TransportBuilder::setFrom in 2.3.3 has a different signuture. Could you reach out to me at melnykov@adobe.com, so I can help you troubleshoot this issue?

DominicW
Occasional Contributor

I've tried applying this patch on clean 2.3.3 zip download from magento site with no modifications and seeing patch error.

 

https://magento.stackexchange.com/q/294379/70343

 

I've used composer method so can track change and roll same fix out to other sites.

 

That should work though right?

 

 

abscom
Senior Member

Hi @DominicW , to apply the patch via Composer you'll need to modify the patch file unfortunately. 

 

See my comment above: https://community.magento.com/t5/Magento-DevBlog/Backward-incompatible-Changes-in-the-Mail-Library-f...

abscom
Senior Member

Thanks for confirming the release strategy @melnikovi . However I am still confused why this bug in particular was given a hotfix patch release. For example, why does this issue https://github.com/magento/magento2/issues/25099 not get a hotfix patch? I've seen it cause major problems on client's sites and would consider it critical. I'm sure there are many other similar examples.

As you said "Patch version (2.3.1,2.3.2, etc) means that release contains bug fixes and in most cases doesn't contain features". So, in my eyes and in the eyes of every merchant I've worked with who's had to battle against Magento patching strategies in the past, there should be a 2.3.4 release with just this fix in it right? I can appreicate why other issues that are fixed in the develop branch have to wait, but as this is issue is clearly verified and released as a patch it should get a patch point release of its own. Again for me it comes back to choosing to restrict yourself to a version number of only two numbers due to locking the major release at "2", whatever the rationale.

Also, I would hope everyone would agree that a patch version should NEVER contain features, by definition.

Roger
Regular Visitor
Running 2.3.3 and trying to apply this patch but currently dead tired so don't know why I don't succeed with applying it. Any hint would be appreciated. elasticsearch-pagination.patch ran fine. https://i.imgur.com/f0mlTcN.png
Roger
Regular Visitor
yes, was tired. Tried to patch it with the github, should have used composer.
Igor Ludgero
M2 Certified

I was having same issue on 2.3.2-p2 but it was related to a 3rd party module.

swhall
New Contributor

The website is Magento v2.3.3 - we are currently having issues with installing the EmailMessageInterface patch.

The full command tried was;

patch -p1 < EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-30-10-20-09.patch

 

The command returns the following error and prompts us for the “File to patch” every time.

                                                                                                                     

===========

[public_html]$ patch -p1 < EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-30-10-20-09.patch

can't find file to patch at input line 5

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|diff --git a/vendor/magento/module-email/Model/Transport.php b/vendor/magento/module-email/Model/Transport.php

|index cbce1682cb5..79ceb56a883 100644

|--- a/vendor/magento/module-email/Model/Transport.php

|+++ b/vendor/magento/module-email/Model/Transport.php

--------------------------

File to patch:

===========

 

We've tried entering several different file paths and file names when the prompt occurs based on previous forum messages. None have allowed us to finalize the patch. Any help or direction would be greatly appreciated.

Thank you,

Spencer

melnikovi
Adobe Team

@swhall are you applying patch on composer installation of 2.3.3?

directco
Senior Member

@melnikovi  We have updated to magento 2.3.3 via composer, applied patch succesfully trhough composer, but we cannot get past this error:

 

Warning: Declaration of Magento\Newsletter\Model\Queue\TransportBuilder::setFrom($from) should be compatible with Magento\Framework\Mail\Template\TransportBuilder::setFrom($from, $store = NULL) in /vendor/magento/module-newsletter/Model/Queue/TransportBuilder.php on line 29

 

 Tried everything including disabling all extensions, the issue still occurs. I am reading other forums of similar issues.

 

Is there a known issue with this? Need to updgrade to 2.3.3 on our live site but cannot as compile does not complete.

 

goutammagento
Senior Member

Hello,

 

After applying EmailMessageInterface_2.3.3_backward_compatibility_composer-2019-10-30-10-20-09.patch in Magento 2.3.3, getting below error in log files.

 

main.CRITICAL: Type Error occurred when creating object: Magento\Framework\Mail\EmailMessage, Argument 2 passed to Magento\Framework\Mail\EmailMessage::__construct() must be of the type array, null given, called in /var/www/html/m233/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php on line 116 [] []

 

Please advise

Johan
New Contributor

It is terrible to see how bad the QA of Magento 2 is.


No solutions provided, SMTP extensions still do not work with 2.3.3 for over a month.

 

Thanks for destroying our stores.

Johan
New Contributor

Where is the fix for =0A= =0A=0A=0A=0A=0A in emails?


I spent about 35 working hours trying to fix this emailing issue.

 

sissico
Senior Member

this fix is so critical, should be a better system to fix it that applying a patch

BotigaPallars
New Contributor

Hello,

 

after upgrade to 2.3.4, order E-mail still not sending… anyone tried it?


thanks in advance,

Miquel.

 

goutammagento
Senior Member
Are you using any SMTPserver?. There is one free extension of Mageplaza.
Install this Mageplaza_Smtp. Put your smtp details and try.
Eric Cavalcanti
M1 Certified

Is anyone still having issues with AWS SES?
Getting this:

smtpmsg='554 Transaction failed: Expected disposition, got =' errormsg='the server did not accept the mail'

Using Magento Commerce 2.3.4. I saw there is a blog post and a patch for 2.3.3.
We are using SMTP relay on mstmp.

PHP mail() works just fine, but Magento contact and sales still not working.

BotigaPallars
New Contributor
Hello @goutammagento, I'm using Postfix and all mails in server are running fine, but since 2.3.3 order sale confirmation is not working...
Kroellie
New Contributor

Also had the

554 Transaction failed: Expected disposition, got =

error here using AWS SES and Magento 2.3.4. Solved it with: https://github.com/magento/magento2/commit/6976aabdfdab91a9d06e412c2ed619538ed034b6