fixed multiple typos inside docs (https://github.com/woocommerce/woocommerce-blocks/pull/11426)
This commit is contained in:
parent
7cea7de7dd
commit
9b1ca0707a
|
@ -77,7 +77,7 @@ From there, you can open the _Summary_ of the e2e test jobs:
|
|||
|
||||
<img src="https://user-images.githubusercontent.com/3616980/231486308-8f85779b-8ede-440d-a250-6ff612d6ea20.png" alt="Log of an e2e test suite that failed, highlighting the Summary button" width="780" />
|
||||
|
||||
From the _Summmary_ page, if you scroll down, you can download the report of each test suite that failed:
|
||||
From the _Summary_ page, if you scroll down, you can download the report of each test suite that failed:
|
||||
|
||||
<img src="https://user-images.githubusercontent.com/3616980/231486320-c52a0e10-c80e-4d3a-ae0f-b3998013f528.png" alt="Report summary showing the Artifacts list, including the e2e reports" width="780" />
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ The initial state of the checkout store is:
|
|||
|
||||
## Observers
|
||||
|
||||
Extensions can register "observers" which will respond to specific events in the Checkout flow. More information on these can be found in the [checkout flow and events documentation](../../internal-developers/block-client-apis/checkout/checkout-flow-and-events.md). Thar documentation also contains information about the general flow of the checkout system, whereas this documentation only describes how the data is affected during checkout.
|
||||
Extensions can register "observers" which will respond to specific events in the Checkout flow. More information on these can be found in the [checkout flow and events documentation](../../internal-developers/block-client-apis/checkout/checkout-flow-and-events.md). That documentation also contains information about the general flow of the checkout system, whereas this documentation only describes how the data is affected during checkout.
|
||||
|
||||
## Status changes
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ Zip file for testing: [woocommerce-gutenberg-products-block.zip](https://github.
|
|||
1. Install and activate a block theme, e.g. [Twenty Twenty-Three](https://wordpress.org/themes/twentytwentythree/).
|
||||
2. Create a test page with the Checkout block.
|
||||
3. Create a test page with the Cart block.
|
||||
4. Go to `WP Admin` » `Apperance` » `Editor.`
|
||||
4. Go to `WP Admin` » `Appearance` » `Editor.`
|
||||
5. Open the Styles sidebar.
|
||||
6. Adjust all `Typography ` and `Color` settings.
|
||||
7. Go to the Checkout block page editor.
|
||||
|
|
|
@ -20,4 +20,4 @@ Zip file for testing: [woocommerce-gutenberg-products-block.zip](https://github.
|
|||
|
||||
1. Go to Pages > Cart and edit the page. It will load the site editor. Add some text below the header, for example. Feel free to add anything for testing purposes. Save the template.
|
||||
2. Add an item to your cart and then load the Cart page on the front end. Ensure your changes from step 1 are visible.
|
||||
3. Go to the WP Dasboard, then WooCommerce > Settings > Advanced and change the cart page slug to something different. Repeat step 2 and ensure it still works with your change visible. Ensure the path to the Cart page shown in your browser is the one you updated it to.
|
||||
3. Go to the WP Dashboard, then WooCommerce > Settings > Advanced and change the cart page slug to something different. Repeat step 2 and ensure it still works with your change visible. Ensure the path to the Cart page shown in your browser is the one you updated it to.
|
||||
|
|
|
@ -187,7 +187,7 @@ Mobile view:
|
|||
#### Screenshots
|
||||
|
||||
|
||||
| Desingn | Implemented |
|
||||
| Design | Implemented |
|
||||
| ------ | ----- |
|
||||
| <img width="1214" alt="Screenshot 2023-07-26 at 13 08 52" src="https://github.com/woocommerce/woocommerce-blocks/assets/15730971/2d122488-a24d-4c2d-9ac1-38d015864d86"> | <img width="1221" alt="Screenshot 2023-07-26 at 13 04 33" src="https://github.com/woocommerce/woocommerce-blocks/assets/15730971/5ab6cee4-9038-40e3-8d96-7d44d20f00e7"> |
|
||||
|
||||
|
|
|
@ -20,4 +20,4 @@ Zip file for testing: [woocommerce-gutenberg-products-block.zip](https://github.
|
|||
|
||||
1. Go to Pages > Cart and edit the page. It will load the site editor. Add some text below the header, for example. Feel free to add anything for testing purposes. Save the template.
|
||||
2. Add an item to your cart and then load the Cart page on the front end. Ensure your changes from step 1 are visible.
|
||||
3. Go to the WP Dasboard, then WooCommerce > Settings > Advanced and change the cart page slug to something different. Repeat step 2 and ensure it still works with your change visible. Ensure the path to the Cart page shown in your browser is the one you updated it to.
|
||||
3. Go to the WP Dashboard, then WooCommerce > Settings > Advanced and change the cart page slug to something different. Repeat step 2 and ensure it still works with your change visible. Ensure the path to the Cart page shown in your browser is the one you updated it to.
|
||||
|
|
|
@ -69,7 +69,7 @@ Smoke test the following blocks
|
|||
|
||||
### Fix product list images skewed in Widgets editor
|
||||
|
||||
- [ ] Install latest Gutenberg version and go to Apperance > Widgets.
|
||||
- [ ] Install latest Gutenberg version and go to Appearance > Widgets.
|
||||
- [ ] Add a Top Rated Products block into one of the widget areas and verify images have the correct aspect ratio.
|
||||
|
||||
### Fix select inputs when dark mode is enabled in Twenty Twenty-One
|
||||
|
|
|
@ -12,4 +12,4 @@ An example of things that _should_ be tested with E2E tests:
|
|||
|
||||
1. Blocks cannot be added to the block editor more than once. Reason: **We cannot really mock the Gutenberg functionality to test that this happens without some serious effort.**
|
||||
2. Fresh cart data is fetched when using the browser's back buttons. Reason: **We need to emulate the behaviour of a browser when the back button is pressed and this can't be done in unit tests.**
|
||||
3. The compatability notice is shown when first adding the checkout block. Reason: **same as 1**
|
||||
3. The compatibility notice is shown when first adding the checkout block. Reason: **same as 1**
|
||||
|
|
|
@ -12,7 +12,7 @@ The payment registry stores all the configuration information for each payment m
|
|||
|
||||
### Data Stores
|
||||
|
||||
Data stores are used to keep track of data that is likely to change during a user’s session, such as the active payment method, wether the checkout has an error, etc. We split these data stores by areas of concern, so we have 2 data stores related to the checkout: `wc/store/checkout` [:file_folder:](https://href.li/?https://github.com/woocommerce/woocommerce-blocks/blob/4af2c0916a936369be8a4f0044683b90b3af4f0d/assets/js/data/checkout/index.ts#L1) and `wc/store/payment` [:file_folder:](https://href.li/?https://github.com/woocommerce/woocommerce-blocks/blob/4af2c0916a936369be8a4f0044683b90b3af4f0d/assets/js/data/payment-methods/index.ts#L1) . Data stores live in the `assets/js/data` folder.
|
||||
Data stores are used to keep track of data that is likely to change during a user’s session, such as the active payment method, whether the checkout has an error, etc. We split these data stores by areas of concern, so we have 2 data stores related to the checkout: `wc/store/checkout` [:file_folder:](https://href.li/?https://github.com/woocommerce/woocommerce-blocks/blob/4af2c0916a936369be8a4f0044683b90b3af4f0d/assets/js/data/checkout/index.ts#L1) and `wc/store/payment` [:file_folder:](https://href.li/?https://github.com/woocommerce/woocommerce-blocks/blob/4af2c0916a936369be8a4f0044683b90b3af4f0d/assets/js/data/payment-methods/index.ts#L1) . Data stores live in the `assets/js/data` folder.
|
||||
|
||||
### Contexts
|
||||
|
||||
|
@ -73,7 +73,7 @@ Once all the checkout processing is done and if there are no errors, the payment
|
|||
|
||||
### 6\. Emit the `payment_processing` event [:file_folder:](https://github.com/woocommerce/woocommerce-blocks/blob/4af2c0916a936369be8a4f0044683b90b3af4f0d/assets/js/data/payment-methods/thunks.ts#L42)
|
||||
|
||||
The `payment_processing` event is emited. Otherplugins can register event listeners for this event and run their own code.
|
||||
The `payment_processing` event is emitted. Otherplugins can register event listeners for this event and run their own code.
|
||||
|
||||
For example, the Stripe plugin checks the address and payment details here, and uses the stripe APIs to create a customer and payment reference within Stripe.
|
||||
|
||||
|
@ -109,7 +109,7 @@ The `after_processing` status indicates that we've finished the main checkout pr
|
|||
|
||||
If there are no errors, the `checkout_after_processing_with_success` event is triggered. This is where other plugins can run some code after the checkout process has been successful.
|
||||
|
||||
Any event listeners registered on the `checkout_after_processing_with_successs` event will be executed. If there are no errors from the event listeners, `setComplete` action is called on the `checkout` data store to set the status to `complete` (step 13). An event listener can also return an error here, which will be displayed to the user.
|
||||
Any event listeners registered on the `checkout_after_processing_with_success` event will be executed. If there are no errors from the event listeners, `setComplete` action is called on the `checkout` data store to set the status to `complete` (step 13). An event listener can also return an error here, which will be displayed to the user.
|
||||
|
||||
### 12\. Emit the `checkout_after_processing_with_error` event [:file_folder:](https://github.com/woocommerce/woocommerce-blocks/blob/4af2c0916a936369be8a4f0044683b90b3af4f0d/assets/js/data/checkout/thunks.ts#L104-L116)
|
||||
|
||||
|
|
Loading…
Reference in New Issue