"description":"Fires when an item is added to the cart.",
"long_description":"This hook fires when an item is added to the cart. This is triggered from the Store API in this context, but WooCommerce core add to cart events trigger the same hook.",
"content":"Matches action name in WooCommerce core."
},
{
"name":"param",
"content":"ID of the item in the cart.",
"types":[
"string"
],
"variable":"$cart_id"
},
{
"name":"param",
"content":"ID of the product added to the cart.",
"types":[
"integer"
],
"variable":"$product_id"
},
{
"name":"param",
"content":"Quantity of the item added to the cart.",
"types":[
"integer"
],
"variable":"$request_quantity"
},
{
"name":"param",
"content":"Variation ID of the product added to the cart.",
"types":[
"integer"
],
"variable":"$variation_id"
},
{
"name":"param",
"content":"Array of variation data.",
"types":[
"array"
],
"variable":"$variation"
},
{
"name":"param",
"content":"Array of other cart item data.",
"types":[
"array"
],
"variable":"$cart_item_data"
}
],
"long_description_html":"<p>This hook fires when an item is added to the cart. This is triggered from the Store API in this context, but WooCommerce core add to cart events trigger the same hook.</p>"
"description":"Fires when the woocommerce blocks are loaded and ready to use.",
"long_description":"This hook is intended to be used as a safe event hook for when the plugin has been loaded, and all dependency requirements have been met.\n To ensure blocks are initialized, you must use the `woocommerce_blocks_loaded` hook instead of the `plugins_loaded` hook. This is because the functions hooked into plugins_loaded on the same priority load in an inconsistent and unpredictable manner.",
"long_description_html":"<p>This hook is intended to be used as a safe event hook for when the plugin has been loaded, and all dependency requirements have been met.</p> <p>To ensure blocks are initialized, you must use the <code>woocommerce_blocks_loaded</code> hook instead of the <code>plugins_loaded</code> hook. This is because the functions hooked into plugins_loaded on the same priority load in an inconsistent and unpredictable manner.</p>"
"description":"Fires when the IntegrationRegistry is initialized.",
"long_description":"Runs before integrations are initialized allowing new integration to be registered for use. This should be used as the primary hook for integrations to include their scripts, styles, and other code extending the blocks.",
"long_description_html":"<p>Runs before integrations are initialized allowing new integration to be registered for use. This should be used as the primary hook for integrations to include their scripts, styles, and other code extending the blocks.</p>"
},
"args":1
},
{
"name":"woocommerce_check_cart_items",
"file":"StoreApi/Utilities/CartController.php",
"type":"action",
"doc":{
"description":"Fires when cart items are being validated.",
"long_description":"Allow 3rd parties to validate cart items. This is a legacy hook from Woo core. This filter will be deprecated because it encourages usage of wc_add_notice. For the API we need to capture notices and convert to wp errors instead.",
"content":"Matches action name in WooCommerce core."
}
],
"long_description_html":"<p>Allow 3rd parties to validate cart items. This is a legacy hook from Woo core. This filter will be deprecated because it encourages usage of wc_add_notice. For the API we need to capture notices and convert to wp errors instead.</p>"
},
"args":0
},
{
"name":"woocommerce_created_customer",
"file":"StoreApi/Routes/V1/Checkout.php",
"type":"action",
"doc":{
"description":"Fires after a customer account has been registered.",
"long_description":"This hook fires after customer accounts are created and passes the customer data.",
"description":"Fires before a customer account is registered.",
"long_description":"This hook fires before customer accounts are created and passes the form data (username, email) and an array of errors.\n This could be used to add extra validation logic and append errors to the array.",
"content":"Matches filter name in WooCommerce core."
},
{
"name":"param",
"content":"Customer username.",
"types":[
"string"
],
"variable":"$username"
},
{
"name":"param",
"content":"Customer email address.",
"types":[
"string"
],
"variable":"$user_email"
},
{
"name":"param",
"content":"Error object.",
"types":[
"\\WP_Error"
],
"variable":"$errors"
}
],
"long_description_html":"<p>This hook fires before customer accounts are created and passes the form data (username, email) and an array of errors.</p> <p>This could be used to add extra validation logic and append errors to the array.</p>"
"description":"Fires an action after a shipping method has been chosen for package(s) via the Store API.",
"long_description":"This allows extensions to perform addition actions after a shipping method has been chosen, but before the cart totals are recalculated.",
"tags":[
{
"name":"since",
"content":"9.0.0"
},
{
"name":"param",
"content":"The sanitized ID of the package being updated. Null if all packages are being updated.",
"types":[
"string",
"null"
],
"variable":"$package_id"
},
{
"name":"param",
"content":"The sanitized chosen rate ID for the package.",
"types":[
"string"
],
"variable":"$rate_id"
},
{
"name":"param",
"content":"Full details about the request.",
"types":[
"\\WP_REST_Request"
],
"variable":"$request"
}
],
"long_description_html":"<p>This allows extensions to perform addition actions after a shipping method has been chosen, but before the cart totals are recalculated.</p>"
"description":"Fires before an order is processed by the Checkout Block/Store API.",
"long_description":"This hook informs extensions that $order has completed processing and is ready for payment.\n This is similar to existing core hook woocommerce_checkout_order_processed. We're using a new action: - To keep the interface focused (only pass $order, not passing request data). - This also explicitly indicates these orders are from checkout block/StoreAPI.",
"long_description_html":"<p>This hook informs extensions that $order has completed processing and is ready for payment.</p> <p>This is similar to existing core hook woocommerce_checkout_order_processed. We're using a new action:</p> <ul> <li>To keep the interface focused (only pass $order, not passing request data).</li> <li>This also explicitly indicates these orders are from checkout block/StoreAPI.</li> </ul>"
"description":"Fires before an order is processed by the Checkout Block/Store API.",
"long_description":"This hook informs extensions that $order has completed processing and is ready for payment.\n This is similar to existing core hook woocommerce_checkout_order_processed. We're using a new action: - To keep the interface focused (only pass $order, not passing request data). - This also explicitly indicates these orders are from checkout block/StoreAPI.",
"long_description_html":"<p>This hook informs extensions that $order has completed processing and is ready for payment.</p> <p>This is similar to existing core hook woocommerce_checkout_order_processed. We're using a new action:</p> <ul> <li>To keep the interface focused (only pass $order, not passing request data).</li> <li>This also explicitly indicates these orders are from checkout block/StoreAPI.</li> </ul>"
"description":"Fires when the Checkout Block/Store API updates an order's meta data.",
"long_description":"This hook gives extensions the chance to add or update meta data on the $order. Throwing an exception from a callback attached to this action will make the Checkout Block render in a warning state, effectively preventing checkout.\n This is similar to existing core hook woocommerce_checkout_update_order_meta. We're using a new action: - To keep the interface focused (only pass $order, not passing request data). - This also explicitly indicates these orders are from checkout block/StoreAPI.",
"long_description_html":"<p>This hook gives extensions the chance to add or update meta data on the $order. Throwing an exception from a callback attached to this action will make the Checkout Block render in a warning state, effectively preventing checkout.</p> <p>This is similar to existing core hook woocommerce_checkout_update_order_meta. We're using a new action:</p> <ul> <li>To keep the interface focused (only pass $order, not passing request data).</li> <li>This also explicitly indicates these orders are from checkout block/StoreAPI.</li> </ul>"
"description":"Fires during validation when adding an item to the cart via the Store API.",
"long_description":"Fire action to validate add to cart. Functions hooking into this should throw an \\Exception to prevent add to cart from happening.",
"content":"Product object being added to the cart.",
"types":[
"\\WC_Product"
],
"variable":"$product"
},
{
"name":"param",
"content":"Add to cart request params including id, quantity, and variation attributes.",
"types":[
"array"
],
"variable":"$request"
}
],
"long_description_html":"<p>Fire action to validate add to cart. Functions hooking into this should throw an \\Exception to prevent add to cart from happening.</p>"
