Tripvance

Changelog

2.5.1

• Hotfix: Improved stability and responsive layout of the Homepage FAQ section.
• Fixed inconsistent FAQ card heights and layout shifting when displaying answers.

2.5.0

Tripvance 2.5 focuses on administrator workflow, editor stability, UI consistency, draft/publish actions, validation feedback and overall admin polish. It is a refinement release: tours, activities, transfers, bookings, pricing, group rates, quotes and the Guest Pass work as before, product pages keep their design with a finishing pass on the gallery, spacing and review form. One conservative migration runs on upgrade: a migrated itinerary still stored as a single untouched collapsed day is rebuilt from its original text; edited cards are never replaced and the original text is kept.

Editor layout

• The tour and activity editors are laid out by the server and by CSS from the first paint: the section navigation is printed in the left column, the section on screen is chosen before the page is drawn, and the boxes of the other sections are marked off as WordPress prints them. The page no longer opens as WordPress’s two-column screen and then rearranges itself. Without JavaScript every section is shown and the navigation links jump to each.
• The editor reopens on the section you were working in after a save.
• The 1.x „Tour sections“ side card is no longer registered where the section navigation replaces it, so the same controls are not drawn twice.
• Conditional fields, picker chips and the field finder are decided on the server, so nothing moves when the script arrives. The setup and welcome panels are no longer shown above the editor.

Save, publish and status

• One action bar that follows the post’s status: Save draft and Publish for a new or draft post, Update for a published or scheduled one, Save as pending and Submit for review where WordPress’s permissions call for them. Preview, Duplicate, View bookings, Move to draft and Move to trash sit in a More menu and appear only where they apply.
• The buttons press WordPress’s own Save Draft, Publish and Update, so nonces, capability checks, autosave and revisions are WordPress’s; they also work without JavaScript. Enter in a field still saves as it always did.
• Status is shown in words — New tour, Draft, Pending review, Scheduled (with its date), Published, Private — never „auto-draft“.
• The save state reads Not saved yet, Unsaved changes, Saving… or Saved just now / N minutes ago, and only says „saved“ after the server has confirmed it. The leave-page warning no longer fires after a save or when nothing changed, and a preview no longer clears it.
• Ctrl/Cmd+S saves a draft as a draft instead of publishing it.
• Duplicate is available for activities as well as tours, always creates a draft, and no longer copies the original’s Polylang translation group or its import and restore history. Bookings were never copied and still are not.

Completion and validation

• One completion definition: the percentage counts the essentials only; recommended items are listed without holding it down, and optional sections such as FAQ never count against it. Activities now distinguish essential from recommended rows too.
• „N items need attention“ opens a short list of actions — Choose a destination, Set a price, Add a hero image — each of which opens the right section and puts the cursor in the field.
• Sections show one set of marks: complete, needs attention, incomplete, must be fixed, or nothing for an optional section.
• Saving a draft is never blocked. Publishing and updating stop only for what would break the page — a missing title, a malformed number or address — with the reasons listed under the bar and marked on the section, never in a browser alert. A first publish without a title is also kept as a draft on the server.

Consistency and accessibility

• One icon family (Dashicons) with one size and alignment policy, one button shape with primary, secondary, menu and destructive roles, one chip style, and a shared spacing scale. The admin uses one accent colour across the editor, bookings, operations and transfers.
• Same-named terms in the editor’s term lists — one per language, or duplicates left by an import — are shown with their language, parent or slug. No term is merged or deleted.
• Keyboard support for the More menu, the attention list, the section navigation and the field finder; visible focus everywhere; states are never told by colour alone; logical CSS properties for right-to-left screens; no horizontal scrolling at narrow widths.

Product pages

