That was (accidentally?) removed with SHA: 877e39064
Fixes "PHP Notice: Undefined variable: items" when attempting to get
line items of a type that does not exist on the order, like coupons.
When inserting a new set of API keys via the visual API endpoint, only 5 format
values were specified in the 3rd param passed to the $wpdb->insert(); however,
6 values were specified in the 2nd param. This meant that the truncted_key value
was being formatted as an integer only the first numerical characters of the last
7 character of the consumer key were being stored. For example, given a consumer
key value of ck_e91f2aeae6c3dea3045293a3dbdf55c317ad762c the truncated_key value
should be 7ad762c but instead, it was being stored at 7.
Sanitize early, escape late. Rather than double escaping, I figured
it’d be better to sprintf it in, and then escape that string — closer
to the output.
Also, I’m not sure why `urlencode` was used to escape a name?
There’s a lot of them, so I’m breaking them into multiple commits.
This is safeguarding stuff in case some translation uses a double
quote, it will no longer risk breaking out of the attribute.
array_filter() expects parameter 1 to be array, boolean given
/wp-content/plugins/woocommerce/includes/admin/class-wc-admin-duplicate-
product.php(171)
$exclude is evaluated as a boolean.
WooCommerce prior to WC 2.4 saved the product type before any variations were saved because
WC_Meta_Box_Product_Data::save_variations() was called by WC_Meta_Box_Product_Data::save().
However, in WC 2.4 the variations are saved independently of other data about the containing
variable product, including product type. Because the product type hasn't been saved yet,
extensions that need to save their own variation level meta data can't know when saving
variations if the product is of the type they want to act on. They also can't check `$_POST`
to find out when saving variations, because 'product-type' isn't passed to that as it's
variable level meta data, not variation level meta data.
This patch passes the product type along with the variation level meta data when saving variations.
It then uses that to save the product type if the variable product has not yet been saved (and
therefore the product type has never been stored, which means calling get_product() would instantiate
a 'simple' product, as that is the default product type). This can lead to fatal errors if callbacks
expect the product type to be variable and attempt to call methods that only exist on those product
types, like variable_product_sync().
It will also update the product type if it was previously saved but has since changed. This prevents
fatal errors like that mentioned above but caused by switching from one product type, like a simple
product, to another, like a variable product.
For Subscriptions v2.0.
* Use new 'woocommerce_subscription_failing_payment_method_updated_' hook
* Use new wcs_is_subscription() method to run process_subscription() when the
transaction is for a subscription object.
* Save the card and customer IDs on the 'shop_subscription' post from the renewal
order rather than saving it on the order which purchased the subscription.
* Add new save_subscription_meta() method to allow us to save customer ID both
in Subscriptions 1.n on the original order and in 2.0 on the subscription/s
created for the order)
* Use the new 'woocommerce_scheduled_subscription_payment_simplify' hook and
deprecate use of the old 'scheduled_subscription_payment_simplify' hook by
moving it to the WC_Addons_Gateway_Simplify_Commerce_Deprecated class
* Use core WC methods on the renewal order passed to scheduled_subscription_payment()
to process the payment rather than having to call special Subscriptions API methods
like WC_Subscriptions_Manager::process_subscription_payments_on_order() and
WC_Subscriptions_Manager::process_subscription_payment_failure_on_order()
* Use the original order's total to determine the amount to charge up-front to
save having to call WC_Subscriptions_Order::get_total_initial_payment()
* Use a description for recurring payments that is consistent with standard orders,
i.e. "{Site Name} - Order {order_id}" instead of a description that does not include
the renewal order's ID. This helps link payments to orders (which can then be traced
to subscription/s).
Mike Jolley
Brent Shepherd
Claudio Sanches
Doug Smith
Shiva Poudel
George Stephanis
Nicola Mustone
Nicola Mustone
toddlahman
Fredrik Rossland
JeroenSormani
nils-fredrik@maksimer.no
WordCommerce
Tamara Zuk