This commit fixes a bug that made it impossible to assign to a product a tax class that contained non-ASCII characters that are URL encoded by sanitize_title().
WooCommerce uses sanitize_title() to generate a slug when creating a tax class (d48f1d4e2e/includes/class-wc-tax.php (L808)). sanitize_title() converts some non-ASCII to ASCII equivalents (those handled by remove_accents()) and URL encodes others (like some Greek characters, for example).
The code was using wc_clean() to sanitize the tax class when the user edited a product. The problem is that wc_clean() removes URL encoded characters, changing the slug of some tax class, causing WooCommerce to use the standard tax class instead without any errors. To fix this issue, this commit replaces wc_clean() with sanitize_title(). This should be enough for security purposes and should not cause any issues with non-ASCII characters.
This commit changes the condition in the if the statement that decides
whether or not to display the "Paid by customer" section in the order admin
page. Before it, this section was displayed for all orders that
contained one of the following statuses: 'processing', 'completed' or 'refunded'.
The problem with this approach is that offline payment gateways, like
'Cash on Delivery', set the order status to processing when the order is
placed but before the customer pays for it. So the "Paid by customer"
section was being displayed in some cases where the order was not
actually paid yet creating a confusing experience to store managers.
To fix this, this commit also checks for the presence of the
`_date_paid` order meta. If this order meta is present and the order
status corresponds to one of the three statuses listed above, it means that
the order has been paid and we can display the "Paid by customer"
section. If this order meta is not present, we don't display the "Paid
by customer" section.
WordPress Coding Standard 2.0 removed the sniff
WordPress.Security.NonceVerification.NoNonceVerification:
```
The WordPress.Security.NonceVerification sniff used the same error code for both an error as well as a warning.
The old error code NoNonceVerification is no longer used.
The error now uses the Missing error code, while the warning now uses the Recommended error code.
```
(from
d45f5e5cf3/CHANGELOG.md (200-rc1---2018-12-31))
This commit updates WooCommerce code and replaces all instances where WordPress.Security.NonceVerification.NoNonceVerification verification was used with either WordPress.Security.NonceVerification.Missing or
WordPress.Security.NonceVerification.Recommended. In a few cases WordPress.Security.NonceVerification.NoNonceVerification was used but was not needed, so instead of replacing the sniff, the line was removed. In two other cases, I removed other unrelated sniffs that were not needed.
The default value ('no') of the setting to round taxes at subtotal was not being honored on the Edit Order screen, which resulted in off-by-one discrepancies between the checkout item total and the edited or refunded item total.
This change is to round to the proper precision (w.r.t. the 'woocommerce_tax_round_at_subtotal' setting) for the default value of the form, as well as when the values are dynamically recomputed.