Bundle product backorders being set incorrectly

Hi @gferguson78 ,

For your information, technically there are only 2 kinds of stock status: available (in stock/ on backorders) or not available (out of stock, unpurchasable).

Even if you set it to “allow backorders but notify customers”, it allows that products to be purchasable, so is considered “available”. We don’t distinguish between “in stock”, “allow backorders” & “allow backorders but notify customers”. Technically, there are all “available”.

Best regards.

Thanks for your reply. I appreciate that all items are purchasable, however we use the different types of backorder to differentiate the availability message that is displayed to the user on the product page.

If backorders are set to ‘allow’ then we show the item as being available immediately.
If backorders are set to ‘notify’ then we show them as being available within a certain timeframe (usuallly 10-14 days)

The previous version of the plugin (8.1.1) returned the correct backorder status for woosb products when using the $_product->get_backorders(); command (generally this was always ‘notify’). Now in 8.1.2 – whenever a woosb product is queried for it’s backorder status it is returning it as ‘allow’ rather than ‘notify’ regardless of the backorder status of the items that make up the bundle product. This is an issue for us and I believe it to be a bug.

I can setup a simple bundle product with just 2 items in the bundle, both not having any stock but with backorders being set to ‘allow but notify’. When I save the bundle product then the backorder status is being saved as ‘allow’ rather than ‘notify’. It is impossible to override this, it is always saved as allow. I can provide temporary login details to our dev site if you wish to see this issue.

I notice some additional code has been added to the include/class-product.php file in V8.1.2 and I can only assume that this may be causing the issue.

In the meantime I will stick with version 8.1.1 until this issue is acknowledged and fixed.

Hi @gferguson78 ,

This is not really a bug. Our developers have received some reports about users claiming that their bundle stay unpurchasable because of some backorder items inside and this affect their sales because customers cannot purchase the bundle properly and it said the bundle is unpurchasable all the time.

So our developers have discussed and considered that even when “On backorders, but notify customers”, by nature, this means that item can still be purchased. So they might have made some adjustments to solve the issue of bundle availability.

I will write a report to our developers so that they can consider further if there should be any changes regarding this issue. Kindly note that our developers might not make any change in case they consider the result would affect the majority of users.

Please check back when you find a new update. It might take quite some time though because our developers are quite under snowed at this time of the year.

Best regards.

Ok, thanks for the explanation. I’m not sure why forcing all backorder bundle products to be set to ‘allow’ rather than ‘notify’ would make any difference as to whether they are purchasable though as all products which are on backorder are always purchaseable. The backorder status is purely related to how the product is displayed to the customer on the front end.

The previous V8.1.1 is working correctly for us at the moment anyway so I’ll stick with that and will do some testing when a new update is released.

Thanks!

Just to advise that this issue has still not been rectified as of version 8.1.4.

There was an update to the changelog saying ‘Fixed: Stock status issue’ but backorder statuses are still being set incorrectly for bundle products.

This new bit of code (since 8.1.2) at line 283 in the includes/class-product.php file seems to be stopping the bundle backorder status being set correctly:

if ( WPCleverWoosb_Helper()->is_in_stock( $_product ) && WPCleverWoosb_Helper()->has_enough_stock( $_product, $_qty ) ) {
continue;
}

From what I can see the WooCommerce ‘is_in_stock’ function only checks to see if the product is purchasable and the ‘has_enough_stock’ function only checks to ensure that there is enough stock for the products that are currently in the customers shopping cart. In our case these will always both be returned as ‘yes’ (since the products are purchasable and there would be no bundle items currently in the shopping cart) then the function would never move past this onto the next lines which set the backorder status.

When I’ve tested it removing this line of code then the backorder status is once again set correctly, otherwise all backorders are automatically being set to ‘yes’ rather than ‘notify’.