TBD Release (2.4.9)

src/pages/coding-standards/js.md

@@ -361,4 +361,33 @@ var foo = 'bar',
 
 There is a set of custom Eslint rules to ensure code compatibility with the latest versions of third-party libraries.
 
-These custom rules are included using the `rulePaths` setting in the [Eslint Grunt configuration](https://github.com/magento/magento2/blob/2.4/dev/tools/grunt/configs/eslint.json).
+In previous versions of ESLint, these custom rules were included using the `rulePaths` setting in the [ESLint Grunt configuration](https://github.com/magento/magento2/blob/2.4/dev/tools/grunt/configs/eslint.json).
+
+However, since ESLint 9 has deprecated `rulePaths`, you must update the configuration accordingly.
+
+The following example shows the necessary changes to implement custom Eslint rules in the `dev/tools/grunt/configs/eslint.json` file.
+
+```json
+{
+  "file": {
+    "options": {
+      "overrideConfigFile": "vendor/magento/magento-coding-standard/eslint/eslint.config.mjs",
+      "useEslintrc": false
+    }
+  },
+  "test": {
+    "options": {
+      "overrideConfigFile": "vendor/magento/magento-coding-standard/eslint/eslint.config.mjs",
+      "outputFile": "dev/tests/static/eslint-error-report.xml",
+      "format": "junit",
+      "quiet": true
+    }
+  }
+}
+```
+
+### Applying custom rules
+
+To add or modify custom rules, update the `eslint.config.mjs` file in the `magento-coding-standard` repository.
+In the latest version of ESLint, the configuration has transitioned from using the legacy `.eslintrc` settings to the new flat configuration.
+Refer to the [migration guide](https://eslint.org/docs/latest/use/configure/migration-guide) in the ESlint documentation for detailed instructions on migrating to the new format.

src/pages/development/cli-commands/custom.md

@@ -85,9 +85,9 @@ Following is a summary of the process:
 
     ```php
     <?php
-   
+
     declare(strict_types=1);
-   
+
     namespace Magento\CommandExample\Console\Command;
 
     use Magento\Framework\Exception\LocalizedException;
@@ -125,7 +125,7 @@ Following is a summary of the process:
          protected function execute(InputInterface $input, OutputInterface $output): int
          {
              $exitCode = 0;
-             
+
              if ($name = $input->getOption(self::NAME)) {
                  $output->writeln('<info>Provided name is `' . $name . '`</info>');
              }
@@ -144,21 +144,21 @@ Following is a summary of the process:
                  ));
                  $exitCode = 1;
              }
-             
+
              return $exitCode;
          }
     }
     ```
 
     Style the output text by using `<error>`, `<info>`, or `<comment>` tags. See [Symfony](https://symfony.com/doc/current/console/style.html#output-coloring) documentation for more information about styling.
 
-1. Declare your Command class in `Magento\Framework\Console\CommandListInterface` and configure the command name using dependency injection (`<your component root dir>/etc/di.xml`):
+1. Declare your Command class in `Magento\Framework\Console\CommandList` and configure the command name using dependency injection (`<your component root dir>/etc/di.xml`):
 
     ```xml
     <?xml version="1.0"?>
     <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
         ...
-        <type name="Magento\Framework\Console\CommandListInterface">
+        <type name="Magento\Framework\Console\CommandList">
             <arguments>
                 <argument name="commands" xsi:type="array">
                     <item name="commandexample_somecommand" xsi:type="object">Magento\CommandExample\Console\Command\SomeCommand</item>

src/pages/development/components/message-queues/async-configuration.md

@@ -64,6 +64,8 @@ The message queue topology configuration links all auto-generated topic names wi
 </exchange>
 ```
 
+The connection type is automatically determined from your `env.php` configuration.
+
 <InlineAlert variant="info" slots="text"/>
 
 The message queue connection is defined dynamically based on the deployment configuration in `env.php`. If AMQP or STOMP is configured for the queue, that connection is used. Otherwise, the database connection is used. Because the connection is resolved dynamically, explicit declarations are unnecessary in the [message queue configuration files](configuration.md): `queue_consumer.xml`, `queue_publisher.xml`, `queue_topology.xml`.

src/pages/development/components/message-queues/bulk-operations-example.md

@@ -329,7 +329,7 @@ The `queue_consumer.xml` file defines the relationship between a queue and its c
 </config>
 ```
 
-The connection type (AMQP or STOMP) is determined automatically from the `env.php` configuration.
+The connection type (AMQP or STOMP) is determined automatically from your `env.php` configuration.
 
 ### queue_publisher.xml
 
@@ -346,6 +346,8 @@ The `queue_publisher.xml` file defines the exchange where a topic is published.
 
 Alternatively, you can explicitly specify the connection and exchange:
 
+**For RabbitMQ (AMQP):**
+
 ```xml
 <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework-message-queue:etc/publisher.xsd">
     <publisher topic="<topic_name>">
@@ -378,6 +380,8 @@ The `queue_topology.xml` file defines message routing rules and declares queues
 </config>
 ```
 
+The connection type is automatically determined from your `env.php` configuration.
+
 <InlineAlert variant="info" slots="text"/>
 
-Message queue connections are resolved dynamically from `env.php`. When AMQP or STOMP is configured, the corresponding connection is applied; otherwise, the database connection is used. You can omit connection declarations from `queue_consumer.xml`, `queue_publisher.xml`, and `queue_topology.xml` when using AMQP or STOMP. ActiveMQ Artemis (STOMP) was introduced in Adobe Commerce 2.4.5 and uses ANYCAST addressing mode for point-to-point message delivery and load balancing across multiple consumers. See [Message queue configuration files](configuration.md).
+Message queue connections are resolved dynamically from `env.php`. When AMQP or STOMP is configured, the corresponding connection is applied; otherwise, the database connection is used. You can omit connection declarations from `queue_consumer.xml`, `queue_publisher.xml`, and `queue_topology.xml` when using AMQP or STOMP. ActiveMQ Artemis (STOMP) support was introduced in Adobe Commerce 2.4.5. For STOMP connections, use ANYCAST addressing mode for point-to-point message delivery and load balancing across multiple consumers. See [Message queue configuration files](configuration.md).

src/pages/development/components/message-queues/index.md

@@ -12,7 +12,7 @@ Message queues provide an asynchronous communications mechanism in which the sen
 
 ## Message Queue Framework overview
 
-The Adobe Commerce Message Queue Framework (MQF) is a fully-functional system that allows a module to publish messages to queues and create consumers to receive them asynchronously.
+The Adobe Commerce and Magento Open Source Message Queue Framework (MQF) is a fully-functional system that allows a module to publish messages to queues and create consumers to receive them asynchronously.
 
 The MQF supports the following messaging brokers:
 
@@ -112,3 +112,40 @@ The following example shows how to switch a topic to an external broker. Replace
 ```
 
 For example, to switch the `product_action_attribute.update` topic to RabbitMQ, use `amqp-magento` as the publisher and `amqp` as the connection name.
+
+### Example: switch a topic to ActiveMQ Artemis (STOMP)
+
+The following configuration shows how to configure a topic to use STOMP instead of MySQL:
+
+```php
+'queue' => [
+    'topics' => [
+        'inventory.update' => [
+            'publisher' => 'stomp-magento'
+        ]
+    ],
+    'config' => [
+        'publishers' => [
+            'inventory.update' => [
+                'connections' => [
+                    'stomp' => [
+                        'name' => 'stomp',
+                        'exchange' => 'magento',
+                        'disabled' => false
+                    ],
+                    'db' => [
+                        'name' => 'db',
+                        'exchange' => 'magento',
+                        'disabled' => true
+                    ]
+                ]
+            ]
+        ]
+    ],
+    'consumers' => [
+        'inventory.update' => [
+            'connection' => 'stomp',
+        ],
+    ]
+],
+```

src/pages/development/components/message-queues/migration.md

@@ -263,7 +263,7 @@ The Adobe Commerce and Magento Open Source 2.1 `communication.xml` file has not
 
 To upgrade from Adobe Commerce or Magento Open Source 2.0, you must create the following files in the `<module>/etc` directory for each module that will use the message queue framework.
 
-- `queue_consumer.xml` - Defines the relationship between an existing queue and its consumer.
+- `queue_consumer.xml`—Defines the relationship between an existing queue and its consumer.
 - `queue_topology.xml`—Defines the message routing rules.
 - `queue_publisher.xml`—Defines the relationship between a topic and its publisher.
 

src/pages/development/security/subresource-integrity.md

@@ -32,17 +32,31 @@ The default SRI feature is implemented only on the payment pages for the admin a
 
 ## Subresource Integrity Hash Generation
 
+<InlineAlert slots="text" />
+Adobe Commerce and Magento Open Source 2.4.9 and later support SRI hash generation for all JavaScript assets, including those processed through minification, bundling, and merging.
+
 The Subresource Integrity hash generation process begins once [static content](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/static-view/static-view-file-deployment) for each package area has been deployed.
-The [postprocessor](https://github.com/magento/magento2/tree/2.4-develop/app/code/Magento/Csp/Model/Deploy/Package/Processor/PostProcessor) class then systematically processes all javascript files within each package and generates integrity hashes.
-The postprocessor class triggers the [SubresourceIntegrityCollector](https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Csp/Model/SubresourceIntegrityCollector.php) class to collect the hashes which are stored in the filesystem after all packages are deployed.
+The [postprocessor](https://github.com/magento/magento2/tree/2.4-develop/app/code/Magento/Csp/Model/Deploy/Package/Processor/PostProcessor) class then systematically processes all JavaScript files within each package and generates SHA-256 integrity hashes, including minified file variants. This process covers all Static Content Deployment (SCD) strategies: Standard, Quick, and Compact.
+The postprocessor class triggers the [SubresourceIntegrityCollector](https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Csp/Model/SubresourceIntegrityCollector.php) class to collect the hashes, which are saved to a scoped, per-package repository immediately after each package is deployed.
+Hashes for bundled JavaScript assets are also generated at deploy time. Hashes for runtime-generated merged JavaScript assets are captured on first use and stored separately in `pub/static/_cache/merged/sri-hashes.json`.
 All integrity hashes are stored in the filesystem via the [Storage](https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Csp/Model/SubresourceIntegrity/Storage/File.php) class.
 
 ## Subresource Integrity Storage
 
 <InlineAlert slots="text" />
 Adobe Commerce and Magento Open Source 2.4.8 and later no longer use a cache to store SRI hashes. The implementation has been refactored to store the hashes in the local filesystem instead. This ensures that SRI hashes are still intact and not effected by purging of caches.
-Subresource Integrity hashes are stored in JSON files in the `pub/static` directory by the deployed package area (frontend, base or admin).
-For example, SRI hashes for the `adminhtml/Magento/backend/en_US/requirejs/require.js` file will be located in the `pub/static/adminhtml/sri-hashes.json` file.
+
+<InlineAlert slots="text" />
+Adobe Commerce and Magento Open Source 2.4.9 and later store SRI hashes in files scoped by area, theme, and locale, rather than a single file per area.
+
+Subresource Integrity hashes are stored in `sri-hashes.json` files scoped by area, theme, and locale under the `pub/static` directory.
+For example, SRI hashes for the `adminhtml/Magento/backend/en_US/requirejs/require.js` file are stored in the `pub/static/adminhtml/Magento/backend/en_US/sri-hashes.json` file.
+
+Hashes for runtime-generated merged JavaScript files are stored separately in `pub/static/_cache/merged/sri-hashes.json`.
+
+Scoping hash files by area, theme, and locale prevents a single large file from degrading page and checkout performance as additional themes and locales are added.
+
+When running a partial static content deployment with the `--area`, `--theme`, or `--language` options, only the SRI hash files that match the specified scope are removed and regenerated, leaving all other locales and themes intact.
 
 ### Subresource Integrity for Remote Resources
 

src/pages/module-reference/module-cms.md

@@ -9,7 +9,7 @@ The CMS module provides the create, edit, and manage functionality on pages for
 
 ## Wysiwyg
 
-The Wysiwyg UI component is a customizable and configurable TinyMCE editor.
+The Wysiwyg UI component is a customizable and configurable HugeRTE editor.
 
 The default implementation has the following customizations: