robertrosanke

Hello @inpsydekrystian ,

Thank you for your detailed response.
I really appreciate that you want to help us, as correct payment processing is essential.
Stripe plugin support, for example, simply rejected me. They are acting as if my request were a custom code request. 😮

I looked at our settings. We have set intent = CAPTURE. That should take care of everything, and we don’t have to do anything manually for PayPal orders, as far as I understand?

I didn’t attach the system report. We probably don’t need it anymore. (To be honest, we also have a lot of individual extensions and database tables in the shop that I don’t want to leak. If we need it, I’ll take care of removing the sensitive parts and send you the report. Otherwise, I’d rather save myself the effort.)

I just want to briefly share the current status of the investigation, because I gained some new insights today.

• I monitor all relevant REST requests and have integrated a few log points directly into the WooCommerce code so that we can gain insights from real orders.
• It currently looks as if no order-status-changed-hooks are firing when foreign-language orders are processed via REST when using WPML, specifically WCML, with WooCommerce >= 10.0.x.

The cause seems to lie in the following pull request, which made it into WC 10.0.x: https://github.com/woocommerce/woocommerce/pull/46887/files

Before that, everything was fine, including for us. We have only been affected since the update from WooCommerce 9.9.x to 10.0.x in combination with WCML 5.5.1. Both were updated on the same day.

The get_changes() check for the variable $order_items_persisted is always false because WCML converts the product IDs and names to the base shop language. I traced their code to find out and logged the get_changes() output. For all foreign language orders, this results in a deviation and the entire code block, which is so important, is not executed via REST requests:
https://github.com/axi/woocommerce/blob/4285cb2e1665b6b9e503f1d14a97235e6d5a25a2/plugins/woocommerce/includes/class-wc-order.php#L430

At least that’s how it looks at the moment. I will continue to check the behavior with the next orders that are processed via REST.

Edit: Just to clarify. I would like to point out that orders placed with us in recent weeks are affected. So we’re not just talking about a handful. That’s why I’m explicitly asking for the correct way to proceed.

Processing one order incorrectly might be acceptable, but not many.

Edit: Close ticket.

Hello @mosesmedh ,

We tested the update to 9.9.2 today and it fixes the display issues. Thank you very much for your quick response and the speedy update by the plugin developers.

Have a great week!

Hello Sai,

Thank you for your response and patience!

We have reconnected Stripe and there do not appear to be any issues at first glance.

The communication in the UI was somewhat misleading. When I disconnect an account, the plugin tells me that I need a new Stripe account if I want to reconnect. Perhaps you could improve the wording for the disconnect/reconnect process to better support users during this procedure.

The ticket can be closed. Thanks for your help.

Hello @klarna ,

thanks for the update.

A cronjob could probably help us, yes.
But I don’t understand why every store owner who wants to use Klarna via your plugin has to program it manually.

An out of the box solution should be much more efficient and valuable for your customers.

For example, you could add a function in the plugin settings: Automatically set orders to “failed” after x hours. Anyone who activates this option already knows why they are doing so, and that’s the end of the matter.
You could also create an entry in the order notes that informs the shop operator that the order has automatically been set to failed because Klarna has not given the green light for x hours.

That’s the end of the matter, without adding manual effort for every store operator.

@louisekrokedil :

