The new WooCommerce Cart and Checkout blocks are built with conversions and ease of use in mind. In this pursuit, we have made deliberate design and engineering choices to enhance the overall experience. As a result, this requires a new approach to extensibility, which diverges from tradition hook and filter methods and instead leverages more focused extensibility interfaces to ensure the best developer and user experience.
We’re committed to increasing our investment in this domain to simplify the process of making extensions compatible and facilitating the implementation of their features for a seamless shopping experience. In this article, we’ll provide a concise overview of the most common extensibility requests, link to relevant GitHub discussions, followed by a preview of our upcoming roadmap.
We want your opinion
We have organized these extensibility points into the following categories. You’ll find links to a GitHub Discussion for each of the points below.
- Payment gateways integration/customization
- Shipping methods – calculation changes and customization
- Product options and configurations
- Custom checkout fields
Payment gateways integration/customization
Embedded checkout
This use-case covers extensions that have their own custom checkout form and want to show that in place of the form we offer.
Currently, we don’t have any way to remove or replace specific inner blocks and the extensions currently doing this use CSS to remove the unwanted blocks which is not an ideal solution.
We have an issue open about this topic https://github.com/woocommerce/woocommerce-blocks/issues/5424
Requirements
We understand this use case has the following requirements:
- Extensions must be able to programmatically disable some of our checkout blocks.
- They should be able to replace our blocks with their own
- Any custom fields being rendered in the checkout form should be surfaced to the relevant block/block replacement
- We must allow for extension to stop the checkout process and show notices or errors if any validation errors are present in their replacement blocks
💬 Discussion
https://github.com/woocommerce/woocommerce-blocks/discussions/11179
Read-only billing/shipping addresses
If you are running a B2B shop, it could be that you only allow synced users from a CRM or similar system to place orders and therefore don’t want to allow WooCommerce users to change their billing and/or shipping addresses.
Making the billing and shipping addresses read-only fields is a good way of achieving this.
In this case, it is also possible that, since they are not editable, the merchant may want to display the information in a more condensed fashion, e.g. an address card, instead of a full form to save space.
Requirements
- The developer must be able to set the address fields to readonly.
- The shopper must not be able to change the data in them.
- The address may be condensed into a smaller component and the form itself hidden, since it is readonly, opting not to display the form will save space. See the following issue for more information: https://github.com/woocommerce/woocommerce-blocks/issues/9787
💬 Discussion
https://github.com/woocommerce/woocommerce-blocks/discussions/11177
“Place order” button replacement
Some payment gateways would like to display a different “Place order” button based on specific factors, such as geolocation. In this case, the payment gateway ensures that buyers only get presented with the payment buttons that are relevant to them and the ones they are not eligible for will not be displayed.
As an example, buyer A from country A may be presented with different payment options to buyer B from country B, without the merchant setting up any logic.
Requirements
- Developers must be able to replace the “Place order button” with a new component
- The button may only be replaced by a payment method when that method is the active one chosen by the shopper
- The original “Place order” button must reappear if the user changes their selected payment method to something else
- The custom component must also render when a saved token belonging to the payment gateway is selected.
💬 Discussion
https://github.com/woocommerce/woocommerce-blocks/discussions/9432
Shipping methods – calculation changes and customization
Estimated Delivery Dates
This use-case is for shipping methods that may want to show an estimated delivery time alongside their rates. Here is an example of what this may look like:
Requirements
- Shipping extensions must be able to specify an estimated delivery date, or range of dates
- This estimate must be shown in the shipping methods block. It should show regardless of whether the rate is selected or not.
- It should not be too distracting from the rest of the checkout process (keep it text-only, for example)
- Shipping methods should not be able to interfere with rates that do not belong to that method.
💬 Discussion
https://github.com/woocommerce/woocommerce-blocks/discussions/11175
Product options and configurations
Per-item inputs or data
Each item in the cart may need controls to change settings, or to display some data. For example, a checkbox to indicate a product is a gift, or a text input to enter a custom note for the gift.
Requirements
- The developer must be able to add one or more controls to specific cart items to control a value.
- The configuration requirements must be available to consumers of the Store API, e.g. they must know that there should be a checkbox rendered for each cart item with the label “This is a gift”
- An extension must be able to conditionally show or hide an individual field (this may depend on a value of one of its other fields too)
💬 Discussion
https://github.com/woocommerce/woocommerce-blocks/discussions/11176
Custom checkout fields
Creating additional fields
In WooCommerce Core, there is a filter which enables the fields displayed in the checkout form to be modified. Using this filter enables merchants and extension developers to add custom fields to their form to collect specific information that is not usually collected, e.g. VAT Number.
This is a common use case we see requests for fairly often. Some examples:
- https://github.com/woocommerce/woocommerce-blocks/discussions/5483
- https://github.com/woocommerce/woocommerce-blocks/issues/8229
- https://github.com/woocommerce/woocommerce-blocks/issues/7529
- https://github.com/woocommerce/woocommerce-blocks/discussions/5736
Requirements
- Extensions must be able to define custom fields to force-render in the Checkout block without requiring the merchant to add them
- Extensions must be able to add a range of optional custom fields that the merchant may or may not add to the Checkout block
- The custom fields added to the Checkout block must be discoverable by the Store API
- The merchant/extension must be able to add fields of various types: e.g. checkbox, text field, email, number, select, multi select etc.
💬 Discussion
https://github.com/woocommerce/woocommerce-blocks/discussions/11173
Editing/Removing existing checkout fields
Similar to the above, WooCommerce core has filters that allow the checkout form to be modified. Using this filter, as well as adding fields, merchants and extension developers can modify existing fields and alter their form, so it behaves differently to the default. This is an extension of the above use case, but we feel that editing and removing will require a separate effort and maybe a different approach to simply adding fields.
Requirements
- Extensions must be able to edit existing fields in the Checkout block without requiring the merchant to manually do it.
- Extensions must be able to remove existing fields from the Checkout block without requiring the merchant to manually do it.
- The edited fields in the Checkout block must be discoverable by the Store API, it must be able to tell what was edited and its new state
- Removed fields must be discoverable by the Store API, it must be able to tell which fields have been removed.
💬 Discussion
https://github.com/woocommerce/woocommerce-blocks/discussions/11174
Exporting WooCommerce Blocks components
We identified that a lot of developers are creating extensions that need specific UI components to function. We also realized that we have already written a lot of these UI components for use in the WooCommerce Blocks plugin. By exporting these, we can reduce the work required by developers to get their extensions working.
We identified the following components as the most important and will work on making these available on the wc global object.
CheckboxListRadioControlRadioControlAccordionLabelTextareaComboboxFormTokenFieldSortSelectTitleSpinnerFormStepChip&RemovableChipFormattedMonetaryAmount
More details on these components will be available in the GitHub discussion for this work.
Roadmap
You can also keep track of all of our plans for WooCommerce and see what the team is working on right now by viewing the WooCommerce Roadmap.
The roadmap is a living document, and it will evolve as we explore use cases, release new endpoints, and gather feedback from the community.
We’re currently focusing on Custom Checkout Fields and migrating the commonly used components to an easily accessible package for developers to use in their own projects.
Feedback
We welcome your feedback on our plans, and we are open to suggestions for new extensibility points based on specific use cases.
Each use case listed above has an associated GitHub discussion, and we welcome and encourage anyone with questions, comments, or suggestions to contribute to the discussion.
We ask that requests for extensibility APIs are posted on our GitHub discussions board and that they include a concrete use case. It may be the case that we have something in place to help you already, so knowing the use case is very important.
Leave a Reply