• Tour galleries: every photograph is in the thumbnail strip, which scrolls sideways with the next picture showing at its edge and previous/next arrows once there is more to see; the selected thumbnail stays clear and in view. Small sets (two to six photographs) fill the row instead of leaving a gap, with no arrows when everything fits. Activity galleries mark the last frame „+N“ when the viewer holds more photographs than the grid shows.
• Product pages: no empty „related tours“ block (and its reserved blank space) when there is nothing to suggest; the classic layouts get a content width and gutter on block themes; the „prices checked“ date wraps inside a narrow booking card.
• Reviews: the logged-in line reads as one sentence, the rating select is sized to its options, the submit button uses the plugin’s primary style, and the summary and form line up with the review list in every layout (full width on tablets and phones).
• Itinerary and FAQ: text pasted from Word, Google Docs, AI tools or other plugins no longer collapses into one day or one question. Numbered days or questions run together in one paragraph („2- Day two“ or „2-Day two“) are separated when the numbering is unambiguous, a day recovered that way as „Title / Description“ keeps a short title, and an ordered list keeps its sequence; ranges, times, dates and prices never open a day, and bullet lists stay inside their answer. Content that already read correctly is read exactly as before. Migrated tours whose single collapsed day was never edited are rebuilt from their original text once, on upgrade; edited cards are never replaced and the original text is kept.

Structured data and SEO

• Tour and Activity pages: Tripvance adds at most one Product, describing that tour or activity only — name, URL, image and short description where the page has them, the bookable price as one Offer at the public „From“ price (the fixed price, or the lowest valid Group Rate), and the aggregate of approved on-site reviews where the page shows it. Prices come from the same pricing code as the page and the booking engine; tours on request, incomplete rate tables and seasonal discounts get no price. No availability, SKU, brand, shipping or return data is invented.
• With Rank Math active the data goes into Rank Math’s graph: a Product Rank Math already builds for the page is enriched in place, otherwise one Product is added to that graph. Nothing else in the graph is changed. Without Rank Math one JSON-LD Product is printed.
• Removed: the homepage graph (TravelAgency, WebSite, WebPage, FAQPage, ItemList) and its setting, and the ratings and individual reviews previously added to Rank Math Service, TouristTrip or Trip entities. Legacy settings are preserved. The old rating_schema value is read only to preserve an existing rating opt-out until the new product_rating preference is saved.
• The „Stars in search results“ setting is now „Search result product data“, on by default, with a separate „Include the average rating from approved reviews“ option. A site that had switched the old rating option off keeps ratings off; the old value is kept. It makes pages eligible for rich results; search engines decide what is shown.
• Rank Math sitemaps: the empty-terms switch is no longer forced on for every taxonomy on the site; only empty Tripvance terms are left out.
• The page builder no longer writes or clears Rank Math’s SEO title, description and focus keyword; with Rank Math active they are shown read-only and edited in Rank Math.

2.1.0

Transfers with reusable Vehicle Types, Fleet links in Operations, transfer-aware booking documents, and an optional Privacy & Cookies module. Tours, activities, group rates and their pricing are unchanged, and nothing is migrated: existing bookings and settings keep working.

Transfers

• New Transfers post type (wptm_transfer, /transfers/{slug}/): route, pickup and drop-off types, estimated duration, distance, operating hours, minimum booking notice, pickup and meeting instructions, inclusions, important information, cancellation and gallery. An optional transfer archive (Settings), off by default. No schema is printed; the SEO plugin owns the markup.
• Vehicle Types (wptm_vehicle_profile): reusable customer-facing vehicle options with category, class, passenger and luggage capacity, features and a picture. Private data, not public pages.
• Transfer pricing: each transfer sets its own price per Vehicle Type. A round trip is two journeys at the same price; there are no distance, surcharge or discount rules. One pricing service feeds the page, the server-side check and the price stored with the booking.
• Transfer booking form: Vehicle Type cards, one way or round trip, pickup date and time, passengers, luggage, optional flight details and addresses. Passenger capacity is checked in the browser and on the server; minimum notice is enforced on the server.
• A transfer request is an ordinary booking record (same statuses, history, reservation ledger, messages and confirmation), marked _wptm_booking_type = transfer, with its facts under _wptm_trf_* and its price snapshot stored once.
• The price snapshot stored with a transfer booking is worded in the booking’s language (one way, round trip); amounts are unchanged and earlier bookings are not rewritten.
• The WhatsApp follow-up after a transfer request carries the transfer’s facts — reference, transfer, route, pickup and drop-off, pickup date and time, passengers, Vehicle Type and return — to the site’s WhatsApp number. Tours and activities keep their message.
• Homepage: a new Transfers section, off until ticked in Page layout. Latest transfers or transfers chosen and ordered by hand, a heading and a line, and cards with the route, Vehicle Types, capacity and the „from“ price per vehicle from the transfer pricing service, linking to each transfer page. Existing homepages render unchanged.

