SMTP connection has timed out

SMTP connection has timed out issue has started causing problems with our newly version upgraded project. For our case, it was originally just silently falling back to Sendgrid so our testers team did not manage to pick out.

These are the different errors have you might have been seeing.

smtp.mailgun.org has timed out
smtp.eu.mailgun.org has timed out
r3-smtp.dotdigital.com has timed out

These errors are caused by an update from Laminas 2.14.1 to 2.14.2 (and possibly some 2.15.x) versions. Laminas has provided a fix at 2.14.3 and the latest version of 2.15.x to patch this issue, and more information can be read from some of the Github ticket here #167, #168 and #170.

 

Problems?

1. Checkout issues causing duplicated order

Due to the timeout, emails got caught into exception error which caused the customer to pay for it repeatedly. Repeated payment has resulted into “duplicated” orders as customer will not notice that card has been charged due to the error notice.

2. GA issues

Due to exception error, customer will not get redirected to Success Page, which has resulted into all Enhanced Ecommerce not being tracked. GA will have 0 conversion due to this loading error which will never bring customer to the success page.

 

Solutions?

1. Upgrade Laminas Mail to the latest version (if you’re able to)

Laminas has already provided at update from 2.14.2 onwards, and the latest version of 2.15.x.

2. Use .patch file to patch directly (if you are wary due to your project Production status)

As per comment in #168, patch line 293 of Laminas Mail’s Abstract Protocol file.

