When SHA: 7b3a9b introduced wc_get_email_order_items(), it slightly
changed the logic applied to determine whether to display:
* download links; and
* purchase notes.
In WC 2.6.13 and older, WC_Abstract_Order::email_order_items_table()
would only display download links and purchase note in emails *not*
sent to the admin. This patch preserves that behaviour.
Rather than requiring child classes to merge it as well as define it.
If it's not defined in a child class, then the merge call will have no
effect as it will be an the empty array set in WC_Data, if they do define
it, WC_Data will now take care of it automatically rather than requiring
manually merging it in the child class's constructor before it has any
effect on that objects data.
This helps reduce duplicate code by removing this from child classes, and
in some cases, being able to remove the child constructor definitions
entirely. It also avoids a gotcha for developers setting their own
$extra_data values only to find they aren't being set on the $data
property.
So that classes which extend WC_Abstract_Order can define custom statuses
specifically for their order type and have those used for validation in
WC_Abstract_Order::set_status() instead of only the order statuses defined
by wc_get_order_statuses().
For example, the subscription order type has a number of custom order statuses,
like 'wc-active' and 'wc-expired', which do not apply to orders but are valid
statuses for WC_Subscription objects, which extend WC_Abstract_Order.
Prior to SHA: 43d362d1, WC_Checkout::get_value() would set the default value
for an $input whenever the value after was null after being passed through
filters. This logic changed with SHA: 43d362d1 to *always* return the filtered
value, even if the value was not changed by filters and was still null.
This means if any code filters just one checkout value, like order_comments,
then all other checkout values will default to null, because the has_filter()
check will pass, but the default null value won't be modified by that callback.
Even though I'm sending `position` as integer in my REST request, it comes through as string value.
```
array (
'id' => '186',
'position' => '0',
)
```
Claudio Sanches
Mike Jolley
Boro Sitnikovski
Brent Shepherd
Claudiu Lodromanean
Caleb Burks
Chris Lam
Frédéric Demarle
Toni Viemerö