Operations and Booking Admin

• Operations → Vehicles is now labelled Fleet, and Transfers → Vehicle Types holds the customer-facing options. Post types and meta keys are unchanged.
• A fleet vehicle can be linked to a Vehicle Type, whose capacity and class it then reads (an existing seat figure still wins). Optional brand, model and operational status (Available, Assigned, Unavailable, Maintenance).
• Assigning a fleet vehicle to a transfer: a warning when it does not match the requested Vehicle Type or is Unavailable or in Maintenance; refused when it cannot carry the passengers. The requested Vehicle Type is never overwritten.
• Transfer bookings show a Transportation block (route, requested Vehicle Type, passengers, luggage, assigned fleet vehicle, driver), a booking type filter in the list, and Trip details with pickup date, pickup time and one Passengers field kept equal to the reservation ledger.
• Quotes, the Guest Pass, the voucher, check-in, the operations board and the personal-data export read transfer bookings in transfer terms, and quotes start from the price stored with the booking rather than tour rates. The Guest Pass and quotes no longer read a transfer as a tour.

Privacy & Cookies

• Optional consent banner, off by default and loading nothing while off: Tripvance → Settings → Privacy & Cookies. Three layouts, four categories (Necessary, Analytics, Marketing, Preferences), editable wording, RTL and keyboard support.
• Scripts placed in the Analytics, Marketing and Preferences boxes, or tagged type="text/plain" data-wptm-consent="…", run only after their category is accepted. Consent is kept in one first-party cookie, wptm_consent.
• Campaign attribution (wptm_attr) now honours the Analytics choice made in Privacy & Cookies. When a consent manager runs the WordPress Consent API in opt-in mode, its statistics answer is final and a refusal there is never overridden by Privacy & Cookies; the wptm_attribution_consent filter still has the last word. Without consent it stays off.
• The module helps collect and honour consent; it does not by itself make a site legally compliant.

Display

• Homepage: the hero no longer jumps under the theme header, spacing in rails and lists is restored, and search fields have a 44px touch target.
• Tour and activity pages: the price, its basis and the group-rate note read as one phrase; phone bar and quick-fact layout fixes. Display only.

2.0.1

Visual refinement of the tour page and the booking screens. No change to the pricing engine, the booking workflow, the stored data or the meta keys.

• Tour header: title, place, rating and the starting price read as one opening; the quick facts sit under the gallery as one strip.
• Gallery: the picture takes the reading column on a desktop, the thumbnails are an even strip, and a „View all photos“ button on the picture opens the viewer, which now shows where you are in the set („3 / 8“) and follows the reading direction.
• Booking panel: reads in the order of the decision — From price, date and travellers, the rate for that party, extras, the estimated total, then the button — with the site’s own reassurances and reply time under the button. Every figure still comes from the server.
• Fix: optional extras in the two-step form were drawn as large empty boxes with upper-case labels; they are real checkboxes with their price.
• Fix: a form reopened at step two after an error did not fill its summary.
• Phone bar: more compact, safe-area aware, and hidden while a dialog or the photo viewer is open.
• Sections: one spacing and type scale for Overview, Itinerary (multi-day thread and timed day timeline), Included / Not included, Important information, questions, reviews and related tours.
• Reviews: a summary card with the average as stars, and each review as a card with the name, date and stars.
• Fix: a single related tour grew to the width of the page; the rate table on SalmaDesign split its header on phones; sections below the booking panel carried a double gutter on phones; the page ran edge to edge on block themes.
• Bookings list: a Total column (accepted quote, else the price worked out with the request), status views with counts, a „Move to“ menu for a safe status change from the list (same transitions, history and hooks as the booking screen), and a readable layout on phones.
• Booking screen: the request is set out as Booking, Trip, Customer, Pricing (line by line from the stored price snapshot) and Notes, each reachable from the header.
• Fix: group-rate input uses one decimal parser for dot/comma decimals and grouped thousands; displayed tiers retain cents.
• Admin: non-blocking warnings for group-rate gaps, overlaps, reversed ranges and invalid prices; saved values and engine selection rules are unchanged.
• Reviews: full, true half and empty SVG stars use the existing icon set, with RTL and accessible rating text.