laminas/laminas-mail/src/Protocol/AbstractProtocol.php

       if (isset($info['timed_out']) && $info['timed_out']) {

For those in Magento Commerce Cloud, you can easily drop the patch file into /m2-hotfixes/ folder, and Cloud will automatically patch it during their CI/CD deployment.

Patch File: laminas-mail-2-14-1.patch

 

Do share below if you have encountered more issues with the recent upgrades! Read more on Session size exceeded allowed session max size – Magento 2 which looks to have caused quite a bit of issues given the amount of views I have seen on the post! 

Problem with Temporarily allowed to save HTML value warning?

Encountering errors such as “Temporarily allowed to save HTML value that contains restricted elements” after Version Upgrade? There are a few ways to workaround, or fix this issue. It’s not exactly an “issue” per se, but the warning can be glaring if we don’t know what it means.

Temporarily allowed to save HTML value that contains restricted elements. Allowed HTML attributes for tag "a" are: class,width,height,style,alt,title,border,id,data-content-type,data-appearance,data-element,data-enable-parallax,data-parallax-speed,data-background-images,data-background-type,data-video-loop,data-video-play-only-visible,data-video-lazy-load,data-video-fallback-src,data-grid-size,data-active-tab,role,href,data-tab-name,data-same-width,target,data-link-type,data-show-button,data-show-overlay,data-overlay-color,data-autoplay,data-autoplay-speed,data-fade,data-infinite-loop,data-show-arrows,data-show-dots,data-slide-name,data-show-controls,data-locations,data-video-src,data-video-overlay-color

 

On a high level, this error does not have any bad effect as it is just a warning that such content will likely be deprecated some point in the future. If you do take a closer look at the error message, it will point out more information on what may have caused the warning. 

Allowed HTML attributes for tag "a"

 

Digging deeper, the <a> tag in the product content has issue with fulfilling what the newer version of Magento requires. Most of the time this content falls under Description, Short Description, or attributes where Page Builder and WYSIWYG are used. For our case, it fell into the Page Builder of Description where using the Link functionality in the WYSIWYG widget. It has created a rel=”” attribute which is not accepted after version upgrade, specifically when choosing “New Window”.

 

Solution?

There is no 1 recommended solution for this “Temporarily allowed to save HTML value” error as it depends on the nature of the project. The tags and attributes in question will also need to be studied on their importance.

1. Change the content to fit

Identify the tag or attribute causing the issue and update the content so that the warning does not show up. Pay attention to what tag or attribute can be used, and removed or replaced whenever possible.

2. Reduce the use of WYSIWYG

This may be a weird suggestion but some attributes are included through the widget and it is not something you can just hijack away. If you hit an error like this project did, changing the content will not work because the rel=”” attribute is added through the WYSIWYG widget.

 

After Note

Currently patched versions of Magento (2.4.3, 2.4.2-p2 and 2.3.7-p1) are expected to see errors like this due to a config that was introduced.

vendor/magento/module-cms/Model/Wysiwyg/Validator.php

cms/wysiwyg/force_valid

vendor/magento/module-cms/etc/config.xml

This value is by default set to false (for the time being) so it will just be a suggested “warning”. However given the lack of option for Admin to change this at the Admin Panel, it is suspected that eventually Magento could default this to a true due to security concerns.

Under CLI, this value can be changed using the command below.

bin/magento cms:wysiwyg:restrict <restrict>

y – This will force strict validation
n – This will remain as current “suggested” warning setup (default)

Ref: https://devdocs.magento.com/guides/v2.4/reference/cli/magento-commerce.html#cmswysiwygrestrict

 

Have you been doing version upgrade for Magento lately? Read more into session max size issue that was encountered during one of the Version Upgrade sessions!

Are you suddenly seeing a number of silent errors “Session size exceeded allowed session max size” on your log files (system.log/support_report.log) recently?

A series of version upgrades has been ongoing for the past 2 months due to the serious security warning from Adobe back in Aug 11, 2021 where “successful exploitation could lead to arbitrary code execution.”

Major version upgrades for our projects to 2.4.x were in the pipeline, however the security warning has caught us by surprise given that it was a priority 2 threat.

Since then, a couple of projects with older versions of Magento 2.3.x have actively upgraded to 2.3.7-p1 where security patches have been introduced for the 2.3.x versions. 

While upgrading, one of the common issues we have encountered is Session Size that came out of no where. Errors such as “Session size exceeded allowed session max size” have been noted for the past few days for our projects, and it was quite a silent error if developer has not been looking into the system.log or support_report.log files.

This error eventually surfaced due to a 500 error which happened when we were working on the Product Attribute Bulk Update for Catalog content update.

[] report.WARNING: Session size of 581711 exceeded allowed session max size of 256000. [] []
[] report.WARNING: Session size of 581311 exceeded allowed session max size of 256000. [] []

 

After some Google and Stack Overflow, the issue is caused by 2 configurations under

Stores > Setting > Configuration > Advanced > System > Security
/admin/system_config/edit/section/system/

– Max Session Size in Admin, default: 256000
– Max Session Size in Storefront, default: 256000

These 2 values are responsible for the errors that are seen in the logs, and they can be set to 0 for disabled, or a higher value which will fit your project.

 

Alternatively, if you are CLI buff, you can run the command below to do the same thing.

bin/magento config:set system/security/max_session_size_admin 0
bin/magento cache:flush

These commands will set the Max Session Size in Admin to 0 (which will disable any limit) and a cache flush for the configuration to take effect.

Leave a comment if it solves your issue!

Coming from Magento 2 On-Prem (self-hosted), we often miss out product attributes bulk update consumers under the .magento.env.yaml file. 

The On-Prem projects normally have these under cronjob and a different setup may not be necessary. However due to how Magento Commerce Cloud infrastructure is built to be, consumers configurations are needed for Queues to run. This is part of the CI/CD structure that is implemented during each deployment (ie. git push).

There are several other consumers that a Magento Cloud project will normally need.
Here’s a default basic of what we will normally run on a basic Cloud setup. More configurations are usually added more as the project goes, but this setup will allow basic features to be enabled.

.magento.env.yaml

stage:
  global:
    SCD_ON_DEMAND: true

  build:
    VERBOSE_COMMANDS: "-vvv"

  deploy:
    VERBOSE_COMMANDS: "-vvv"
    CRON_CONSUMERS_RUNNER:
        cron_run: true
        max_messages: 1000
        consumers:
            - exportProcessor
            - codegeneratorProcessor
            - product_action_attribute.update
            - product_action_attribute.website.update

Some explanations of what the 4 different consumers do

 

– exportProcessor
This will run export queue of CSV export (eg. Catalogs, Customers), and are mainly used for when we are importing/exporting data for upload or comparison.
System > Data Transfer > Export

 

– codegeneratorProcessor
This will run Cart Rules promotion codes generation (possibly gift cards too), otherwise the promotion codes will not be generated if you are needing to generate unique codes. 
Marketing > Promotions > Cart Price Rules > Manage Coupon Codes

 

– product_action_attribute.update
– product_action_attribute.website.update
Both of these will be required when Mass Update is used. Mass Update is an useful action when you have a big chunk of same content you need to update across many different products. For example, Promotion Label or Shipping Type.
Catalog > Inventory > Products > Actions (eg. Update attributes)

 

Let’s also aim to talk about what other configurations are there in some upcoming posts.
This yaml file has a ton of things that we can use to manipulate how our Magento projects can run under the Cloud’s infrastructure.

Do you have more questions or need more help in terms of product attributes bulk update? Do leave a comment down below!