New filter request

Resolved Simon Kane
(@simonkane)

4 years, 4 months ago
I’ve got a custom order status that should be “payable”,
but the “Pay For Order” button does not show because:

includes/admin/meta-boxes/class-wc-stripe-admin-order-metaboxes.php:57
```
public static function pay_order_section( $order ) {
	if ( $order->get_type() === 'shop_order' && $order->has_status( array( 'pending', 'auto-draft' ) ) ) {
```
Hard-coded list in the “has_status”.
Maybe also allow for types other than ‘shop_order’, too.

How about this?
```
public static function pay_order_section( $order ) {
		$allow_show = $order->get_type() === 'shop_order' && $order->has_status( array( 'pending', 'auto-draft' ) );
	if ( apply_filters('wc_stripe_show_pay_order', $allow_show, $order) ) {
```
The page I need help with: [log in to see the link]

Viewing 7 replies - 1 through 7 (of 7 total)

Plugin Author Clayton R
(@mrclayton)

4 years, 4 months ago

Hi @simonkane,

I’ll make a note to include a filter for additional statuses. The shop order is the only post type that is relevant for paying for an order. Other post types may not be compatible and error prone.

Kind regards,

Thread Starter Simon Kane
(@simonkane)

4 years, 4 months ago

Thank you!

Might there be any timeframe for this?

Also, I am finding that there are plugins out there that define custom objects based on WC_Order (‘shop_order’) just as:
woocommerce/includes/class-wc-order.php:16
`class WC_Order extends WC_Abstract_Order {‘
If the custom order type extends WC_Order, without touching the things you touch,
it wouldn’t be a problem for the payment gateway – and for the same reasons.

You (very correctly):
‘class WC_Payment_Gateway_Stripe_CC extends WC_Payment_Gateway_Stripe {‘
which is in turn:
‘abstract class WC_Payment_Gateway_Stripe extends WC_Payment_Gateway {‘

I was wondering how I was going to handle a client requested enhancement
until I ran into the fact that the above is possible. I haven’t written it yet,
and my extended WC_Order likely won’t need this, but the overall community might.

As for being “error prone” and having compatibility issues,
isn’t that true for any filter?
If the user’s filter code is written incorrectly, it could break anything –
and it’s not your responsibility.
This has been a truism since IBM invented “user exits” in the mid-1970s.
Plugin Author Clayton R
(@mrclayton)

4 years, 4 months ago
Might there be any timeframe for this?

I like to group code changes together in a release so no I don’t have a timeline. Based on past releases, it will be a week or two. You’re welcome to contact us via the support button if you want an advanced copy.

As for being “error prone” and having compatibility issues,
isn’t that true for any filter?

Most extensions aren’t going to override the WC_Order::get_type method because that describes the underlying post type. It’s the order object that you want to process a payment for. For example, we don’t render the Pay for Order functionality for subscriptions (they override get_type()), because it’s the order that payment is actually processed for. The subscription is a child of the initial order, then each recurring payment has it’s own renewal order. Everything goes back to the order object to represent the payment.

As for being “error prone” and having compatibility issues,
isn’t that true for any filter?

Yes, but I don’t want someone rendering the Pay for Order functionality for some custom post type that has no relevancy to an order and then wondering why the plugin “isn’t working.”
- This reply was modified 4 years, 4 months ago by Clayton R.
Thread Starter Simon Kane
(@simonkane)

4 years, 4 months ago

Right – but again, somebody doing something stupid is not your problem. 😉

No big deal – I don’t need that side of it. 🙂

Plugin Author Clayton R
(@mrclayton)

4 years, 3 months ago

Filter wc_stripe_pay_order_statuses added in version 3.3.11.

Thread Starter Simon Kane
(@simonkane)

4 years, 2 months ago

@mrclayton The filter works just fine to enable the “Pay for Order” button, but the button throws a modal error box instead of processing the payment:
‘You must create the order before payment can be processed.’

It turns out there’s a hard-coded check for order status = ‘pending’ in script:
/woo-stripe-payment/assets/js/admin/meta-boxes-order.js:120

The “triggering” PhP is at:
woo-stripe-payment/includes/admin/meta-boxes/class-wc-stripe-admin-order-metaboxes.php:81

I did a quick hack of that line to:
‘order_status’ => ‘pending’, // $order->get_status(),
And the “credit card” box pops up just fine, and the payment processes (in test mode).

Note that the default “allowed status” array includes status ‘auto-draft’ (…/class-wc-stripe-admin-order-metaboxes.php:58) which will probably cause the same modal error popup. I would guess that’s some kind of testing hook left in production code.

Also, the “Pay” button on the front-end orders list page shows without using this filter (but with use of standard Woo filters), and if I remember correctly, payments work just fine with statuses other than ‘pending’, but I have not had time to actually test that at the moment.

In any event, payment processing should not be dependent on the actual value of the order’s “internal woo-status”, especially now that the new filter exists.

Plugin Author Clayton R
(@mrclayton)

4 years, 2 months ago

Hi @simonkane,

Just now seeing this message. Will update in the next release.

Kind Regards,

Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘New filter request’ is closed to new replies.