f000fb4f7a
* prototype 'create account' checkbox in checkout block
* expose store config for generating password/username to blocks:
+ use FILTER_VALIDATE_BOOLEAN instead of hard-coded `yes`
* stub out signup form in checkout block
* context / provider to store checkout signup form data
* revert signup form - checkout block will always generate username etc
* persist signup checkbox in checkout state & pass to checkout API
* add `create_account` param to order API, fix name in client POST
* handle creating user account as part of order (first cut)
* ensure the order is associated with the new customer
* only show 'create account' checkbox when appropriate (guest checkout)
* remove unnecessary username/password variables
* refactor account-creation logic into functions:
- clarify inputs and outputs
- use RouteException for error handling
- use woo options directly, avoid dependency on WC_Checkout
* update "email exists" error message to use existing error message text
* handle all known errors from wc_create_new_customer + use core message
* only show "create account" checkbox to shopper when necessary:
- if guest checkout is disabled, user must create account - not optional
* only show "create account" if account creation is optional:
- fixes incorrect logic in previous commit
- add some comments to clarify
* fix create account logic in API when checkout requires account:
- use correct woo setting option name
- reverse logic to match option = allow guest false means registration required
* strip html tags from create account error messages
* temporarily force enable autogenerate user/pass in new account API
* fix rebase errors
* add new allowCreateAccount attribute in checkout block
* show/hide `Create account` checkbox dependent on block attribute:
- previously was dependent on store setting
* new create user API, with set initial password email (first cut):
- use core register_new_user for creating the user
- this triggers core "set new password" email
- generate username using logic lifted from WC core
- rough cut, lots to tidy/polish here
* remove alternative/unused create account function
* set `Customer` role for signups during checkout
* eslint fix - switch case break
* remove comments that mirror code & might go stale
* tidy func comment
* remove unused function
* use store setting `allow signup` for default value of new block option
* refactor order signup logic to service class first cut:
- new CreateAccount service
- hook up via custom action (for now at least)
- paste over existing create account logic (temporary - will be replaced)
* adapt wc_create_new_customer logic in CreateAccount service (WIP)
* set default_password_nag on new account + throw instead of WP_Error
* rename `createAccount` => `shouldCreateAccount` to clarify meaning
* fix checkout block - renamed `shouldCreateAccount` (missed in prev commit)
* prototype sending alternative email template for checkout signup
* add magic link to set password to blocks new account html email
* tidy up new account email templates - set password link, subject/heading
* use same id so merchant setting tweaks apply to our new improved email
* remove logging
* code tidies in CreateAccount service:
- remove unnecessary constructor
- type-hint in should_create_customer_account
- streamline logic in should_create_customer_account - remove
unnecessary `empty` check
- add comments to illuminate different use-cases handled by should_create_customer_account
* don't provide password to new account email templates (no longer used)
* declare dependencies in root namespace
* code tidies on new account email class:
- correct namespace and camelcase name
- declare class in file, don't instantiate; instantiate in client code
(CreateAccount service) when used
- no require/file import, use `use`
* move CustomerNewEmail to folder matching namespace
* use Package->get_path for email template paths:
- CreateAccount service now depends on Package
- CreateAccount passes Package to email class so it can use `get_path`
- note: CustomerNewAccount is not registered with DI container as it
needs to be instantiated after Woo init (for `WC_Email`)
- shift email templates to {plugin}/templates, consistent with WP
convention
* call CreateAccount::from_order_request directly, no custom hook:
- custom hook is not appropriate as we may not want to allow
extensibility in this way - TBD
* add appropriate margin above create account checkbox
* remove unnecessary direct-access protection
* generalise name of error-handling method
* simplify CustomerNewAccount - instantiate directly, when needed
* remove unused new_account_email member - now instantiated on demand
* numerous fixes and updates due to rebase changes
* fix typo in name of CustomerNewAccount php file (missing `n`)
* experiment - link to lost-password form in my-account (prototype branded screen)
* Revert "experiment - link to lost-password form in my-account (prototype branded screen)"
This reverts commit e1dc6dd5e9f0218ede81da92188d813c2d0856d9.
* feature gate CreateAccount service init to dev build only +
+ remove stale comment
* feature gate front end "Create account" checkbox to feature plugin only
* feature gate editor "allow signup" option to dev build only
* feature gate checkout api create account - dev build only
* tweak feature gating PHP logic so it's robust:
- all PHP feature gating is in the service class
- all publicly-available methods return early if feature gate off
- Checkout rest API transparently calls service - no explicit feature
gate at API level
* ensure frontend/editor features are feature gated (isExperimentalBuild is a function)
* feature gate value of checkoutAllowsSignup - can only be true in feature plugin
* fix a / an typo in comment
Co-authored-by: Albert Juhé Lluveras <contact@albertjuhe.com>
* remove commented code
* hello world unit test (doesn't test anything yet)
* add a command for running unit tests when container already up:
- this should probably move to another PR/branch
* basic tests of core logic in CreateAccount service
* import isExperimentalBuild direct:
- import from alias package was causing an issue, likely a dependency cycle
* refactor from_order_request to return new user ID so it's easier to test
* test creating a customer from an order + rest request:
- i.e. a full end-to-end integration test
* delete redundant test and tidy comments
* generalise test to provider format
* refactor create-dup-user err test to use same approach as success test
* add test for when user should not be created
* don't hard-code options in "create" test, remove redundant provider in no-account-requested test
* de-generalise "user already signed up" test
* add test for malformed email
* flesh out & comment successful signup tests
* flesh out "invalid email" tests
* clarify no account requested test comment
* remove phpunit:quick - I don't think it's needed
* add comment explaining this is an integration test
* experiment – disable feature flag, is this why the tests are failing?
* revert test commit - restore feature gate (experimental flag)
* skip all tests if CreateAccount is disabled due to feature flag
* d'oh - expose CreateAccount:is_feature_enabled so can be used in tests
* add jsdoc for checkout-state shouldCreateAccount field
* remove unnecessary comment + fix whitespace/indentation
* simulate logged-out user for createaccount signup tests
* use a single, compound if statement for early return (review nitpick)
* don't hide `checkoutAllowsSignup` store setting behind feature flag:
- the feature flag should be used to enable/disable behaviour
- it's dangerous to adjust store settings/options based on feature flag
* rejig tests so they require woocommerce_blocks_phase==3:
- make feature gate method private to avoid exposing
- remove feature flag check & test skip for other builds
- set blocks phase in travis config
* remove redundant user-logout in test setup - cleaner to just require this
* use WP function bracket style (same line)
Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
Co-authored-by: Albert Juhé Lluveras <contact@albertjuhe.com>
|
||
|---|---|---|
| .. | ||
| 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.