5850966894
* initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic |
||
|---|---|---|
| .. | ||
| 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 | ||
| 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.