2.0.0

Tours and Activities become one Experience Builder, while staying two post types with their own URLs and designs. No meta key moves and nothing is migrated.

• Experience Core: one internal API for the fields tours and activities share (media, pricing, itinerary, inclusions, booking, FAQ, important information, sections, presentation), mapped onto each type’s existing meta keys.
• Experience Editor: Basics, Media, Pricing, Itinerary, Inclusions, Booking, FAQ, Additional information and Publish, with a left navigation, one section at a time and marks on incomplete sections. Same form, nonces and save as before. Posts written with blocks keep the block editor; a setting turns the editor off.
• Itinerary: multi-day, single-day timeline, or a new simple route (Marrakech → Atlas Mountains → Ourika). Day cards are kept when switching.
• Pricing: booking forms show how the total is reached („300 MAD × 4 travelers = 1,200 MAD“, or group price and total), from the server’s quote. The editor previews it.
• Booking requests: children, hotel / pick-up, preferred language and notes on every form; Pending is now labelled New. Statuses, the ledger and Guest Passes are unchanged.
• Section manager: show, hide and reorder a page’s sections, per tour or activity.
• Media: optional mobile hero image (served with picture, no cropping), Select / Replace / Remove pickers, video on activities.
• Layouts: Adventure joins Classic and Editorial for tours; activities gain the same three, with a site default. Theme fonts are always inherited.
• Homepage: Travel Agency, Local Guide, Luxury Operator and Adventure Company presets. Presets never change content.
• Admin: a new minimal Tripvance menu icon (an SVG „T“ that follows the admin colour scheme).
• Onboarding: the welcome offers Create your first Tour, Create an Activity, Configure Booking and Build Homepage, and is not shown to sites that already have tours.
• Tailor-Made Requests: a multi-step Trip Builder (shortcode, block or assigned page) with configurable steps and answers, private TMR-numbered requests with six statuses, agency and traveller emails, Create Draft Tour, and an optional tour-page call to action (off by default). No existing meta key, address or setting changes, and no page is created automatically.

1.42.1

Why Activity pages could render unstyled, and the Activity page on a phone. Nothing on a tour page changes, no meta key moves, and every activity, price, gallery and booking is where it was.

• The Activity stylesheet reaches the page. It was enqueued with two other handles named as dependencies, and WordPress prints nothing at all — with no notice and nothing in the log — when a named dependency is not registered. One handle removed by another plugin and the page shipped its full markup with no stylesheet. Both handles are now registered at the point of use and a handle that still cannot be found is dropped rather than allowed to take the page’s stylesheet down with it.
• The page no longer depends on a second file for its appearance. Every panel, card, cell rule and tinted block on it is drawn with custom properties declared in tokens.css, and a custom property with no value invalidates the whole declaration that reads it — so losing that one file left At a glance with no box, Highlights with no card and the panels with square corners, which is the page looking unstyled. activity.css now carries its own floor for those values, at zero specificity, so tokens.css, the site accent and the unified brand all still win when they are there.
• Assets are versioned by the file actually served. The version string stamped the readable source while the browser was given the .min built from it, so rebuilding the .min without touching its source changed the bytes at an address that had not changed and every cache kept the old copy. A .min that is empty or a tenth the size of its source — an interrupted build — is no longer served at all.
• The Activity hero starts below the theme’s header. A fixed header is painted over the top of the banner, and on a phone the breadcrumbs and part of the line above the title were underneath it. The overlap is measured from whatever is actually fixed or sticky at the top of the window, including the admin bar, so no theme’s height is written into the stylesheet and a theme whose header scrolls away is unchanged.
• The Activity page on a phone. One step tighter on the spacing scale the whole page is set with, reading type at phone proportions, At a glance as compact cells with no empty one at the end of a short row, the gallery two across instead of twelve full-width frames, the meeting point stacked so an address is not four lines of two words, and the running order’s clock column at the width of its badge rather than a tour’s.
• What to bring, Important information and the questions are headed like the rest of the page. They are drawn by the tour page’s section templates, whose title sets no colour, so they inherited the body grey and stood beside navy headings at a different size over a shorter accent rule.
• The mobile price bar cannot clip or cover. Its height is derived from its own parts and the safe area, and the page reserves exactly that much; the price never wraps or is cut, and a long button label ends in an ellipsis instead of past the card’s edge. The button’s label also stopped being given the icon’s line-height — an old first-child selector that matched the label on the one button with no icon.

