Merge branch 'trunk' into fix/product-gallery-thumbnails-sizing

docs/internal-developers/block-client-apis/checkout/checkout-api.md

@@ -95,7 +95,8 @@ The shipping method data context exposes the api interfaces for the following th
 
 The payment method events context exposes any event handlers related to payments (typedef `PaymentEventsContext`) via the `usePaymentEventsContext` hook.
 
--   `onPaymentProcessing`: This is an event subscriber that can be used to subscribe observers to be called when the status for the context is `PROCESSING`.
+-   `onPaymentSetup`: This is an event subscriber that can be used to subscribe observers to be called when the payment is being setup.
+-   ~~`onPaymentProcessing`~~: This event was deprecated in favour of `onPaymentSetup`.
 
 ### Checkout Events Context
 
@@ -151,9 +152,9 @@ Payment method components are passed, by default, everything from the [`usePayme
 ```js
 const Content = ( props ) => {
 	const { eventRegistration, emitResponse } = props;
-	const { onPaymentProcessing } = eventRegistration;
+	const { onPaymentSetup } = eventRegistration;
 	useEffect( () => {
-		const unsubscribe = onPaymentProcessing( async () => {
+		const unsubscribe = onPaymentSetup( async () => {
 			// Here we can do any processing we need, and then emit a response.
 			// For example, we might validate a custom field, or perform an AJAX request, and then emit a response indicating it is valid or not.
 			const myGatewayCustomData = '12345';
@@ -182,7 +183,7 @@ const Content = ( props ) => {
 	}, [
 		emitResponse.responseTypes.ERROR,
 		emitResponse.responseTypes.SUCCESS,
-		onPaymentProcessing,
+		onPaymentSetup,
 	] );
 	return decodeEntities( settings.description || '' );
 };

docs/internal-developers/block-client-apis/checkout/checkout-flow-and-events.md

@@ -4,13 +4,14 @@
 
 -   [General Concepts](#general-concepts)
     -   [Tracking flow through status](#tracking-flow-through-status)
-    -   [Checkout Data Store Status](#checkout-data-store-status)
-        -   [Special States:](#special-states)
+        -   [Checkout Data Store Status](#checkout-data-store-status)
+        -   [Special States](#special-states)
     -   [`ShippingProvider` Exposed Statuses](#shippingprovider-exposed-statuses)
     -   [Payment Method Data Store Status](#payment-method-data-store-status)
     -   [Emitting Events](#emitting-events)
     -   [`onCheckoutValidation`](#oncheckoutvalidation)
-    -   [`onPaymentProcessing`](#onpaymentprocessing)
+    -   [~~`onPaymentProcessing`~~](#onpaymentprocessing)
+    -   [`onPaymentSetup`](#onpaymentsetup)
         -   [Success](#success)
         -   [Fail](#fail)
         -   [Error](#error)
@@ -252,9 +253,13 @@ const PaymentMethodComponent = ( { eventRegistration } ) => {
 };
 ```
 
-### `onPaymentProcessing`
+### ~~`onPaymentProcessing`~~
 
-This event emitter is fired when the payment method context status is `PROCESSING` and that status is set when the checkout status is `PROCESSING`, checkout `hasError` is false, checkout is not calculating, and the current payment status is not `FINISHED`.
+This is now deprecated and replaced by the `onPaymentSetup` event emitter.
+
+### `onPaymentSetup`
+
+This event emitter was fired when the payment method context status is `PROCESSING` and that status is set when the checkout status is `PROCESSING`, checkout `hasError` is false, checkout is not calculating, and the current payment status is not `FINISHED`.
 
 This event emitter will execute through each registered observer (passing in nothing as an argument) _until_ an observer returns a non-truthy value at which point it will _abort_ further execution of registered observers.
 
@@ -271,10 +276,10 @@ const successResponse = { type: 'success' };
 When a success response is returned, the payment method context status will be changed to `SUCCESS`. In addition, including any of the additional properties will result in extra actions:
 
 -   `paymentMethodData`: The contents of this object will be included as the value for `payment_data` when checkout sends a request to the checkout endpoint for processing the order. This is useful if a payment method does additional server side processing.
--   `billingData`: This allows payment methods to update any billing data information in the checkout (typically used by Express payment methods) so it's included in the checkout processing request to the server. This data should be in the [shape outlined here](../../../../assets/js/types/type-defs/billing.js).
--   `shippingData`: This allows payment methods to update any shipping data information for the order (typically used by Express payment methods) so it's included in the checkout processing request to the server. This data should be in the [shape outlined here](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/34e17c3622637dbe8b02fac47b5c9b9ebf9e3596/assets/js/type-defs/cart.js#L20-L32).
+-   `billingAddress`: This allows payment methods to update any billing data information in the checkout (typically used by Express payment methods) so it's included in the checkout processing request to the server. This data should be in the [shape outlined here](../../../../assets/js/settings/shared/default-address-fields.ts).
+-   `shippingAddress`: This allows payment methods to update any shipping data information for the order (typically used by Express payment methods) so it's included in the checkout processing request to the server. This data should be in the [shape outlined here](../../../../assets/js/settings/shared/default-address-fields.ts).
 
-If `billingData` or `shippingData` properties aren't in the response object, then the state for the data is left alone.
+If `billingAddress` or `shippingAddress` properties aren't in the response object, then the state for the data is left alone.
 
 #### Fail
 
@@ -289,7 +294,7 @@ When a fail response is returned by an observer, the payment method context stat
 -   `message`: The string provided here will be set as an error notice in the checkout.
 -   `messageContext`: If provided, this will target the given area for the error notice (this is where `noticeContexts` mentioned earlier come in to play). Otherwise the notice will be added to the `noticeContexts.PAYMENTS` area.
 -   `paymentMethodData`: (same as for success responses).
--   `billingData`: (same as for success responses).
+-   `billingAddress`: (same as for success responses).
 
 #### Error
 
@@ -319,11 +324,11 @@ import { usePaymentEventsContext } from '@woocommerce/base-contexts';
 import { useEffect } from '@wordpress/element';
 
 const Component = () => {
-	const { onPaymentProcessing } = usePaymentEventsContext();
+	const { onPaymentSetup } = usePaymentEventsContext();
 	useEffect( () => {
-		const unsubscribe = onPaymentProcessing( () => true );
+		const unsubscribe = onPaymentSetup( () => true );
 		return unsubscribe;
-	}, [ onPaymentProcessing ] );
+	}, [ onPaymentSetup ] );
 	return null;
 };
 ```
@@ -334,11 +339,11 @@ _For registered payment method components:_
 const { useEffect } = window.wp.element;
 
 const PaymentMethodComponent = ( { eventRegistration } ) => {
-	const { onPaymentMethodProcessing } = eventRegistration;
+	const { onPaymentSetup } = eventRegistration;
 	useEffect( () => {
-		const unsubscribe = onPaymentMethodProcessing( () => true );
+		const unsubscribe = onPaymentSetup( () => true );
 		return unsubscribe;
-	}, [ onPaymentMethodProcessing ] );
+	}, [ onPaymentSetup ] );
 };
 ```
 

docs/internal-developers/testing/cart-checkout/data-stores.md

@@ -86,7 +86,7 @@ usePaymentProcessing(
 	emitResponse,
 	sourceId,
 	setSourceId,
-	onPaymentProcessing,
+	onPaymentSetup,
 	eventRegistration
 );
 ```
@@ -102,7 +102,7 @@ export const usePaymentProcessing = (
   emitResponse,
   sourceId,
   setSourceId,
-  onPaymentProcessing,
+  onPaymentSetup,
   eventRegistration
 ) => {
 ...

docs/internal-developers/testing/releases/1146.md

@@ -0,0 +1,13 @@
+# Testing notes and ZIP for release 11.4.6
+
+Zip file for testing: [woocommerce-gutenberg-products-block.zip](https://github.com/woocommerce/woocommerce-blocks/files/13308368/woocommerce-gutenberg-products-block.zip)
+
+## WooCommerce Core
+
+### Bug Fixes
+
+#### Update Jetpack WooCommerce Analytics module integration to check for changed template names ([#11707](https://github.com/woocommerce/woocommerce-blocks/pull/11707))
+
+1. Enable Jetpack and ensure the WooCommerce Analytics module is set up and enabled.
+2. Install [Query Monitor](https://wordpress.org/plugins/query-monitor/).
+3. Go to the Cart and Checkout blocks and ensure no PHP warnings are logged.

docs/internal-developers/testing/releases/README.md

@@ -187,5 +187,6 @@ Every release includes specific testing instructions for new features and bug fi
     -   [11.4.3](./1143.md)
     -   [11.4.4](./1144.md)
     -   [11.4.5](./1145.md)
+    -   [11.4.6](./1146.md)
 -   [11.5.0](./1150.md)
     -   [11.5.1](./1151.md)

docs/third-party-developers/extensibility/checkout-block/available-filters/cart-line-items.md

@@ -572,7 +572,7 @@ The Cart object of the filters above has the following keys:
     -   _phone_ `string` - The phone of the address.
     -   _postcode_ `string` - The postcode of the address.
     -   _state_ `string` - The state of the address.
--   _billingData_ `object` - The billing data object with the same keys as the `billingAddress` object.
+-   ~~_billingData_~~ `object` - The billing data object with the same keys as the `billingAddress` object.
 -   _cartCoupons_ `array` - The cart coupons array.
 -   _cartErrors_ `array` - The cart errors array.
 -   _cartFees_ `array` - The cart fees array.

docs/third-party-developers/extensibility/checkout-block/available-filters/order-summary-items.md

@@ -388,7 +388,7 @@ The Cart object of the filters above has the following keys:
     -   _phone_ `string` - The phone of the address.
     -   _postcode_ `string` - The postcode of the address.
     -   _state_ `string` - The state of the address.
--   _billingData_ `object` - The billing data object with the same keys as the `billingAddress` object.
+-   ~~_billingData_~~ `object` - The billing data object with the same keys as the `billingAddress` object.
 -   _cartCoupons_ `array` - The cart coupons array.
 -   _cartErrors_ `array` - The cart errors array.
 -   _cartFees_ `array` - The cart fees array.

docs/third-party-developers/extensibility/checkout-block/available-filters/totals-footer-item.md

@@ -73,7 +73,7 @@ The Cart object of the filters above has the following keys:
     -   _phone_ `string` - The phone of the address.
     -   _postcode_ `string` - The postcode of the address.
     -   _state_ `string` - The state of the address.
--   _billingData_ `object` - The billing data object with the same keys as the `billingAddress` object.
+-   ~~_billingData_~~ `object` - The billing data object with the same keys as the `billingAddress` object.
 -   _cartCoupons_ `array` - The cart coupons array.
 -   _cartErrors_ `array` - The cart errors array.
 -   _cartFees_ `array` - The cart fees array.

docs/third-party-developers/extensibility/checkout-block/how-checkout-processes-an-order.md

@@ -16,10 +16,10 @@ Data stores are used to keep track of data that is likely to change during a use
 
 ### Contexts
 
-Contexts are used to make data available to the Checkout block. Each of these provide data and functions related to a specific area of concern, via the use of a hook. For example, if we wanted to use the `onPaymentProcessing` handler from the `PaymentEventsContext` context, we can do it like this:
+Contexts are used to make data available to the Checkout block. Each of these provide data and functions related to a specific area of concern, via the use of a hook. For example, if we wanted to use the `onPaymentSetup` handler from the `PaymentEventsContext` context, we can do it like this:
 
 ```js
-const { onPaymentProcessing } = usePaymentEventsContext();
+const { onPaymentSetup } = usePaymentEventsContext();
 ```
 
 The other job of contexts is to run side effects for our Checkout block. What typically happens is that the `CheckoutEvents` and `PaymentEvents` will listen for changes in the checkout and payment data stores, and dispatch actions on those stores based on some logic.
@@ -145,4 +145,3 @@ The `checkPaymentMethodsCanPay()` [function](https://github.com/woocommerce/wooc
 🐞 Found a mistake, or have a suggestion? [Leave feedback about this document here.](https://github.com/woocommerce/woocommerce-blocks/issues/new?assignees=&labels=type%3A+documentation&template=--doc-feedback.md&title=Feedback%20on%20./docs/third-party-developers/extensibility/checkout-block/how-checkout-processes-an-order.md)
 
 <!-- /FEEDBACK -->
-

docs/third-party-developers/extensibility/checkout-payment-methods/filtering-payment-methods.md

@@ -90,7 +90,7 @@ interface CanMakePaymentArgument {
 	cart: Cart;
 	cartTotals: CartTotals;
 	cartNeedsShipping: boolean;
-	billingData: CartResponseBillingAddress;
+	billingAddress: CartResponseBillingAddress;
 	shippingAddress: CartResponseShippingAddress;
 	selectedShippingMethods: Record< string, unknown >;
 	paymentRequirements: Array< string >;