Magento 2 major backward-incompatible changes were introduced in the 2.4.7

By | April 22, 2024
0 Comment
Spread the love

The following major backward-incompatible changes were introduced in the 2.4.7 Adobe Commerce and Magento Open Source releases:

  • API integration: FedEx SOAP
  • API integration: UPS SOAP
  • Default behavior for isEmailAvailable API
  • Elasticsearch 7 deprecation
  • Fixes to resolve compatibility issues with Symfony
  • New block class for subresource integrity verification
  • New interface and method for ApplicationServer module
  • New method and an optional parameter for multicoupons
  • New method in Config/Type/System
  • New method for encryption key generation
  • New SKU validation in inventory source items API
  • New system configuration for full-page caching
  • New system configuration for limiting coupon generation
  • New system configuration for payment information rate limiting
  • New system configuration validation for Two Factor Authentication otp_window value

API integration: FedEx SOAP

The Commerce FedEx SOAP API integration has been migrated to the new FedEx REST API. The FedEx Web Services for Tracking API was retired on May 15, 2024. All previous FedEx SOAP APIs have been removed from the Adobe Commerce and Magento Open Source 2.4.7 code base.

This change affects custom code and extensions that use the SOAP APIs. You must update your code to use the REST APIs.

You must generate REST credentials (Account Number, API Key, and Secret Key) from the FedEx developer portal and add those credentials to the Admin by going to Stores > Configuration > Sales > Shipping/Delivery Methods > FedEx.

The following module is affected by this change:

API integration: UPS SOAP

The Commerce UPS SOAP API integration has been migrated to the new UPS REST API to support updates that UPS is making to their API security model. UPS is implementing an OAuth 2.0 security model (bearer tokens) for all APIs. All previous Commerce UPS SOAP APIs have been removed from the Adobe Commerce and Magento Open Source 2.4.7 code base.

You must generate REST credentials (Account Number, API Key, and Secret Key) from the UPS developer portal and update those credentials to the Admin by going to Stores > Configuration > Sales > Shipping/Delivery Methods > UPS.

The following module is affected by this change:

Default behavior for isEmailAvailable API

The default behavior of the isEmailAvailable GraphQL query and (V1/customers/isEmailAvailable) REST endpoint has changed. By default, the API now always returns true. The new default behavior also affects the checkout workflow for guests that do not realize they already have an account. Previously, by default, when a guest supplied an email address that matched an existing customer account, they were prompted to sign in. Now, they are no longer prompted to sign in.

Merchants can restore the original default behavior of the isEmailAvailable API and checkout flow by setting the Stores > Configuration > Sales > Checkout > Enable Guest Checkout Login field to Yes. However, doing this can expose customer information to unauthenticated users.

Elasticsearch 7 deprecation

This change removes the Magento_Elasticsearch module (for Elasticsearch 5) and adds support for Elasticsearch 8. The Magento_Elasticsearch7 module is being deprecated because Elasticsearch 7 reached end-of-life in August 2023. However, it is still the default option for 2.4.7.

The Magento_Elasticsearch8 module is not currently supported because of backward-incompatible changes in ES7 and ES8. It is available as a Composer metapackage only in 2.4.7 until the Magento_Elasticsearch7 module is removed from the codebase.

You can use the Magento_Elasticsearch7 module or install the Magento_Elasticsearch8 module in 2.4.7.

The following modules are affected by this change:

Fixes to resolve compatibility issues with Symfony

The return type was changed for the Magento\Framework\Console\Cli::getDefaultCommands interface to provide compatibility with the latest Symfony 6.4 LTS version.

Extension developers must define strict typing for return values in classes that use the changed interface: Magento\Framework\Console\Cli::getDefaultCommands.

New block class for subresource integrity verification

A new block class was added (Magento\Csp\Block\Sri\Hashes) marked with the @api annotation to support subresource integrity verification. This ensures that all scripts executed on payment pages and the Admin have an integrity attribute so that no unauthorized scripts can run. You must add integrity attributes to all custom and remote JavaScript resources.

The following module is affected by this change:

New interface and method for ApplicationServer module

