Payment tokens was introduced in 2.6 and was updated to use the new CRUD code while some of the CRUD system was still in flux.
While most things were correct, the prop handling for custom fields (like a card's last 4 digits) were directly calling meta functions, instead of delegating to the data store/parent.
This PR moves these props to `extra_data` and follows the same pattern as product types or order items. It also updates some version tags to 3.0.0. Finally, it adds an additional test for saving meta after a create which looks like it was lacking.
To Test:
* Run `phpunit`.
* Go to the "My Account" tab and add a new payment method. You need a payment gateway that supports this, like Simplify.
* Test the add a payment method flow.
* Make a test purchase using the saved payment method.
The cache busting currently in `wc_add_order_item_meta`, `wc_update_order_item_meta`, and `wc_delete_order_item_meta` doesn't actually bust anything. The cache line looks like it is from 2.6. The relevent cache to bust is actually in the `order-items` group and has a different key/prefix.
This bug allows your meta to get out of sync if you use these functions and then try to access a value from a CRUD object.
You can see this in the `test_wc_order_item_meta_functions` test I've added. If you keep your `wc-order-item-functions.php` as is, the asserts against `$item->get_meta` will fail.
To test:
* `phpunit --filter=test_wc_order_item_meta_functions`.
* Try before applying the `wc-order-item-functions.php` changes and after.
In 2.6, you could access the amount via $coupon->coupon_amount. Or legacy code incorrectly handles $coupon->amount instead. 7778583340/includes/class-wc-coupon.php (L102)
This PR handles both since the RCs and betas allowed `->amount` and I don't want to break anything that may be accessing it that way..
To Test:
* `phpunit --filter=test_coupon_backwards_compat_props_use_correct_getters`
Claudio Sanches
Mike Jolley
Claudiu Lodromanean
Justin Shreve