Skip to main content

Rentiva 6.1.4 — A booking linked by ID no longer vanishes from the Customers screen

· 4 min read
MaxHandMade
MaxHandMade
Maintainer

If a guest booked with you first and created an account afterwards, the Customers screen could not see that booking. The customer's row read 0 bookings, their money never reached the summary cards at the top, and "View Bookings" showed an empty list. 6.1.4 fixes that, and it asks nothing of you: no database change, no re-saving of settings.

The Customers screen now finds every booking​

The screen reached a customer's bookings through the customer's e-mail address alone. That works for the ordinary case, where the account and the booking carry the same address. It fails for every case where they do not:

  • a guest who booked, then registered later — the booking is attached to the account by its internal ID, not by a matching e-mail
  • a customer who changed their e-mail address after booking
  • an account added by hand that has no booking yet, or one known only through the plugin's own records

In each of those, the booking was invisible to the screen. The row showed 0, the detail panel was empty, the summary cards at the top left that money out, and the account could be missing from the customer count entirely.

Underneath the screen, four separate copies of "who counts as a customer" had drifted apart, which is why the customer list and the booking count could disagree about the same person. There is now one definition, and it is read from every place that asks the question — seven files across the plugin, twenty-nine call sites, including membership, counting, deletion and export. Those can no longer contradict one another.

One note on how it was built, because it is the kind of detail that decides whether a fix is real: the query uses an EXISTS predicate rather than a widened join. A join that matches on either e-mail or ID counts a booking twice when both match. That was not assumed to be a risk — it was demonstrated by deliberately writing the naive version and watching the numbers double.

The dashboard's own figures are computed separately and were not part of this change.

The admin menu is back above WordPress's own items​

Rentiva registers one top-level menu with a lot of pages behind it, and if you run a rental business you are inside those pages all day. The menu had been sitting below Appearance, Plugins, Users and Tools, near the bottom of the sidebar, so reaching any of it meant scrolling past the whole of WordPress first.

It now sits directly below WooCommerce and above Appearance. That is as high as it goes: the position is the floor of the WordPress.org guidance that asks a plugin not to compete with WordPress's own top-level items, and Rentiva stays inside it rather than pushing above core.

Multisite activation reaches every site​

Activating Rentiva across a network stopped at the hundredth site and skipped private sites entirely, so on a large network the sites past that point never got their tables. Both now get them. A subsite also reads its own language when building its URL slugs, rather than inheriting the network's.

A layout rollback can no longer touch the wrong page​

Rolling a page back in the layout tool could write layout markup onto a completely different, unrelated post when a stale internal ID pointed at it. It can no longer touch a post it was not meant to.

Redis and Memcached hosting​

On hosting with an external object cache, saving a customer, booking or vehicle left its list showing the old data until the cache entry expired on its own. The list now updates when you save.

A smaller download​

The package no longer carries React source files that WordPress never runs.

Where to get it. 6.1.4 is published on GitHub as v6.1.4. The WordPress.org plugin directory still serves 6.1.3 — submitting 6.1.4 there is a separate decision and has not been made yet, so updating from inside WordPress will not offer it to you today. The full changelog in both languages ships with the plugin.