MHM Rentiva

MHM Rentiva is a vehicle rental management plugin for car and motorcycle rental businesses. You manage your fleet, availability and bookings from the WordPress admin; frontend payments are handled by WooCommerce, and administrators can also create and manage bookings manually. Everything described below works in full. There are no vehicle, booking or listing caps, no feature timers, and no locked screens. Features:

• Vehicle Management: Add, edit and manage your fleet with detailed attributes (transmission, fuel type, seats, and your own custom features and equipment).
• Booking System: Booking engine with calendar view, availability checking and automatic price calculation.
• Payment via WooCommerce: Frontend payments go through WooCommerce, so you keep whatever payment gateways you already use. Native offline payment is supported for admin-created manual bookings.
• Customer Management: Customer records, booking history, and CSV export of your customer list.
• Email Notifications: Editable email templates for booking confirmations, cancellations, refunds and reminders.
• Customer Account Pages: Bookings, favourites and payment history in the customer's WooCommerce account area.
• 16 Shortcodes: Search, results, vehicle grids and lists, vehicle details, booking form, availability calendar, comparison, testimonials, ratings, contact form, and the customer account views.
• 16 Gutenberg Blocks: One for each frontend shortcode, built on a Render Parity architecture — a block, its Elementor widget and its shortcode all delegate to the same renderer, so they produce identical output.
• 17 Elementor Widgets: The same components as Elementor widgets, with Elementor's own controls and live preview. (Two of the seventeen — Vehicle Card and Vehicles List — render the same underlying component with different presets, so the seventeen widgets cover sixteen distinct components.)
• REST API: Endpoints under mhm-rentiva/v1 for availability checks, customer records and admin dashboard data.
• Translation Ready: Ships with a full Turkish translation.

Requirements: WooCommerce. It is declared in the plugin header and checked on activation, so the plugin will not activate without it. WooCommerce provides the cart, checkout and payment gateways used for frontend bookings. External services This plugin does not send your data anywhere. It makes no requests to any third-party service: no analytics, no geolocation lookups, no remotely-hosted fonts or scripts. Every asset it loads, including its webfont, is served from your own site. Nothing about your site, your bookings or your customers leaves your server. For completeness, the plugin's admin screens do contain ordinary hyperlinks to pages outside your site, which open only if you click them and send nothing when you do:

• Its documentation at https://maxhandmade.github.io/mhm-rentiva-docs/ (source: https://github.com/MaxHandMade/mhm-rentiva-docs)
• Its issue tracker at https://github.com/MaxHandMade/mhm-rentiva/issues, linked from the About screen
• The author's site and support page at https://wpalemi.com/ — terms: https://wpalemi.com/terms/ , privacy policy: https://wpalemi.com/privacy/
• This plugin's own support forum at https://wordpress.org/support/plugin/mhm-rentiva/ and, in the setup wizard's e-mail step, links to the wp-mail-smtp and fluent-smtp plugin pages on WordPress.org
• The author's YouTube channel

These are links, not integrations: the plugin performs no HTTP request to any of them. A check in our build guards against reintroducing the specific third-party services earlier versions used — geolocation lookups, CDN-hosted fonts and scripts, analytics and Gravatar — by failing if any of those hosts reappears in the PHP we ship. Privacy MHM Rentiva stores its booking and customer records (such as names, e-mail addresses and phone numbers) locally in your WordPress database and does not transmit them anywhere. Four other things it keeps are worth naming; three of them record an IP address, which in most jurisdictions counts as personal data in its own right. If you publish the plugin's contact form, each submission is saved as a private record holding the sender's name, e-mail address, telephone number, company, the message itself, a link to any file they attached, and the IP address and browser user-agent it was sent from. The record also keeps the rest of what the form submitted: which vehicle the enquiry was about, a preferred date, a priority, a rating, and which variant of the form was used. These records have no retention setting and are never removed automatically; you read and delete them yourself under MHM Rentiva → Contact Messages. The attached file itself is placed in your site's ordinary uploads folder, where it is reachable by anyone who has the URL, and it stays there even if you delete the message. If you publish the plugin's rating form, each review is stored as an ordinary WordPress comment, so WordPress itself records the reviewer's IP address and browser user-agent alongside it, exactly as it does for any comment — and for a review left by someone who is not logged in, the name and e-mail address they typed. Those guest reviews are reachable through Tools → Export/Erase Personal Data, which matches comments by e-mail address. From version 6.0.1, a review left by a logged-in customer is saved the same way WordPress saves any comment from a signed-in visitor: against their user ID, and with the display name, e-mail address and website address from their profile written onto the comment. Those reviews are matched by the same Export/Erase tools, on the account's e-mail address. Reviews that logged-in customers left in earlier versions carry no name and no e-mail address on the comment, and updating does not fill them in, so the Export/Erase tools — which look comments up by e-mail address — do not return those older ones; remove them from the Comments screen instead. The activity log records, for each entry, the IP address and browser user-agent of the request that produced it, along with the WordPress user ID where there is one. Unlike contact messages, log entries are deleted automatically after a retention period you set in the plugin's settings (30 days by default). The e-mail log records, for each message sent through the plugin's notification system, the recipient address, the subject, whether delivery succeeded, and the booking details the message was built from — which for a booking e-mail means the customer's name, contact details and rental dates. The assembled message body itself is not stored. This log has its own retention setting on the same terms (also 30 days by default). Booking records themselves do not store an IP address: no code path in this version writes one, whether the booking comes through WooCommerce checkout or an administrator enters it by hand. Records created by older versions may still carry an IP address and user-agent; where they exist they have no expiry and go only when the booking is permanently deleted. If you keep a privacy policy, these are the parts of the plugin it should describe. The plugin registers no personal-data exporter or eraser of its own; advanced GDPR export and erasure tooling is provided by the separate paid Rentiva add-on. A paid version exists A separate paid Rentiva plugin adds a multi-vendor marketplace, VIP transfers with location-based routes, customer messaging, advanced reports and vendor payouts. It is a separate add-on plugin. Nothing described on this page is withheld or limited to promote it, and this plugin never advertises it to you in the admin.

