Rentiva v5.2.1 / Pro v5.2.1 — A chart that says what it counts, and translations that ship
A patch release about honesty. The dashboard chart was named after something it does not measure, and a set of admin strings was being shipped in English despite having been translated months ago. Both are fixed — and the second one turned out to have a cause worth writing down.
This post is the record of a release that shipped before 6.0.0, which renamed the plugin's post types, taxonomies, options, meta keys and hooks. The identifiers below are the names those versions actually used, and they are kept that way on purpose. For the current names — and a conversion table — see the 6.0.7 release post.
The chart was measuring the right thing under the wrong name
The dashboard's bar chart was labelled "Revenue (Last 7 Days)". It sums _mhm_total_price for confirmed and completed bookings, bucketed by DATE(post_date) — the date each booking was created. That is not rental income earned in those seven days; it is the value of new business booked in them.
The mismatch was visible: the table directly beneath the chart lists bookings by pickup date. So a rental company with a full week ahead could see a row of upcoming rentals under a chart reading zero, and reasonably conclude the chart was broken. It wasn't — it was answering a different question than its title asked.
The label now reads "New Bookings Value (Last 7 Days)", and the daily series is "Daily Bookings Value".
The numbers have not changed. We deliberately did not move the chart onto pickup dates, because post_date is the basis shared by the dashboard metrics, the period deltas, the booking statistics, the deposit statistics and the comprehensive report. Changing only the chart would have left the plugin with two different definitions of "revenue" on one screen. Reporting on realised rental income is a genuine feature, and it belongs in its own release rather than smuggled into a label fix.
Five translated strings that never reached anyone
WordPress serves JavaScript translations from one JSON catalogue per script, named after an MD5 of the script's path. Those catalogues are generated by wp i18n make-json, which — by default — only looks at references ending in .js or .min.js.
Every React reference in our translation template is a .jsx source path. So the command matched nothing, printed a success line, and wrote no React catalogues at all. Because regeneration correctly runs with --no-purge, the previous catalogues survived untouched, and the check that was supposed to catch this only asserted that the files existed. They did. They were four months old.
The result: "Pending Payments", "Upcoming Operations", their empty-state messages, and the notice shown when an admin screen fails to load were all translated in the catalogue and all displayed in English.
This release fixes the build and, more importantly, changes what the check actually checks. It now compares the shipped catalogues against the translation source on three axes — the script each catalogue claims to belong to, whether this run actually rewrote it, and whether every string the source assigns to that screen is present. It runs on every push. A green result now means something.
Pro: the same class, five screens wide
The paid add-on's five React screens — Reports, Messages, Export, Vendor Management and Vendor Reports — had been shipping entirely untranslated since they moved into their own plugin. The sources had been corrected to the add-on's own text domain at the time, but nothing rebuilt the compiled bundles, because the build configuration had not moved with them.
That chain is now closed end to end: the bundles are rebuilt against the right text domain, the translation template scans the React sources, 325 strings are translated, and the catalogues are generated under the names WordPress actually resolves. All five screens were verified in a browser in Turkish before this release, tab by tab.
Pro v5.2.1 also corrects its declared minimum Lite version. The translation fix depends on a parameter Lite gained in this release; with an older Lite the add-on does not fail, the screens simply stay English.
Housekeeping
- Eleven translation catalogues belonging to screens and blocks that are no longer part of the free plugin were removed. Nothing loaded them.
- The readme's bundled-library inventory now lists Chart.js 4.5.1 alongside flatpickr and Swiper, with its licence and upstream source. It is compiled into the dashboard bundle rather than shipped under
assets/vendor/, and that distinction is stated.
Upgrading
Nothing to do. No figure, setting or stored record changes. Update both plugins together if you run the paid add-on.