c7b4e3aa76
* use my-account/lost-password endpoint url for set password (tbd): - companion for working on https://github.com/woocommerce/woocommerce/issues/27754 * use more appropriate (new) set-password endpoint * add version check - use new woo core endpoint if woo version is new enough * use my-account/lost-password for setting password in checkout signup: - this has been available forever - no need for a version check - page will show `Lost password`; looking at options for overriding that * use more explicit `newaccount` action for set password url if available * tweak feature gating for checkout signup: - only available in dev builds (will change soon) - only available if Woo core 4.7 or newer - checkout signup relies on fixes in 4.7+ (tbc) to my-account/lost-password endpoint for setting initial password - standardise feature gate logic so is consistent, ensure feature is disabled in API/backend, hide editor option, and disable front end - add new setting `wcVersion` to allow feature gating on woo version * fix woo-version feature gate of checkout signup: - fixed version logic, explicit 4.7.0 reference version - refactor version compare routine so can be used for woo or WP version * revamp Woo 4.7+ logic so PHPunit tests aren't dependent on Woo version: - Woo-version feature gating is implemented at integration layer: - checkout REST API - register/override new account email handler |
||
|---|---|---|
| .. | ||
| active-filters | ||
| attribute-filter | ||
| cart-checkout | ||
| featured-category | ||
| featured-product | ||
| handpicked-products | ||
| price-filter | ||
| product-best-sellers | ||
| product-categories | ||
| product-category | ||
| product-new | ||
| product-on-sale | ||
| product-search | ||
| product-tag | ||
| product-top-rated | ||
| products | ||
| products-by-attribute | ||
| reviews | ||
| single-product | ||
| README.md | ||
README.md
Blocks
Our blocks are generally made up of up to 4 files:
|- block.js
|- editor.scss
|- index.js
|- style.scss
The only required file is index.js, this sets up the block using registerBlockType. Each block has edit and save functions.
The scss files are split so that things in style are added to the editor and frontend, while styles in editor are only added to the editor. Most of our blocks should use core components that won't need CSS though.
Editing
A simple edit function can live in index.js, but most blocks are a little more complicated, so the edit function instead returns a Block component, which lives in block.js. By using a component, we can use React lifecycle methods to fetch data or save state.
The Newest Products block is a good example to read over, this is a simple block that fetches the products and renders them using the ProductPreview component.
We include settings in the sidebar, called the Inspector in gutenberg. See an example of this.
Other blocks have the concept of an "edit state", like when you need to pick a product in the Featured Product block, or pick a category in the Products by Category block.
Saving
Usually blocks can be converted to HTML in the save function, so that what's saved into the database is the same HTML that's rendered on the frontend. Our blocks are different since they need to show the latest products and reflect any changes to products.
The grid blocks are saved as shortcodes using getShortcode, but the Featured Product block is considered a "dynamic block", so we use PHP to build that each time the post is loaded on the frontend. The code for that is set up when the block is registered in PHP, and lives in WGPB_Block_Featured_Product.