Switching over to building the table with JS — wp.template.
We are now using the same JS template for existing rows and newly
generated rows on the fly — this should simplify things moving forward.
I’ve also started building stuff in an external JS file rather than
straight on the page. Will continue migrating things to it and
localizing as needed.
Saved ( 2 * displayed tax rates - 1 ) db queries per page load by doing
the locations all in one query and then parceling them out in php.
More coming.
This is by no means complete. A number of things need to be relocated
and optimized still, but it does a rough search, purely in JS, and
highlights the results in yellow.
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.
George Stephanis
Mike Jolley
Shiva Poudel
Claudio Sanches
Nicola Mustone
Nicola Mustone
toddlahman
Fredrik Rossland
Brent Shepherd
JeroenSormani
nils-fredrik@maksimer.no