State management has been enabled for all GraphQL APIs (excluding B2B and service-related processes). The 2.4.7 release introduces a new PHP application server that is implemented on a Swoole PHP extension. The ApplicationServer module enables Adobe Commerce to maintain state between Commerce GraphQL API requests and eliminates the need for request bootstrapping. By sharing application state among processes, API requests become significantly more efficient, and API response times potentially decrease by 50 to 60 milliseconds.

The ResetAfterRequestInterface interface and _resetState() method were added to enable the PHP application server. The __debugInfo() method was also added to fix issues with var_dump calls.

No action for merchants or extension developers is necessary.

The following modules are affected by this change:

New method and an optional parameter for multicoupons

The following changes were introduced to implement the multicoupon functionality in the SalesRule module:

  • Optional parameter added to Magento\SalesRule\Model\ResourceModel\Rule\Collection::setValidationFilter
  • New method introduced: Magento\SalesRule\Model\Validator::initFromQuote

All changes have been done in a way to minimize any impact to extensions and customizations. However, there are risks of conflict if an extension or customization extends the following:

  • Magento\SalesRule\Model\ResourceModel\Rule\Collection::setValidationFilter and adds a parameter to this method.
  • Magento\SalesRule\Model\Validator and introduces a method with the same name initFromQuote.

The following module is affected by this change:

New method for encryption key generation

This change improves the security of encrypted user data. You must reset the encryption key and set the Auto-generate option to Yes. After resetting the encryption key, all credit card data and cache files are re-encrypted with the new key.

The following files are affected by this change:

New method in Config/Type/System

The bin/magento cache:clean config CLI command, and its Admin UI equivalent, now pre-warm the config cache (when config cache is enabled) in order to reduce the lock time after cleaning the config cache. This reduces the downtime for large configurations that take significant time to generate the config cache.

We’ve also changed the configuration save so that it no longer cleans the config_scopes cache (when config cache is enabled). Config saving also pre-warms the config cache now, which also reduces the lock time for large configurations. Cleaning the config cache after saving configuration changes is still recommended.

No action for merchants or extension developers is necessary because the general functionality is the same. Only the order of generating the config cache, serializing, and encrypting (before lock instead of after) was changed.

The following module is affected by this change:

New SKU validation in inventory source items API

Payload containing SKU will now be validated for leading and trailing spaces in the rest/V1/inventory/source-items API.

New system configuration full-page caching

This change improves the security and performance of how the framework resolves Varnish Edge Side Includes (ESI) for full-page caching.

The {BASE-URL}/page_cache/block/esi HTTP endpoint supports unrestricted, dynamically loaded content fragments from Commerce layout handles and block structures.

The new Handles params size system configuration setting limits the handles parameter for the endpoint to 100 by default. You can change the default in the Admin by going to Stores > Settings > Configuration > Advanced > System > Full Page Cache.

No action is necessary unless you need to modify the default value for the endpoint.

The following module is affected by this change:

New system configuration for limiting coupon generation

Added a new setting for the number of coupons to generate. This property has a default value of 250,000, which is also the maximum value. Merchants can disable this feature by setting it to 0 in the Admin by going to Stores > Settings > Configuration > Customers > Promotions > Code Quantity Limit.

The following module is affected by this change:

New system configuration for payment information rate limiting

New native application rate-limiting features have been added with initial out-of-the-box support for rate limiting of payment APIs. Disabled by default.

No action for merchants or extension developers is necessary.

The following module is affected by this change:

New system configuration validation for Two Factor Authentication otp_window value

The updatedspomky-labs/otphp library introduced a new validation requirement for supplying custom otp_window values. This configuration setting controls how long (in seconds) the system accepts an administrator’s one-time-password (OTP) after it has expired. Previously, the library allowed any number of seconds to be specified. Now, the value cannot be higher than the lifetime of a single OTP (usually 30 seconds). You must update this value if it is currently set to 30 or higher.

If your Commerce application is affected by this change, admin users might see the following message when they log in: There was an internal error trying to verify your code. You can confirm the cause of the error by checking the system.log file in var/log for an entry main.ERROR: The leeway must be lower than the TOTP period.

To fix this issue, change the value of the configuration path twofactorauth/google/otp_window to be shorter than the TOTP period, which is usually 30 seconds. For example, you can reset it to 29 seconds using the bin/magento config:set twofactorauth/google/otp_window 29 command. You might need to flush the cache to apply the updated configuration.