Skip to main content

Rentiva v5.2.2 / Pro v5.2.2 — What we tell WooCommerce, and one thing we were telling it wrong

· 4 min read
MaxHandMade
MaxHandMade
Maintainer

A patch release with one uncomfortable admission in it. Preparing for the WordPress.org submission, we ran our WooCommerce control checklist against the whole codebase for the first time — and found that we had never answered WooCommerce's compatibility questions at all.

What we were not saying​

WooCommerce asks every plugin that touches orders to declare which of its newer features it works with. A plugin that says nothing is filed as uncertain, and the site owner is warned by name when they try to switch on High-Performance Order Storage — which has been the default for new stores since WooCommerce 8.2.

We had never declared anything. Not "incompatible" — nothing at all.

HPOS: compatible, and measured before saying so​

A compatibility declaration is a promise, and a false one is worse than silence: people enable HPOS on the strength of it and lose data quietly. So we checked rather than assumed. Every order this plugin touches is read through wc_get_order(); there is no post-meta access keyed to an order id; nothing queries wp_posts or shop_order for orders; no order is created or updated with wp_insert_post().

That is now declared, in both the free plugin and the paid add-on.

Block cart and checkout: not compatible, and we say so​

This is the part worth reading if you run a store.

We could have stayed quiet. Instead we checked what actually happens on a block-based checkout, and declared incompatible, because that is the truth:

  • The payment-type selector, the custom tax row and the return-to-cart link never render — they are printed from classic-checkout hooks the block checkout does not run.
  • The availability check does not run. woocommerce_checkout_process is where we verify that the vehicle is still free for the requested dates. On a block checkout that hook never fires, which leaves a window where two customers can book the same vehicle for the same dates.

If your store uses the block checkout, switch to the classic checkout while using this plugin. Making the block checkout genuinely supported means rebuilding those surfaces on the Additional Checkout Fields API and a Store API integration — a feature, not a flag, and one we would rather do properly than claim.

One value was being stored where HPOS cannot read it​

The payment type chosen at checkout was written with update_post_meta( $order_id, … ). Under HPOS an order is not a post, so that writes a row keyed to something that is not the order.

It now goes through WooCommerce's own order object. On a store that has not switched to HPOS, that object writes to post meta anyway — so the value stays exactly where it has always been. Nothing is moved and nothing needs migrating.

The admission​

The independent audit we run before every release build caught a claim inside this very change that a search disproves. Our first draft of the add-on's explanation said it "registers no checkout hooks and prints nothing into cart or checkout". It does both — four hooks, in two files.

The audit also did the work we had skipped: it read WooCommerce's own source and established that the Store API does run two of those hooks, so most of that surface survives a block checkout, and only the cart line-item name is classic-only and cosmetic. That mixture is neither "compatible" nor "incompatible", so the add-on declares neither and explains why.

We are writing this down because the correction is the useful part. A release note that only lists what went right teaches nobody anything, least of all us.

Upgrading​

Nothing to do. Update both plugins together if you use the paid add-on.