To be honest, I was confused about the link you showed (https://docs.krokedil.com/krokedil-general-support-info/pending-payment-orders-and-held-stock/).

I don’t like what the “Changed pending payment orders” section says about creating multiple orders for just one customer.

Earlier in this thread I described how PayPal, for example, simply sends the user back to the checkout if you cancel in the PayPal popup and there are not multiple orders in the system for this one customer.
Especially if you want to automate processes, in this case e.g. the payment reminder in case of problems, it worries me that a customer with one checkout process may have two orders in the WooComerce system.

The “second order” may go through as paid, while the “first”, pending order is then set to failed by the cronjob and the customer receives a message that the payment has failed and they should pay again.

I can hardly tell my customer, for whom I’m writing this thread, about this behavior without him thinking I’m joking.

It’s not meant to be malicious. It’s more like honest feedback so that we can initiate improvements together.

I also have customers who wouldn’t care about the behavior because they only have a few orders and process them manually.

However, anyone who relies on reliable automation is probably not satisfied with the current situation. It seems immature compared to other payment solutions for WooCommerce (PayPal, Stripe).

Hello @doublezed2 ,

Unfortunately, even with rollbacks up to version 9.4.0, I couldn’t find out when the problem started.
It may have existed for some time, and we only noticed it recently.

Perhaps we can relabel the topic from “Error” to “Suggestion for improvement”.

Proposal

It would be good if there were a PHP filter that allows developers to choose between a server-side and a client-side preselection of a product variant for product pages of variable products with attribute_pa_* properties in the query parameters.

Use case

The use case clearly relates to online stores that send users directly to product pages that preselect properties via URL.
This is common for Google Shopping Ads, for example. Performance is important there, so we as store operators are very interested in delivering such specific variant page views via cache (e.g. via WP Rocket).
We therefore cache a product page without preselection and deliver this cached version, regardless of which query parameters are in the URL.
To ensure that the whole process runs smoothly, the product variant should then be selected on the client side via JavaScript after the cached product page has been delivered.

Implementation

By default, it can remain as it is.
On the server side in wc_dropdown_variation_attribute_options(), select the variants that can be read in the URL.

If the filter described above is used by a developer to perform the preselection on the client side, the following should happen:

1.) The function wc_dropdown_variation_attribute_options() or its caller ensures that only the product variation defined as the preferred variant in the backend is marked as “selected” in the HTML on the server side and delivered. (Or no variation if no preferred variation has been defined by the store operator). The query parameters in the URL are therefore ignored during server-side HTML generation.
2.) On the client side, i.e. via JavaScript, the possibly existing query parameters in the URL of a product page should be synchronized with the selectable product properties. This means: If, for example, ?attribute_pa_color=red is in the URL, then the WooCommerce JavaScript should automatically select the red product variant, if possible.

Here is an example of JavaScript code that only refers to the color example.
If you were to implement it ready for production, you would probably first go through all the properties in the add to cart form in a loop, then check the query parameters associated with the individual select fields and set any values found accordingly via JavaScript.

function initSingleProductPageVariationsForm() {
	const searchParams = new URLSearchParams(window.location.search);
	const COLOR_ATTR = "attribute_pa_color";
	const queriedValue = searchParams.has(COLOR_ATTR) ? searchParams.get(COLOR_ATTR) : '';

	const selectField = document.querySelector('form.variations_form.cart select[name="' + COLOR_ATTR + '"]');
	if (!selectField) return;

	let isQueriedValueAvailable = false;
	const selectedIndex = selectField.selectedIndex;
	for (let i = 0; i < selectField.length; i++) {
		const option = selectField.options[i];
		isQueriedValueAvailable = queriedValue === option.value;

		if (isQueriedValueAvailable) break;
	}

	selectField.value = queriedValue && isQueriedValueAvailable ? queriedValue : "";

	selectField.dispatchEvent(new Event("input", {
		bubbles: true
	}));
	selectField.dispatchEvent(new Event("change", {
		bubbles: true
	}));

	console.log({
		isQueriedValueAvailable,
		queriedValue,
		selectField
	})
}

jQuery(function() {
  initSingleProductPageVariationsForm()
});

We, and presumably many other online store operators, would be happy to see an improvement in WooCommerce in the future.

If the proposed improvement lands, then caching plugins, such as WP Rocket, can automatically and safely ignore URL parameters in the style of attribute_pa_* on product pages, so that many stores should generally benefit from this improvement in terms of loading time and thus also conversion rate.