WordPress.org renders at most 5,000 characters of this section, so only the releases published since the version currently in the directory are repeated here. The complete history, in English and Turkish, ships with the plugin as changelog.json and changelog-tr.json, 6.0.0's breaking-change notice among them. 6.1.4

• Fixed: on the Customers screen, a booking linked by ID rather than e-mail did not count on the customer's row, was missing from their detail panel and summary cards, and did not show behind "View Bookings".
• Fixed: multisite activation stopped at the hundredth site and skipped private sites; both now get their tables. A subsite reads its own language for URL slugs, not the network's.
• Fixed: a page rollback in the layout tool could overwrite an unrelated post with layout markup via a stale ID; it can no longer touch a post it was not meant to.
• Fixed: on hosting with an external cache (Redis/Memcached), saving a customer, booking or vehicle left its list stale until the cache expired.
• Changed: the ZIP no longer ships React source files WordPress never runs, so the download is smaller.
• Changed: the admin menu moved back above WordPress's own Appearance, Plugins, Users and Tools items, just below WooCommerce.

6.1.3

• Fixed: on a site whose vehicle settings were saved before 6.1.2, adding gallery images and pressing Update still wiped the gallery. 6.1.2 stopped the two non-detail keys, image and gallery_images, from being written into the selected-details option, but did nothing for the sites that already had them stored. A stored key that matched none of the known field sources was handed a label made up from the key name, which carried it past every later check, and the detail grid then rendered a second field named mhmrentiva_gallery_images -- the same name as the gallery meta box's hidden input. PHP keeps the last field of a repeated name, so an empty box overwrote the gallery. Such a key is now dropped rather than labelled, which makes an already-affected site safe without touching its database. One deliberate consequence: a custom detail whose name you clear under Edit Names now disappears from the grid instead of showing under a key-derived label. Nothing stored is deleted, naming it again brings it back, and the front end was already hiding it.
• Security: the handlers that write vehicle and booking meta now verify the post type of the post they are writing to. edit_post answers whether a user may edit a given post, never whether that post is one of this plugin's, so a handler acting on whatever id arrived was writing to an object it had not identified. The booking meta handler was the widest case: hooked to the untyped save_post, saving any page or post on the site wrote a booking status onto it. Twelve handlers were corrected; an independent audit then found three more outside the recorded list, including a live AJAX handler that wrote vehicle ordering meta onto any post id it was given.
• Fixed: an admin screen whose data fails to load now says so instead of going blank. The failure that prompted this happened in the companion add-on, where one bad endpoint map took out five screens at once -- the three wrapped in an error boundary showed a message and could be refreshed, while the two that were not left an empty page under the WordPress chrome with nothing explaining it. Sweeping the same class here rather than fixing only the screens that had already failed found one unwrapped screen in this plugin. Every React screen here is wrapped now, and a gate keeps new ones from shipping unwrapped.
• Changed: shared admin modules and the React page loader now come from the mhm/ui-core package rather than copies kept here, and duplicate CSS custom-property declarations were consolidated. Checked in the browser, light and dark: nothing rendered differently.

6.1.2

• Fixed: a booking created from the admin's manual booking screen was stored with no status at all. The screen's script read the status field by its name rather than its id, matched nothing, and sent an empty value that the handler stored as-is. The availability check counts only live statuses, so such a booking was invisible to it and the same vehicle could be booked again over the same dates.
• Security: the manual booking screen's boundary now refuses any status the screen itself does not offer, instead of writing whatever arrives.
• Fixed: the confirmation prompt before changing a booking's status on the edit screen never appeared -- it was bound to the status field by name rather than by id, so it was bound to nothing. The field's label was associated with the same missing id and is now linked to the select.
• Security: the role given to customer accounts this plugin creates is rejected if it carries administrative capabilities, rather than accepted because the role exists. The same setting decides which accounts count as customers, so a privileged value affected the Customers list too.