remove call to $order_total_modules->process();

[proseLA]

pursuant to our conversation today, i think the following code changes will eliminate the bug associated with gift certificates.

we can change this line here:

one_page_checkout/includes/modules/pages/checkout_one_confirmation/header_php.php

Line 139 in 2839539

$order_total_modules->pre_confirmation_check();

to

    $calculatedTotal = $order_total_modules->pre_confirmation_check('string');
    $total = $calculatedTotal;
    if (is_array($calculatedTotal)) {
        $total = $calculatedTotal['total'];
    }

we can then delete line 185:

one_page_checkout/includes/modules/pages/checkout_one_confirmation/header_php.php

Line 185 in 2839539

$order_totals = $order_total_modules->process();

finally we need to change this section of code:

one_page_checkout/includes/modules/pages/checkout_one_confirmation/header_php.php

Lines 206 to 214 in 2839539

	if (($_SESSION['opc_saved_order_total'] ?? '') !== $currencies->value($order->info['total'])) {
	$error = true;
	$checkout_one->debug_message(
	"Order-total mismatch, before and after:\n" .
	json_encode($_SESSION['opc_saved_order_total'] ?? '', JSON_PRETTY_PRINT) . "\n" .
	json_encode($currencies->value($order->info['total']), JSON_PRETTY_PRINT)
	);
	$messageStack->add_session('checkout_payment', ERROR_NOJS_ORDER_CHANGED, 'error');
	}

to:

if (($_SESSION['opc_saved_order_total'] ?? '') !== $currencies->value($total)) {
    $error = true;
    $checkout_one->debug_message(
        "Order-total mismatch, before and after:\n" .
        json_encode($_SESSION['opc_saved_order_total'] ?? '', JSON_PRETTY_PRINT) . "\n" .
        json_encode($currencies->value($total), JSON_PRETTY_PRINT)
    );
    $messageStack->add_session('checkout_payment', ERROR_NOJS_ORDER_CHANGED, 'error');
}

the only reason i see calling the process method is to update the $order->info['total'] amount and use it for comparison to the opc saved value.

frankly i am surprised that this bug was not exposed earlier; but then again, maybe my payment module is the only one that needs the correct amount on the confirmation page?

as we saw, this is a definite bug as the amount going to the payment module using 3 page checkout was different from the amount going from OPC. and i have tracked that bug down to line 185.

[lat9]

Unfortunately, the input hints for currently-released Zen Cart versions (through zc210) for order_total::pre_confirmation_check will result in a PHP Fatal error if a string is passed:

    public function pre_confirmation_check(bool $returnOrderTotalOnly = false)

I'll need to find a compatible means ...

[lat9]

the only reason i see calling the process method is to update the $order->info['total'] amount and use it for comparison to the opc saved value.

frankly i am surprised that this bug was not exposed earlier; but then again, maybe my payment module is the only one that needs the correct amount on the confirmation page?

as we saw, this is a definite bug as the amount going to the payment module using 3 page checkout was different from the amount going from OPC. and i have tracked that bug down to line 185.

I've verified OPC's operation with a partial GC using both moneyorder and paypalr and don't see the order-total difference.

[lat9]

Since OPC gathers all the information in its confirmation page's header_php.php, that $order_total_modules->process(); needs to remain.

Noting that the reason that the call's not in the base Zen Cart's /includes/modules/pages/checkout_confirmation/header_php.php is that (tsk, tsk) the base implementation defers that processing to the page's template stage:

https://github.com/zencart/zencart/blob/8a19edeee418aa3fd737b1f52c5cc5300f4d6821/includes/templates/template_default/templates/tpl_checkout_confirmation_default.php#L157-L164

[proseLA]

Unfortunately, the input hints for currently-released Zen Cart versions (through zc210) for order_total::pre_confirmation_check will result in a PHP Fatal error if a string is passed:

public function pre_confirmation_check(bool $returnOrderTotalOnly = false)

I'll need to find a compatible means ...

strict typing is not required on this page; but i do understand the want to conform to strict types just so a motocross parts company store owner can remain happy.

this problem can be very much handled by checking one's zc version. alternatively one can do so using reflection:

function example(int $id, string $name): bool {
    return true;
}

$func = new ReflectionFunction('example');
echo $func->getName() . " signature:\n";

foreach ($func->getParameters() as $param) {
    $type = $param->getType();
    echo "- " . $param->getName() . ": " . ($type ? $type : 'mixed') . "\n";
}

$returnType = $func->getReturnType();
echo "Return type: " . ($returnType ? $returnType : 'mixed') . "\n";

[proseLA]

Since OPC gathers all the information in its confirmation page's header_php.php, that $order_total_modules->process(); needs to remain.

Noting that the reason that the call's not in the base Zen Cart's /includes/modules/pages/checkout_confirmation/header_php.php is that (tsk, tsk) the base implementation defers that processing to the page's template stage:

https://github.com/zencart/zencart/blob/8a19edeee418aa3fd737b1f52c5cc5300f4d6821/includes/templates/template_default/templates/tpl_checkout_confirmation_default.php#L157-L164

noting that your tsk, tsk does nothing to further the conversation....

also noting that if the base defers it to the template, what doesn't OPC???

when i talked about moving the processing out of the template and into the module, i did not see you making any comments.

the fact the base does it one way and OPC does it another way, (as you have conveniently highlighted in your own post) is all the more reason that they should both do it the same way.

i code payment modules. they work in standard ZC, they do not work in OPC. this has been an on-going battle. and i'm not really sure why.

you want to keep OPC the way it is, great, do it. but then fix the base ZC.

[lat9]

I'll reiterate my suggestion made to you via private message.

I can add a notification prior to the call to the order-totals' process method whereby you can indicate that the payment module is 'taking care' of that. If that's not acceptable, I'll consider this discussion concluded.

[lat9]

when i talked about moving the processing out of the template and into the module, i did not see you making any comments.

I would have been supportive at the time if I hadn't been laid up with a 103-degree temperature!