| @@ -3,9 +3,9 @@ | ||
| 3 | 3 | Tags: tour-booking, travel-booking, tour-operator, travel, travel-agency |
| 4 | 4 | Requires at least: 6.0 |
| 5 | 5 | Tested up to: 7.1 |
| 6 | 6 | Requires PHP: 7.4 |
| 7 | -Stable tag: 3.0.16 | |
| 7 | +Stable tag: 3.0.17 | |
| 8 | 8 | License: GPLv2 or later |
| 9 | 9 | License URI: https://www.gnu.org/licenses/gpl-2.0.html |
| 10 | 10 | |
| 11 | 11 | WordPress travel booking plugin for tour operators. Trips, departures, payments, OTAs, AI. Free + [Pro](https://wpyatra.com/pricing/) from $99/yr. |
| @@ -282,8 +282,28 @@ | ||
| 282 | 282 | |
| 283 | 283 | == Changelog == |
| 284 | 284 | |
| 285 | 285 | The two most recent releases are listed below. For the complete version history, see [changelog.txt](https://plugins.svn.wordpress.org/yatra/trunk/changelog.txt). |
| 286 | + | |
| 287 | += 3.0.17 — 7 October 2026 = | |
| 288 | + | |
| 289 | +**New** | |
| 290 | +* **Choose what happens to your data when Yatra is removed.** A new Uninstall section in Settings, after Advanced, carries a single switch: *Delete all data on uninstall*. It is off, so deleting the plugin leaves every trip, booking and customer in place and reinstalling picks up where you left off. Switch it on and deleting Yatra removes its tables, settings, scheduled tasks and user meta for good — leaving Yatra Pro's own settings and scheduled work alone for as long as Pro is still installed, so removing one plugin never half-removes the other — the screen says so plainly before you save, and Yatra Pro follows the same switch for its own data. Deactivating never removes anything either way. | |
| 291 | +* **Kids-friendly and the other age filters can be re-tuned.** The age each band covers was fixed in the code — kids-friendly meant "12 and under" and nothing could change it. The four bands now come from one place and a site can set its own: `add_filter( 'yatra_age_suitability_thresholds', fn( $t ) => $t + [ 'kids_max' => 17 ] );`. The filter chips and the trips they return always agree, which they could previously drift apart on. | |
| 292 | + | |
| 293 | +**Fixed** | |
| 294 | +* **Review request emails could go out in one large batch, long after the trip.** The request was scheduled for a fixed number of days after a booking was *marked completed*, which is not the same as days after the trip. The nightly sweep that completes finished tours can work through a backlog in one run, so customers whose trips had ended weeks or months earlier were all asked to review on the same night. The request is now timed from the date the trip ended, and a trip that finished longer ago than the new *Don't ask about trips older than* setting (14 days by default) is never asked about at all. Requests for trips ending on the same day are spread over an hour rather than sent in one burst, and any reminders already queued by an earlier version for trips that are now too old are cleared on update. Both the delay and the age limit are configurable under Settings → Review, and via the `yatra_review_reminder_days` and `yatra_review_reminder_max_age_days` filters. | |
| 295 | +* **Traveller categories, attributes and itinerary item types were never exported.** The classifications table holds eight kinds of entry and a backup only ever contained four of them, so traveller categories, trip attributes, itinerary item types and itinerary items were silently missing from every export — and the trip links pointing at them could not resolve on import either, which quietly dropped a further 157 trip-to-classification links on the site this was tested against. All eight are now exported and restored. | |
| 296 | +* **Restoring a backup onto a new site lost everything belonging to a Pro module that had not been switched on.** Yatra Pro creates each module's tables when that module is enabled, so on a fresh install the tables for Email Automation, Dynamic Pricing, Consent Forms and Additional Services do not exist yet, and every row destined for them was counted as a failure and discarded — 2,440 rows on the migration this was tested against, including the entire email history, pricing history and template set. The import now makes sure those tables exist before it writes. Whether you switch the modules on afterwards is a separate decision from whether your data survived the move. | |
| 297 | +* **A re-import looked like it had done nothing.** The import summary only ever showed what it brought in and what failed, never what it recognised as already present. Importing a backup into the site it came from is supposed to bring in nothing — every row is already there — so the screen filled with zeroes and a red failure count, and read as a broken import. It now reports what was imported, what was already here, and what could not be linked, and says plainly when a file was already fully present. Rows that reference a record the file does not contain are no longer called failures: they are listed as "not linked", because that is what they are — usually something deleted on the original site. Data-type names with more than one underscore no longer render as "Email Sequence_steps". | |
| 298 | +* **Review request emails are now off until you switch them on.** They were enabled on every new install. A review request is the one transactional email that is not a reply to something the customer just did, and several jurisdictions treat it as advertising rather than service mail — in Germany the Federal Court of Justice (VI ZR 225/17) holds that it needs prior consent, and the existing-customer exemption does not cover it. New sites therefore start with it off, so you can turn it on once you have decided how you collect that consent. **Sites that already have it switched on are unchanged.** | |
| 299 | +* **The Email Logs missed everything Yatra itself sent.** Only the Pro automation and abandoned-booking modules wrote to the log, so a booking confirmation or a review request sent by Yatra's own templates left no record, and operators searching for an email a customer had received found nothing. Those sends are now logged too, marked as coming from Yatra core, with no duplicate entry for the emails Pro already records. | |
| 300 | +* **Translated admin screens stayed in English unless a JS translation file happened to exist.** The React admin could only read translations from a script-translation JSON file. Translations from WordPress.org ship one, but a site translated by hand — with Loco Translate, or a .po/.mo dropped into wp-content/languages — has only the PHP catalogue, so every label, button and message in the admin stayed English no matter how complete the translation was. Yatra now hands those translations to the admin itself when no JSON file is present. Sites running in English are unaffected and carry no extra weight. | |
| 301 | +* **Adding an availability date that already existed crashed the screen.** The date is unique per trip, departure date and time, so the second attempt was rejected by the database — and because the rejection was never checked, the code tripped its own return type and raised a fatal error. Operators saw "There has been a critical error on this website" and the Availability screen went blank. It now says *"Availability date already exists for the selected departure"* and the screen stays usable. The same check covers editing a date onto a slot another date already holds, which previously reported success while quietly changing nothing. | |
| 302 | +* **Importing the same file twice duplicated everything.** Import gave every row a fresh id, so a second run doubled trips, bookings, discounts, availability and itineraries, while anything with a unique column was rejected outright — on one site every customer failed to import because their email addresses were already present. Import now recognises what the site already has and brings in only what is missing, so running it twice leaves you where the first run finished. That covers destinations, activities, categories and difficulty levels, which a second run used to re-add under renamed slugs, as well as service, consent-form and pricing-rule catalogues. Sent-email history is the one exception and is still appended, because two genuinely separate emails can look identical and skipping them would lose records from a restore. | |
| 303 | +* **Importing could leave trip and category links pointing nowhere.** Restoring settings also restores the permalink bases, but the rules behind the URLs were not rebuilt, so trips and categories stopped resolving until someone re-saved Settings → Permalinks. The rules are now rebuilt on the next page load. | |
| 304 | +* **"1 Trips" on activity, destination and category listings.** Those three templates always used the plural, so a single result read as "1 Trips" — and in a translated site, "1 Reizen". The count now picks singular or plural, and translators get a proper singular to fill in. | |
| 305 | +* Import no longer probes Yatra Pro's email-template and consent tables on sites where those modules have never been enabled, which logged a database error for every row imported. | |
| 286 | 306 | |
| 287 | 307 | = 3.0.16 — 24 September 2026 = |
| 288 | 308 | |
| 289 | 309 | **Please read if you use reCAPTCHA.** With reCAPTCHA switched on for the booking form, checkout could not be completed on Stripe, Square or Authorize.net — the card form showed "reCAPTCHA verification failed. Please try again." and the payment never went through. Lowering the score threshold did not help, because no token was being sent at all. This release fixes that; if you turned reCAPTCHA off to take payments, you can turn it back on. |