1.42.0

The Activity page and a way out of a tour that should have been an activity. Nothing on a tour page changes, no meta key moves, and every tour, activity, price, itinerary and booking is where it was.

• The Activity hero is full width. The band reaches both edges of the screen while its words stay in the same column as the reading below them, and it sits against the site header instead of under a band of white. The photograph keeps its own proportions rather than being stretched to the height of the text beside it.
• The booking rail holds the booking card and nothing else. Meeting point, cancellation, important information and the questions were being drawn in a three-hundred-and-seventy pixel column beside the form; they are sections of the reading column now, at its full width, each drawn once. The card follows the reader on a wide screen and stacks normally on a phone.
• One spacing scale for the page. Six different margins between sections became three custom properties, and a section heading now sits closer to what it introduces than to the section above it.
• At a glance carries every fact, including when the activity runs, which had a card of its own. The strip wraps into counted columns instead of forcing every fact onto one row, so labels are read at their proper size rather than shrunk to fit.
• The gallery opens. „View photos“ and every thumbnail open a viewer with the full-size picture, a counter, previous and next, Escape, arrow keys and a backdrop that closes it; the page behind does not scroll and focus returns where it was. Without JavaScript each frame is still a link to its own picture.
• Tour to Activity conversion. An unpublished tour can be copied into a new draft activity from the tours list or the Publish box: title, content, excerpt, featured image, gallery, destination and place terms, and every commercial and experience field that both post types share. The tour is never modified and no media is duplicated.
• The itinerary is converted rather than copied. A tour keeps its stops as days and an activity keeps them as moments of one occasion, so a copied row arrived as an empty schedule. Stops are now read through the itinerary layer’s own reader — structured, legacy text, or both — and written as schedule rows in order, with their times, titles, descriptions, locations and photographs. Anything with no field of its own is carried into the description rather than dropped, and whatever cannot be mapped is named in a notice on the new activity.
• Description and answer paragraphs are justified and set at a reading measure, ragged on a narrow column, inheriting the theme’s own type.

Earlier releases

In brief below. The full notes for every release, including these, are in
changelog.txt, which ships with the plugin.

• 1.41.0 — The tour editor answers as you type: a live status card that says the booking mode in words, completion counted on the six things a tour needs, and field search that reaches the itinerary.
• 1.40.2 — A styling pass over the itinerary: the thread runs to the last moment of the last day, and the descriptions are set at a reading size.
• 1.40.1 — A migration fix. Activation recorded the itinerary migration as finished before it had started; stranded sites are picked up automatically.
• 1.40.0 — The itinerary is written on cards. Existing tours move across automatically, and the old wptm_itinerary field is kept as the backup.
• 1.39.0 — An editor release: days and stops appear as editable cards straight away, and Activities use the same editor as Tours.
• 1.38.0 — A stability release: less loaded on a front-end request, a correct rate limiter under load, a System Status screen and a test suite.
• 1.37.0 — A tour is drawn day by day only when it says it lasts more than one day, so day trips are no longer announced as DAY 01, DAY 02.
• 1.36.0 — Day trips stop being announced as a run of days: a one-day itinerary reads as a timeline of times and stops on every layout.
• 1.35.2 — A stability release. Tours written by any earlier version open, save and render exactly as they did.