A client with a huge catalog once decided that “cleanup” meant deleting discontinued products straight out of the database, permanently, not into the trash. A week later their support team was calling me because historical orders were returning 500 errors. The cause was needs_shipping() being called on an order line whose product no longer existed, which was enough for a fatal error. That is the bug the WooCommerce 10.4.2 update closes, and it is why I would not leave it sitting in the updates screen.
The fix is tracked in pull request #62102. WooCommerce was fetching product data for shipping calculations without first checking that the product still existed. With five years of order history and an aggressive inventory manager, that gap shows up sooner or later. The patch adds the null handling, so a missing product no longer takes the page down with it.
Defensive coding and the WooCommerce 10.4.2 update
I tried to solve this myself years ago. My plan was a custom filter that caught the null and handed back a dummy product object. It kept the shipping calculation working and broke the tax logic for international orders instead, so checkout was running on stale data. That is the reason I stopped patching core behavior when an upstream fix exists. The WooCommerce Developer Blog has the technical detail on what changed.
The release also deals with the hosting environment. PHP 8.4 is much less forgiving about malformed transient data, so if the WooCommerce Helper gets a strange response during a plugin update check, the site can go down with it. The update validates that data before using it. Nobody will ever notice the fix, which is rather the point.
WordPress 6.9 changed the action hook naming conventions for the Abilities API, which broke the block-based Product Editor for anyone who updated early. Clicking “Full editor” in the Description section threw JavaScript errors, because the code was still referencing deprecated Gutenberg features. WooCommerce 10.4.2 supports both the old and the new hook names. It reads like a trivial change until you count how many sites it hit.
/**
* A look at how we used to manually verify product existence
* to prevent the shipping calculation crash.
*/
function bbioon_validate_order_item_product( $item ) {
$product = $item->get_product();
// This null check is what 10.4.2 now handles internally
if ( ! $product ) {
return false;
}
return $product->needs_shipping();
}Why this dot release is worth your time
Nobody enjoys running maintenance updates on a Friday, and I have put off my share of them. Dot releases like this one are not padding, though. The PHP 8.4 compatibility work and the WordPress 6.9 hook fixes both clear real problems, and either one on its own is enough reason to install it.
On a high-volume store, small fatal errors like these cost conversions and damage your search rankings. You do not want to hear about a broken order history page from the client first. Update staging to 10.4.2, run your tests, then push it to production.
This kind of debugging gets complicated fast. If you are tired of untangling someone else’s code and would rather the site just worked, get in touch with my team. We have probably run into it before.
