Pro Changelog

What’s new in Alnora

Every release, with the features, improvements and fixes it brought. Updates arrive automatically through WordPress while your license is active.

  1. 1.4.9 Latest 1 October 2026

    Order your doctors separately at each location, and see on every doctor’s card where they work. Every date field now reads day/month/year whatever the browser’s language, and a full backup now includes signatures, shares and tokens.

    • Filter the Doctors screen by location and drag doctors into the order patients see when they book at that location. The order under All doctors stays the clinic-wide order for everywhere else, and choosing an order never changes where a doctor works.
    • Each doctor’s card on the Doctors screen says where they work: the location, several locations, or All locations — and No active location for a doctor patients cannot book.
    • Every date field reads dd/mm/yyyy with a calendar beside it — Add appointment, rescheduling, the Appointments filter, days off, Reports, Send an email, and Date questions on the booking form, portal and page forms. The browser’s own date box showed mm/dd/yyyy to anyone with an English (US) browser. Dates are typed day first, and an impossible or unavailable date is refused with a message.
    • The date box no longer flickers when an admin screen loads.
    • A full backup now includes consent signatures, signature requests, form versions, patient shares and Token Builder tokens, which were left out before. Take a fresh backup after updating.
  2. 1.4.8 28 September 2026

    Consent forms patients sign electronically, by an emailed link, in their portal or on a tablet at the clinic, with the signer, date and time, IP address and form version kept as evidence and a signed PDF on the patient card. Doctors can share a patient with a colleague for view-only access. Send an email can carry attachments and reach everyone booked between two dates. A Clinic Doctor can no longer open another doctor’s patients by changing the address bar.

    • Consent forms patients sign electronically. Two new question types for forms placed in the patient portal or on a page: Document, the text the patient reads, and Signature. The patient ticks that they agree, types their full name and, if you ask for it, draws their signature. For each Signature field you choose whether drawing is required, optional or off.
    • Every signature keeps its evidence: who signed, the date and time, the IP address, the browser, how the form was reached and which version was signed. The exact text the patient saw is stored with the signature, so editing the form later never changes what they agreed to. Form versions are numbered automatically when the wording changes.
    • Tamper evidence. Each signature carries SHA-256 fingerprints, and the patient card shows Verified, or Does not match if anything has been changed since signing. Signed records cannot be edited; a withdrawal of consent is recorded beside the original.
    • A signed PDF with the document, the answers, the signature and the evidence, downloadable from the patient card. The patient is emailed a copy when they sign, unless you switch it off for the field.
    • Send a form for signature from the new Consent forms section on the patient card: a single-use link that needs no sign-in and expires after 7 days, or a sign-in link to the patient portal that stays open for 30 days. Waiting requests can be resent or canceled.
    • Sign at the clinic. Sign on this device opens the form full-screen, with no admin menu, for the patient to sign on a tablet at reception, with the staff member recorded as witness.
    • A Forms to sign tab in the patient portal lists forms waiting for the patient, the ones they have signed with a PDF copy, and Sign the new version when a signed form has changed. The signing screens are translated into all 13 languages.
    • Share a patient with another doctor. For a second opinion, a referral or holiday cover, Share with a doctor on the patient card gives a colleague view-only access to the card, clinical information, records and documents, with an optional note. The colleague is emailed a link with no clinical details.
    • A doctor can share patients they have treated; an administrator or clinic manager can share any patient and stop any share. A shared patient cannot be passed on. Sharing, stopping and opening a shared patient are written to the audit log, and the GDPR export lists who a patient was shared with.
    • Attach files to Send an email: up to 5 files, 10 MB in total, sent to everyone on the list. They are stored privately rather than in the Media Library, and are included in test sends and saved emails.
    • Email everyone booked between two dates. Booked on a day between, under Who it goes to, narrows the list together with the other filters. Both dates are included, and canceled bookings and no-shows do not count. A doctor counts only their own bookings.
    • Visited doctors on the patient card: every doctor the patient has seen, with the number of visits, the last visit and the next booked one.
    • The booking consent checkbox now records exactly which wording the patient agreed to, and keeps every wording you have used. A returning patient who books after you change it is recorded as agreeing to the new text. The patient card shows the date, IP address and wording version, with the text itself one click away.
    • PDFs can run to more than one page, with page numbers in the footer. Invoices and prescriptions are unchanged.
    • A Clinic Doctor could open another doctor’s patient card or medical record by changing the ID in the address bar, and could save records, send prescriptions, change appointments or send invoices for patients who were not theirs, in the admin and through the REST API. One rule now covers every screen and action. When two doctors have both seen a patient, each can read the other’s records but no longer edit them.
  3. 1.4.7 24 September 2026

    Patients can move their own appointment from the portal, within the notice you set and once per booking, and everyone hears about it exactly as if reception had moved it. The booking form gains a second design, Modern, with the steps down the side filling in with each answer. Rescheduled telehealth appointments now get a working video link, and Alnora runs on PHP 7.4 and newer.

    • Patients can move their own appointment. A new Patients can reschedule toggle under Settings → Feature toggles → Patients puts a Reschedule button in the patient portal, beside Cancel and on exactly the appointments Cancel appears on. The patient picks a new day and time from the same free times the booking form offers — same doctor, same service, same location. Off by default.
    • Min. rescheduling notice (hours) under Settings → Booking rules, 24 by default. Inside that window the button goes away and the patient is asked to contact the clinic. Each appointment can be moved by the patient once; after that, changes go through the clinic.
    • A patient’s move is announced exactly like one made at reception: the patient’s email, SMS, WhatsApp and Telegram messages, the clinic’s Reschedule notification, Google Calendar and Outlook, and the Zapier webhook. The clinic’s email gains a Moved by: line, also available as the {moved_by} token, and the Zapier payload carries moved_by.
    • The reschedule calendar speaks the patient’s language — month names, weekdays, dates and times follow Settings → Language and your site’s time format, with the right grammar per language — and every new portal message is translated into all 13 languages.
    • A second look for the booking form — Modern. A new Design tab under Settings, beside Customization, lets you choose between Classic, the form as it has always been, and Modern, which puts the steps down the right-hand side and fills each one in with the patient’s answer as they go: location, doctor, service, date and time, with the running total underneath. On a phone the steps become a compact strip under the heading. Classic stays selected until you change it.
    • Modern uses only the colors, font, corners and shadows from Customization, so it follows your branding the way Classic does. Every design books in exactly the same way — a design changes how the form looks, never what it does.
    • A patient who goes back to check an earlier step can jump straight back to where they were. A later step can be clicked as long as every step before it still has its answer; choosing a different doctor still clears the later answers. Works in both designs.
    • The admin screens now use US English spelling. What patients see is unchanged.
    • Feature toggles are grouped — Booking, Choosing a doctor or service, Patients, Forms & messages and Your clinic — and laid out in columns.
    • Alnora now runs on PHP 7.4 and newer, down from 8.1, for clinics whose hosting has not moved on yet.
    • A rescheduled telehealth appointment sent the old video link. The new meeting was created after the messages announcing the new time had been written, and the patient’s rescheduled email did not include the link at all. The new meeting is now made first, the email includes it, and {meet_link} is available in the Reschedule template.
  4. 1.4.6 18 September 2026

    Token Builder: your own tokens for every email, SMS, WhatsApp and Telegram template — a branded button, a link, a paragraph, a notice or an image, written once and aimed at exactly the patients it is for. Reminders also go out within about five minutes of when they are due, instead of on the next hourly check.

    • Token Builder — your own tokens for every template. A new Tokens screen under Forms, where you build a piece of content once and place it in any email, SMS, WhatsApp or Telegram template exactly like {patient_name}: a branded button, a link, a heading and paragraph with an optional link, a highlighted notice, or (in email) an image from your media library. Each token gets its own {my_…} placeholder, made from the name you give it, and changing it once on the Tokens screen changes every template that uses it. Switched on under Settings → Feature toggles, and administrators only, because only administrators can edit templates.
    • Aim a token at the patients it is for. New or returning patients; patients whose appointment is with a particular doctor, service, location or category — a new patient’s first booking counts from its confirmation on; and patients who have seen a particular doctor, had a service or been to a location before. “Before” means visits that went ahead: cancelled and missed appointments do not count, and neither do bookings still to come. With only New patients ticked, the earlier-visit choices are hidden, because a new patient has none. A sentence under the choices says who will see it.
    • A live preview in your own branding. An email token is previewed inside a real email — your header, colours and corners — built the same way the real message is, and an SMS or Telegram token as a chat message on a phone. Buttons and notices use your Customization colours, so they match everything else you send.
    • Your tokens appear in every template editor, under Your tokens beside the built-in ones, ready to click in — and in Send an email. The Tokens list shows which templates each one is in, with search, a filter by channel, copy, edit, duplicate and delete.
    • A patient never sees a raw {my_…}. A token that is switched off, deleted, aimed at someone else or written for another channel is left out of the message cleanly, with no gap where it would have been — and switching Token Builder off takes every token out of every message at once. The placeholder is fixed once saved, so renaming a token never breaks a template that uses it.
    • Reminders now go out within about five minutes of when they are due, rather than on the next hourly check — which could be up to an hour late. Existing sites move to the new schedule on their own. WordPress runs these checks when someone visits your site, so on a quiet site a server cron job still gives the most punctual reminders.
    • A reminder could in rare cases be sent twice when two checks overlapped. Each reminder is now claimed before it is sent, so only one check can send it.
  5. 1.4.5 12 September 2026

    Control over what your New booking email actually says: every question you ask now has its own switch for whether the answer appears there. Alongside it, Send an email reaches a service, a category or a location rather than only a doctor, your forms get a name and an introduction written for patients rather than for you, and the Zapier field that would not save without a page reload is fixed.

    • Choose which answers appear in your New booking email. Every custom field you ask on the booking form has always been printed in the notification the clinic receives, which is right for the two or three that tell the front desk something and wrong for the twenty that do not. Each field now has its own switch — Custom fields → the settings icon → Where the answer goes — and turning it off takes that answer out of that email, both from the {custom_fields} block and from its own token, so it is gone however your template is written. The answer is still saved exactly where you told it to go, and the patient’s own confirmation email is untouched. Every existing field stays switched on, so your notification reads today as it did yesterday until you decide otherwise.
    • Send an email now goes to a service, a category or a location, not just a doctor. Who it goes to adds a group for doctor categories, services, service categories and locations, each folded away with its own search, so “everybody who has had physiotherapy at the Harbour clinic” is two ticks rather than a list read by hand. Tick more than one thing in a group and it means any of them; tick things in two groups and it means both — so that example is the people in both lists, which is what it reads like. A doctor still reaches only their own patients, and the list is still rebuilt on the server when Send is pressed, so the groups narrow it and can never widen it.
    • A name and an introduction your patients see, in their language. Edit form gains Form name for patients and Description for patients. The form’s own name stays yours — it is what you search for on the Forms screen and what appears on a patient’s profile — and patients never see it, which frees you to call something “Reyes intake v3”. What they see is the name you write here, with the description under it before the first question: why you are asking, roughly how long it takes, that they can leave a question blank. Both appear in the portal and on a page, both are optional, and leaving the name empty shows the form name exactly as before.
    • Multiple forms can be switched off, with a toggle under Settings → Feature toggles. Off, the Forms menu goes away and every booking uses Settings → Form, which is what a clinic with one set of questions wants. Your forms are not touched — switch it back on and they are exactly as you left them.
    • You can see a form on its page without signing in as a patient. A form on a page requires a patient sign-in, which meant the person who built the form was shown the login panel on the page they had just published. An administrator — or a doctor, for their own forms and the ones shared with them — now sees the questions instead, marked as a preview, and nothing typed there is saved. Every question is shown, including any aimed at only some patients, because with nobody signed in those rules have no one to be true of. A draft is previewable too, and says that patients are still seeing nothing on that page yet.
    • Custom field tokens now end in the form they belong to — reason_for_visit_4 on form 4, _main on Settings → Form — so the same token ID can be used on as many forms as you like without two forms fighting over one answer. The ending is added for you and shown in the field, and fields you already have keep the ID they already had, so no template, webhook or export changes. A form gets its number when you first save it, so on a brand-new form the ending appears after the first save.
    • The per-field tokens in the New booking template are folded away. Settings → Email templates listed one token button for every question every one of your forms asks, which on a clinic running a few forms was a wall of them above the handful the template is actually built from. They now sit behind Show all custom fields separately, with the number in brackets so you know what is in there. {custom_fields}, which prints them all in one go and is what most clinics use, is still listed where it was.
    • Saving a form, doctor, service or location leaves you where you were. All four used to bounce you back to the list, so correcting one line meant finding the row again and reopening it. You now stay on the thing you just saved, with the notice at the top of it.
    • More styling hooks in the patient portal and on form pages. Every part now carries a class naming what it is, and each question carries its type and its own token ID, so “make the consent question full width” is one line of CSS rather than counting positions that change the next time you add a question. Everything already there is untouched, so any styling you have written keeps working.
    • The Multiple services toggle is now Multiple services booking, which is what it decides — whether one booking can hold more than one service.
    • Zapier webhook addresses would not save without reloading the page, and were especially bad when replacing one. The protection that stops a browser’s password manager quietly filling saved fields was treating a webhook address as one of those, so sending the same catch hook to two events — an ordinary thing to do — made both refuse. Two separate faults: that, and the field never going back to showing the saved address after a save, which both hid the fact that it had worked and sent the value back again on the next save.
    • A condition on a field sometimes did not save. The popup wrote to the server on every click, so building one rule fired a dozen overlapping saves whose replies could come back in any order, and the last one to arrive won. It now writes once, when you close the popup — by Done, by the ×, by Escape or by clicking away, all the same.
    • Duplicating a form copied the original’s token IDs, so the copy and the original wrote to the same answers — the exact collision the endings above exist to prevent. A copy now gets its own.
  6. 1.4.4 10 September 2026

    Send an email. Everything else Alnora sends is a consequence of something the patient did — they booked, they paid, their appointment is tomorrow. This is the one screen where you write to your patients yourself: the surgery is closed on Friday, a new practitioner has joined, the flu clinic is open.

    • Send an email — a new item in the Alnora menu, under Forms. Write a message and send it to the patients you choose, with headings, bold, lists, images and buttons, and use {patient_name} and the other tokens so each person gets their own copy rather than a circular. It goes out from your clinic address, the same sender as every reminder and confirmation — an email claiming to come from an address your website is not authorised to send for is what spam filters are built to catch.
    • You see the email before anyone else does. The preview is built through exactly the same pipeline as the real send, so it is the email rather than an impression of it, and a test send puts one in your own inbox before you commit to the list. Both fill the tokens with sample details rather than a real patient’s, so checking a layout never puts somebody’s name in an inbox it does not belong in.
    • Doctors can write to their own patients. A doctor sees only the patients they have actually seen, and the list is rebuilt on the server when Send is pressed rather than trusted from the browser, so it is a real boundary and not a filtered screen. Reception cannot send at all: taking a booking and writing to the whole patient list in the clinic’s name are different things.
    • Sending happens in the background in small batches, so a list of several hundred does not hang the page or time out half way. Progress is shown and kept if you navigate away or close the tab, and a send can be stopped part-way — the patients already emailed keep the message, and nobody else is written to.
    • You can also send to addresses that are not patients — a colleague, a referrer, your own second mailbox — in the same send as the patients you ticked, so one progress bar and one Stop cover everybody.
    • Save an email you will send again — holiday closing times, a recall notice, the seasonal clinic — and start from it next time. Saved emails are personal to the account that saved them: a doctor sees the ones they wrote and nobody else’s, and so does each administrator. These are working drafts rather than clinic policy, so half-finished wording is not put in front of the whole practice, and nobody can delete or overwrite somebody else’s.
    • A short history of what has already gone out, at the bottom of the screen: the subject, when it finished, how many of the chosen recipients were written to and — where more than one person can send — who sent it. A send stopped part-way is listed as such with the number it reached, and anything that could not be sent shows the reason your mail server gave. A doctor sees only their own sends; whoever runs the clinic sees them all, with the sender named.
    • Patients now sits above Forms in the Alnora menu.
  7. 1.4.3 7 September 2026

    Forms — named sets of questions of your own, shown to the right patients on the booking form, in the portal or on a page of their own. Two security changes worth acting on: your encryption key can be moved out of the database, and the value stored beside each patient’s email is now keyed rather than a plain hash. Alongside them, a proper Import/Export screen, documents on the patient’s page, and doctors managing their own services.

    • Forms — a new item in the Alnora menu. A form is a named set of questions that stands in for the one in Settings → Form: the intake questions for one doctor’s assessments, a pre-visit questionnaire, a consent form. Each form says where it is used — on the booking form (and on Add appointment, so your staff are asked exactly what a patient booking online is asked), in the patient portal, or on a page of its own. Settings → Form is still THE form and still what every booking falls back to; a form here is an override of it. A booking made through one takes payments, syncs calendars, sends reminders and fires webhooks exactly as any other booking does — a form decides the questions and nothing else.
    • Conditions decide which form a patient sees: doctor, doctor category, service, service category, location, or new versus returning patients. Forms are matched top to bottom in the order on the screen and the first active one that fits is the one used, so dragging a row changes which wins. They do not stack — two forms both asking “Referred by?” would ask the patient twice, and neither would be answerable for what they saw.
    • A form on a page of its own, with [alnora_form id="3"] — the shortcode is shown on the Forms screen ready to copy. The patient signs in on that page and comes back to it rather than being sent to the portal. Signing in is required because the answers are written to a patient’s record, and the alternative is trusting an email address typed into a public box, which would let anyone who guesses an address write to that person’s notes. One consequence worth knowing: whoever fills in a page form is signed in and therefore always a returning patient, so a question aimed at new patients could never appear. The editor refuses to save that rather than leaving you with a form that renders empty.
    • The usual fields on a form start from your Settings → Form values. Change a label, placeholder or “required” here and it applies to this form only; leave it alone and it follows your settings, so relabelling a field once still reaches every form you have not deliberately changed. Name and email are always asked and always required — a booking without them cannot become a patient record — though you can still rename them.
    • “Who has access” is set per form: by role, by doctor category, or by named doctor. Doctors get their own My forms screen showing the forms they created and the ones shared with them, so a doctor is never handed the clinic’s whole list. A form they may see but not change can still be duplicated, so a clinic-wide questionnaire is a starting point for their own version rather than something to retype.
    • Answers to a form are kept as history rather than overwritten. Every submission is its own row, which is the whole reason forms have their own store: “how is the pain this week?” asked before every visit is destroyed by keeping only the latest answer. They appear on the patient’s page under the form’s own name, the most recent open and earlier ones folded behind it, and are gated by exactly the same access as the cards above them — a role that can record a clinical answer without reading it back cannot read one here either. Deleting a form does not delete answers patients already gave; erasing a patient does.
    • Forms can be left as drafts, duplicated and searched. A draft is never matched, so a form can be built over several sittings without a patient meeting it half-finished.
    • Your encryption key can be moved out of the database. Patient records were always encrypted, but out of the box the key that opens them was generated into the same database — so a copy of the database was a copy of the data. Settings → GDPR → Encryption key shows the exact line to paste into wp-config.php and then removes the database copy for you. It is your existing key, so nothing is re-encrypted and nothing changes for your patients or staff. A warning appears until it is done, and once it is, that line is the only copy: keep it somewhere safe, because backup plugins do not back up wp-config.php.
    • The key can go in any of three places, so no host is a reason to leave it in the database. wp-config.php is still the recommendation, but the screen now also gives you a ready-made must-use plugin (wp-content/mu-plugins/alnora-key.php) for hosting that keeps wp-config.php out of reach, and your theme’s functions.php works too. Alnora can tell when the key is arriving from your theme and warns you, because a theme update that replaces functions.php — or switching theme — takes the key with it and leaves every patient record reading as blank.
    • Import/Export. Six lists, each with its own export and import as CSV: doctors, doctor categories, services, service categories, locations and patients. Export first and you have a template with your own data already in it. Rows are matched to what you already have and updated, so the same file can be imported twice without creating duplicates.
    • Export or restore your whole clinic as one file — every table and all your settings, for moving to another site or putting things back after a problem. Encrypted information stays encrypted in the file, so it is not a readable copy of your patient records; the site you restore it on needs the same encryption key, and Alnora checks before it starts rather than leaving you with a clinic of blank names. Your key and your Google/Outlook calendar credentials are never written into the file.
    • Documents on the patient’s page, under Other information. Files held for the patient generally rather than for one appointment — a referral letter, an earlier scan, a form signed on paper. Stored in the same protected area as a medical record’s documents and never reachable by URL. The patient does not see them in their portal.
    • Doctors can manage their own services. A doctor gets the same Services screen the clinic has, scoped to their own: add, edit, reorder and assign categories. A service shared with other doctors is read-only to them — only the clinic can change it. The order a doctor sets wins over the clinic’s ordering, because they are arranging their own list.
    • “Add it to the patient’s section for this form” — a per-field choice replacing the old form-level “Add the answers to patient’s profile” switch. A questionnaire that asks one thing worth a clinician’s eye and four worth nobody’s is the normal case, and the old switch could only say all or nothing. Existing forms are converted on update and keep their section.
    • The value stored beside each patient’s encrypted email is now keyed with your encryption key. It used to be a plain hash of the address, which is reversible in practice — anyone with your database could hash a list of people and see which of them are patients of yours. Existing records are converted in the background; there is nothing to do, and returning patients keep being matched to their own history throughout.
    • Form conditions now read the right thing for where the form is. On a booking form they are read against the booking being made — the doctor, services and location the patient chose. On a page or in the portal nobody is booking anything, so they are read against the patient: a doctor means their patients, a service means people who have had it, a location means people who have been there. Previously the rules on a page or portal form were stored, shown in the editor and never consulted, so every patient got every form however carefully it had been aimed.
    • The field settings only offer what applies. “Send it to Zapier webhooks” and “Show it to staff on Add appointment” no longer appear on a portal or page form, where they decide nothing. Settings you have already made are kept rather than cleared, so moving a form between placements loses nothing.
    • The patient portal saves each form on its own. Correcting a phone number no longer means re-submitting every questionnaire the clinic asks, and a required question in a form the patient did not intend to touch no longer blocks the whole save. Each form is a row in a list, closed until they open it.
    • Importing doctors is far more capable, and no longer duplicates. It reads categories, locations, bio, photo and active as well as name, email and specialisation, and rows are matched to the doctors you already have — on email, or on name when your file has no email column. The old import appended blindly, so re-running a file doubled your list.
    • A column your import file does not have is left alone, and a column that is there but empty clears the value. So a two-column file fixing everyone’s phone number cannot wipe anything else on the row.
    • The “Who has access” column on the Forms screen said “Everyone on the team” for a form nobody had been given access to. With nothing ticked a form is now visible to administrators only, and the column says so.
    • Plain links in the booking form, portal, form pages and invoices no longer carry an underline until you hover them.
    • Answers a patient gave at booking never reached their portal. A field marked “Show it to the patient in their portal” and nothing else was never saved against the patient, so the portal listed it as “Not answered yet” for ever — while the clinic could read the answer perfectly well on the appointment. The switch is now called “Save and show it to the patient in their portal”, because that is what it does. Answers given from now on are stored; existing bookings are not converted, because a patient with several past bookings has a different answer on each and only the clinic can say which is current.
    • A portal form still showed “Not answered yet” straight after the patient saved it. The answer was kept as a submission of that form and nowhere else, while the portal only ever read the patient-level copy.
    • File uploads on a portal form answered “Not allowed”. A field on a portal form has no reason to carry the portal destination — the form is already in the portal — but that was the only thing the upload route would accept.
    • Add an appointment showed the clinic’s general form even when the doctor had one of their own. Two separate causes: the screen was only ever sent one set of fields, and choosing a doctor from the search list fired no event, so nothing was re-read. The second of those had also been quietly breaking field conditions on that screen for as long as the picker has existed.
  8. 1.4.2 30 August 2026

    A large release. Custom fields grew up — you now choose who is asked each question, when it appears, and where the answer is kept, and patients can maintain their own details in the portal. Reminders can be sent more than once. Bank transfer joins the payment methods, so a clinic Stripe and PayPal do not cover can still take payment online.

    • More than one reminder per appointment. Settings → Email & reminders now holds a schedule instead of a single lead time: add a row for each moment you want to remind at — 24 hours before, 3 hours before — up to six. Every row has its own channels, so you can email the day before and text three hours out. Columns appear for the channels you have switched on, and turning one off hides its column without forgetting how you had it set.
    • Returning patients can sign in on the booking form. “Already a patient here?” opens a sign-in above the details step; once they are in, their name, email and phone are filled in for them and the booking attaches to their existing record instead of creating a second one. A “Booking as …” bar shows who is signed in, with a way to sign out and book for someone else.
    • A forgot-password box under that sign-in, so a patient who never set a portal password — or has forgotten it — can ask for a link without leaving the booking form. It replies the same way whether or not the address is registered, so it cannot be used to find out who is a patient of yours.
    • “When to show this field” — conditions on any field. Show a field only for certain doctors, services or locations, or only when another field was answered a particular way. Rules can require all conditions or any of them, and the same dialog works for the built-in fields and your own.
    • Choose who is asked each custom field: patients booking online, your staff on Add appointment, or the patient in their portal. A field can be staff-only, or one the patient maintains themselves and is never asked at booking.
    • Choose where each answer is kept — five explicit switches: the patient record, the patient’s clinical information, the patient’s contact details (personal information), the patient’s portal, and Zapier webhooks. “Clinical information” lists the answer in that card on the patient’s page, above Allergies, so a question the clinic set sits with the allergies and conditions rather than among the contact details. It needs medical-records access to read, so a receptionist can take one down the phone without being able to read it back, and it is held back from your webhooks unless you say otherwise. Whether an answer reached your webhooks used to be worked out from the other settings and could not be overridden; it is now your decision, and a field nobody edits keeps behaving exactly as it did.
    • Patients can fill in and change their own details in the portal. Their name and phone number sit at the top of “Your details” and can be corrected there — the two things most likely to have changed since they last booked. Their email address cannot: it is the login behind the portal and the identity every appointment is matched on, so changing it is an account operation rather than a detail edit. Below them, fields marked to show in the portal appear as an editable form — including file uploads, so a patient can send a referral letter or a scan before their visit. Answers are saved against the patient, never against a past appointment.
    • An “Other information” field on the patient’s clinical information, for anything standing that is not an allergy or a chronic condition — mobility needs, an interpreter, who to contact.
    • An ID column on the Patients list and on Data export & erasure, and both searches now match on ID as well as name, email and phone. Useful when a patient’s name is spelled two ways in your records and the ID is the only thing you can be sure of.
    • A {hours} token in the reminder templates, so one template can tell the day-before reminder from the one a few hours out.
    • Bank transfer as a payment method. The patient is shown your account details and a reference, and the appointment time is held while the money is on its way. You check your bank, press “Mark transfer received”, and the booking is confirmed and the patient emailed — from there it behaves exactly like any other paid booking. There is no gateway to apply to and no per-payment fee. Switch it on under Settings → Payments and enter your account details.
    • It works in any currency. Stripe and PayPal each refuse currencies they do not process, and Alnora hides them when yours is one of those — leaving some clinics with cash as their only option. A bank transfer has no such list.
    • Bank transfer can be paid from an emailed payment link too, including a balance left after a deposit. Choosing it on the invoice page hands over the account details and holds the appointment instead of opening a checkout.
    • A “Bank transfer — how to pay” email carrying your account details, the amount, the reference and the date by which the money should arrive. It has its own switch and template under Settings → Email & reminders, and is translated into all twelve languages.
    • A hold window for bank transfers, in days. If the money never arrives the slot is freed automatically, so an unpaid transfer cannot block a time indefinitely. Set it to 0 if you would rather chase the patient and free the slot yourself.
    • Reminders now go out when they are due. A reminder used to be sent on the first hourly check after the appointment came inside the lead time, which for a booking made well in advance could be almost a full day early. One consequence worth knowing: a reminder whose moment has already passed is now skipped rather than sent immediately, so someone booking two hours ahead is no longer sent a “3 hours to go” message the instant they finish. If your only reminder is a long one, patients who book inside that window now receive no reminder rather than an instant one.
    • If WordPress’s scheduled tasks stall for a few hours, a reminder that fell due in the meantime is still sent on the next run rather than skipped, up to six hours late.
    • Allergies, Chronic conditions, Other information, Private notes, Diagnosis, Prescription and a doctor’s Bio are now written in a proper editor — paragraphs, bold, and bulleted or numbered lists, the same as a service description. A list of four medicines reads as four lines rather than as one unbroken paragraph. Anything written before this update is left exactly as it was typed.
    • The prescription PDF keeps that structure. A numbered course of treatment stays numbered and a bulleted list stays bulleted, instead of collapsing into a single block of text — which, on the one document the patient actually follows, was a clinical problem rather than a cosmetic one.
    • Date and time answers are shown in your WordPress date format wherever they appear, instead of as the raw 2002-02-15 the browser stores.
    • The portal’s edit form matches the booking form: checkboxes, radio buttons, yes/no toggles and file uploads there now use the same controls and your own customised colours. Yes/no fields also show as a toggle on Add appointment rather than as a bare checkbox.
    • The Patient and Doctor names on a medical record link to their pages, so you can open the patient’s history from the record you are reading.
    • The Custom fields description now describes what these fields can do — who is asked, when a field appears, and where the answer is kept — rather than only booking-time collection, which was all they could once do.
    • Marking a transfer received also confirms the booking. Checking your bank and saying the money is there is the clinic confirming, so there is no second button to press. The patient gets the confirmation email rather than a “we have received your request” message, which by that point would be a step behind.
    • Each payment method’s settings are now hidden until you switch that method on. A clinic taking cash and bank transfer has no reason to look at four Stripe fields. Nothing is deleted by hiding it — switch a method back on and its saved keys are exactly where you left them.
    • Patients are asked to put the booking reference in the note on their transfer, labelled “Important Note” rather than “Reference”, because that is what their banking app calls the box. It is the same reference shown in Appointments and on their emails, so you can match a payment to a booking.
    • Alnora is honest about what it cannot do here: it has no sight of your bank account, so it cannot know when a payment arrives. Every held booking shows “Awaiting bank transfer” with the amount and reference to look for on your statement, and one button to settle it.
    • If the booking form ever cannot find its settings, it now says so on the page instead of showing an empty box, so you know to reload rather than assuming the form is broken.
    • A “Checkboxes” answer with more than one tick was stored as the word “Array”. It affected bookings made by staff on Add appointment; the booking form was never affected, because it joins the ticks in the browser before sending them. The wrong value went onto the appointment and was then copied to the patient record, so it appeared everywhere that answer was shown. New bookings are stored correctly — answers already saved as “Array” have lost the original ticks and need re-entering.
    • Doctors could not read custom-field answers saved to a patient’s contact details. The patient page requires medical-records access to open, which a receptionist does not have — so the extra check on those answers only ever hid them from the doctors who could open the page, with the medical record sitting on the same screen. Doctors now see the answers in both the Contact and Clinical information cards. Nothing changes for reception: a clinical answer is still one they can record and not read back.
    • Files patients upload are no longer visible in the Media Library. The file itself was already stored privately, but its Media Library entry was not hidden — so a referral letter or a scan could be found by anyone who could open that screen. Clinical uploads are now kept out of both the Media Library list and the file picker, and their attachment address no longer points at the file on disk.
    • Custom fields did not appear on Add an appointment at all, so staff booking for a patient over the telephone could not record the answers.
    • After signing in on the booking form, a second copy of the form appeared below the first.
    • Signing out of the patient portal showed WordPress’s own “Do you really want to log out?” page. Patients are now simply signed out.
    • The field settings could not be saved on a newly added custom field.
    • On a small number of sites the booking form never got past “Loading…”. The form’s settings are sent to the page as a separate inline script, and on some hosting setups that script did not reach the browser at all, leaving the form with nothing to work from and no way to say so. Those settings now also travel inside the form’s own markup, which cannot be separated from the form, so it has what it needs even when the inline script goes missing. Nothing changes on sites where the form already worked.
  9. 1.4.1 23 August 2026

    Stripe payment methods that settle after checkout — vouchers, bank transfers and direct debits — now work properly. Previously the appointment could be released while the money was still on its way.

    • A payment that arrives after checkout no longer costs you the appointment. If a patient paid with a method that settles later — a voucher paid in cash at a shop, a bank transfer, a direct debit — Alnora treated the booking as abandoned and released the slot while the payment was still in transit. The money then landed with no appointment against it, and nothing said so. The slot is now held until Stripe confirms the payment either succeeded or failed. Card and PayPal payments were never affected and behave exactly as before.
    • The slot is held the moment the patient finishes checkout, rather than when Stripe’s notification reaches your site. Stripe returns the patient and notifies your site at the same instant, and the return used to win that race and delete the booking — on a clinic with no webhook endpoint set up, every time.
    • The same money can no longer be taken twice. While a delayed payment is in transit the invoice page tells the patient it is on its way instead of showing the Pay button again, and staff cannot send a second deposit, balance or full-amount link for that appointment. Both were previously possible, and only one of the two payments would have been recorded.
    • A patient paying by one of these methods is no longer told their payment failed on the way back from Stripe. They now see that their appointment is being held while the money makes its way over.
    • PayPal payments that had not actually arrived were being recorded as paid. PayPal can complete a capture while the money is still in transit — an eCheck funded from a bank account, or a payment held for review — and Alnora read only the order, so the booking was confirmed and the records said the money was in. If that payment was later denied or reversed, nothing said so: the booking stayed “Paid” with nothing behind it. PayPal now behaves exactly like Stripe — the slot is held, the patient is told, and the booking is confirmed only once the funds land.
    • A specific hour set for a location could not be booked. Where a doctor had specific start times at a location, any of those times falling outside the doctor’s default working hours was offered to the patient and then refused as “no longer available” — a booking that could never succeed. A 22:00 clinic was rejected while 10:00 worked, because 10:00 also existed in the default hours. The booking check now reads the location’s own schedule, as the rest of Alnora already did.
    • Local payment methods now work end to end. Whatever you switch on in your own Stripe Dashboard is offered at checkout, including the pay-later methods above — there is nothing to configure in Alnora. The one requirement is that your clinic currency matches the one the method needs, since most local methods are tied to a single currency.
    • A “Payment in progress — slot held” email. A patient paying by one of these methods would otherwise hear nothing for a day or two after booking, and either book again or telephone the clinic. It has its own switch under Settings → Email & reminders, and it is deliberately worded as a hold rather than a confirmation, because the payment can still fail.
    • The Appointments list shows “Payment in progress” for a booking whose money is still in transit, so reception can tell it apart from one that was simply abandoned mid-checkout. A booking whose deposit is settled and whose balance is still on its way reads “Deposit paid · balance in progress”.
    • Settings → Payments now lists every webhook event to subscribe to, for both Stripe and PayPal, with a line on what each one does. The documentation has a full Webhooks page covering the address, both gateways, how to confirm deliveries are arriving, and what to check when they are not.
    • The new patient email, and every other new message a patient can see, are translated into all twelve languages Alnora ships with.
  10. 1.4.0 20 August 2026

    A doctor’s hours can now be set as specific appointment times rather than an opening window — per day and per location — and the booking form, patient portal and invoice page gained a lot of CSS classes for theming.

    • Each day of a doctor’s schedule now has an Hours mode. Left on “Start to end” nothing changes — the same start, end and break as before. Switched to “Specific hours” you pick the exact start times patients can book, from a grid built on your slot interval, with Fill, Clear and Copy to all days. Useful for a clinic that only takes appointments on the hour, or a consultant who sits three fixed slots on a Thursday. The mode is per day, so Monday to Thursday can stay a window while Friday runs on set times.
    • Specific hours work per location. Each location keeps its own mode and its own times, exactly as start and end times already did, and a location with no schedule of its own still falls back to the default one.
    • A doctor signed in with the Clinic Doctor role sees their set times listed on My profile, per location, instead of a start-to-end range that would not have described their day.
    • Many more CSS classes on the booking form, patient portal and invoice page, so a theme can style them without overriding the plugin. The booking form marks the current step on its container and gives every doctor, service and time slot its own class. The patient portal gained around twenty, including per-tab panels, appointment rows carrying their status, and classes on the appointment title, meta line, join link, cancel button and medical-record fields — several of which had no class at all. Invoice summary rows now carry a language-independent slug rather than being identifiable only by their translated label. Nothing was renamed or removed, so existing custom CSS keeps working.
    • The working-hours editor is usable on a phone. Below 1024px the settings row and its times grid stay one card instead of splitting in two, the time fields are labelled now the table header is hidden, and the picker reflows for narrow screens.
    • The note under the Language selector links to the contact form again, with the subject “Language request”, rather than to the documentation page.
  11. 1.3.9 16 August 2026

    Your API keys are now stored hidden instead of being printed on the Settings page, and a Google Calendar connection can no longer drop — or fail to connect — without telling you why.

    • Secret keys, tokens and webhook URLs — Stripe, PayPal, Twilio, Telegram, Google, Microsoft, Zoom and Zapier — are no longer readable from the Settings screen. Each field shows a short fragment, enough to tell which credential is in place, with Replace and Remove buttons instead of an editable box. Client IDs and account SIDs, which you need to compare against your provider’s console, stay readable.
    • The Zoom credential fields are hidden when the telehealth provider is Google Meet, which creates its link through the connected Google Calendar and never uses them. Switching back to Zoom brings the fields back with your saved values intact.
    • The note under the Language selector now links to the Language request page in the documentation rather than the contact form, so you can read how the process works — including that we ask you to check the wording before it ships — before getting in touch.
    • A Google Calendar connection that dropped without saying why. Alnora recorded only the bare code “invalid_grant”, with no reason and no timestamp, and the Settings page always blamed the OAuth app being in Testing mode — wrong for apps published to Production. The reason Google gave is now recorded verbatim, with a timestamp, and the last five attempts appear under Connection diagnostics on the Calendar tab.
    • Connecting Google Calendar could report success when it had failed. Pressing “Connect Google” with an empty client ID or secret sent you to a bare “Error 401: invalid_client” page at Google; and if Google refused the token exchange, Alnora still returned showing “Saved successfully” while nothing had been connected. Both now say what actually went wrong.
    • Calendar sync could fail silently while Settings still showed “Connected”. With the Google client ID or secret missing, every renewal failed with an error that was not treated as a disconnect, so the badge stayed green while nothing synced. That state is now flagged in red, naming the field to fill in.
  12. 1.3.8 12 August 2026

    Ask us for a language that is not yet in the list, and a fix to the developer utility that compiles translation catalogs.

    • Request your language. If the language your patients speak is not in the Language list under Settings → General, a note under the selector now links to our contact page — send us a message with the subject “Language request” and we will add it to a future release.
    • The developer utility that compiles a hand-edited .po translation into the .mo file WordPress reads wrote a malformed index and omitted the catalog header, so WordPress silently discarded the whole file and the plugin stayed in English. It now writes a valid catalog and understands wrapped lines, contexts, plurals and escapes, so translations edited in Poedit or Loco Translate apply correctly. The language files shipped with Alnora were built by a different script and were never affected.
  13. 1.3.7 10 August 2026

    Auto-clean the Consent log and Access audit log after a retention window you set, and a clearer GDPR dashboard — patient and staff names, an IP column on the audit log, per-table search, and a full-width stacked layout.

    • Auto-clean GDPR logs. Set a retention window in months for the Consent log and Access audit log under Settings → GDPR — entries older than that window are removed daily. Minimum 3 months; leave at 0 to keep entries forever.
    • The Consent log and Access audit log now show patient full names instead of numeric IDs, the staff member’s display name instead of a user ID, and the Access audit log gains an IP column.
    • A search box above each table on the GDPR page (Data export & erasure, Consent log, Access audit log) filters rows on the fly. The two logs are also now full width, stacked one under the other, for easier reading on wide screens.
  14. 1.3.6 5 August 2026

    Price and invoice in almost any currency — 149 world currencies, grouped by region — with online payments offered only where Stripe or PayPal can actually process them.

    • 149 world currencies in the clinic currency selector, grouped by region — Europe, Middle East, Africa, Americas and Asia & Pacific — each with the correct symbol, so almost any clinic can price and invoice in its local currency.
    • Online payments are now offered only for currencies Stripe or PayPal can actually charge in. Pick a currency neither gateway supports and only cash / pay on arrival is offered, instead of a card button that would fail at checkout.
    • Corrected the display name of a few currencies in the selector (Croatian Kuna, Ukrainian Hryvnia and New Zealand Dollar).
  15. 1.3.5 2 August 2026

    Free Telegram reminders — patients connect once and receive their appointment messages on Telegram, with their own templates and a new Notifications tab in the patient portal.

    • Telegram appointment messages — free to send, with no phone number to manage. Create a bot under Settings → Telegram Bot, and patients connect once by tapping “Connect Telegram” in their booking-received email or the new Notifications tab in the patient portal. Telegram has its own editable message templates — separate from SMS & WhatsApp — each with a per-message send switch.
    • Choose where the “Connect Telegram” invite appears — in the booking-received email, in the patient portal, or both (Settings → Telegram Bot). The invite is hidden automatically once a patient has already connected, so nobody is asked twice.
    • A new Notifications tab in the patient portal, where a patient can connect Telegram and see their connection status. It appears only when Telegram is switched on and set to show in the portal.
  16. 1.3.4 26 July 2026

    Location photos and contact details on the booking form, a mandatory location when booking on a patient’s behalf, and richer Zapier webhooks — including a payment event for every visit in a recurring course.

    • Location photos on the booking form. Add an image to each location (Locations → edit → Location image) and it appears above the name when a patient chooses a branch. The branch’s address, email and phone now show there too, so patients can see and contact the right location before booking.
    • Add appointment now requires a location when your clinic has more than one branch. The “Any location” option has been removed, so a booking made by staff is always tied to a specific branch — matching how the booking form already works.
    • Richer Zapier webhooks. Every event now carries a readable payment method (Card / PayPal / Cash), a per-charge breakdown — so a Card deposit and a PayPal balance appear separately with their own gateway references — and the appointment’s full location details (name, address, email, phone).
    • A payment webhook for every visit in a recurring course. Paying a recurring series — at booking, or later from an emailed invoice link — now sends a Zapier payment event for each appointment in the series with its own amount, instead of a single event for the whole course. The patient still receives just one email.
    • A duplicate, zero-amount payment webhook. Paying a balance from an emailed invoice link could send a second Zapier payment event a moment later showing a zero amount; only the genuine payment is now sent.
    • Calendar sync that could silently stop. When Google or Microsoft dropped the calendar connection, Settings still showed “Connected” while appointments quietly failed to sync. Alnora now detects a dropped connection and shows a clear reconnect prompt, and no longer tears down a working connection over a brief network blip.
  17. 1.3.3 24 July 2026

    Prescription emails, your clinic logo on documents and emails, an optional surname field, and rebuilt revenue reports with refund-aware net totals and date-range filters.

    • Prescription emails. A translated Prescription email template joins the others under Settings → Email, with an “Attach prescription PDF” option and a “send automatically when the appointment is completed” switch. From a patient’s medical record you can also send it by hand with one click, and see when it was last sent and to whom. It is only sent once a diagnosis or prescription has been added, and an automatic send never repeats one you already sent by hand. The patient’s portal login details have moved from the invoice PDF to the prescription PDF.
    • Your clinic logo on documents and emails. Add a logo under Settings → General. It appears at the top of the invoice and prescription PDFs in place of the clinic name, and — if you choose — in the header of every patient email (Settings → Email & reminders → Email header: clinic name or clinic logo, with an adjustable width).
    • Split the name field into Name and Surname. An optional Surname field for the booking form (Settings → Form → Core fields), off by default. When enabled it is collected in its own box and stored and shown together with the name everywhere.
    • Rebuilt revenue reports. Filter every figure by date range — this month, last month, last 30 days, last 12 months, this year, or a custom from/to. See net revenue, gross collected and refunds separately, the number of paid appointments and the average per paid appointment, and net revenue broken down by month, by doctor and — new — by payment method. The CSV export follows the selected range and adds a signed amount column so it totals straight to net.
    • A “Soft — 4 px” corner radius option under Settings → Customization.
    • More Zapier webhooks. Zapier now also fires when an appointment is refunded, completed, or marked a no-show — each with its own optional URL under Settings → Integrations → Zapier — alongside the existing created, confirmed, cancelled, rescheduled and payment-received events. The refund event carries the amount and whether it was a full or partial refund.
    • Require a deposit — hide cash when one is set. A new option under Settings → Payments removes the Pay in cash choice from the booking form while a deposit is configured, so a patient can only hold a slot by paying the deposit online. It applies only when Stripe or PayPal is enabled, and is off by default.
    • Uploaded medical and booking files are now private. Files attached to a medical record, or uploaded through a booking file-field, are no longer stored at a public, guessable /wp-content/uploads/ address. New uploads go to a protected location, existing ones are moved there automatically on update, and each is served only through a signed link to your staff and the patient it belongs to.
    • Emails follow your Corner radius setting, so the email frame matches the booking widget; and when the header shows your logo, the colored header band is dropped so the logo sits on a clean background.
    • Reports now subtract refunds. Revenue figures counted completed payments but ignored refunds, overstating income; every figure is now net of refunds, with gross and refunds shown alongside. Revenue by doctor also lists a “Removed appointments” line for money collected on appointments that were later deleted, so the breakdown still reconciles with the total.
  18. 1.3.2 20 July 2026

    Richer invoices — attach the PDF to payment emails, itemize deposits and balances, and give every visit in a course its own invoice.

    • Attach the invoice PDF to your payment emails. Each invoice email now has an “Attach invoice PDF” switch under Settings → Email — the payment-link email can carry the unpaid invoice, and the payment-received email the paid one — so the patient always has a document to keep.
    • The invoice PDF now has a Status section showing the amount, how it was paid and whether it is paid or still due, so an invoice makes sense on its own without opening the appointment.
    • Deposit and balance are itemized separately on the invoice. When you take a deposit, the invoice lists the deposit and the balance on their own lines — each with its own amount, payment method and status — so a patient who paid the deposit by card and the balance by PayPal sees both.
    • The payment method is printed on paid invoices — Card, PayPal or Cash — shown only once money has actually been collected.
    • A separate invoice for every visit in a recurring course. Each appointment in a series gets its own invoice PDF with that visit’s own amount, and all of them are attached to the payment emails, instead of one invoice for the whole course.
    • A clearer message when a booking has been refunded. Trying to send a payment link for a fully refunded appointment used to say “This appointment is already paid”, which was confusing. It now explains the appointment was refunded and to cancel and rebook if one is needed.
    • Removed a stray developer note (a CSS class hint) from the custom-fields editor under Settings.
    • Some invoice labels showed in English whatever the patient language — “Full amount paid”, “Deposit paid” and similar now translate in all 13 languages, alongside the Card/PayPal/Cash payment-method labels.
    • A deposit that covers the whole price is now marked as paid. When a fixed deposit is larger than the service price — a €10 deposit on a €5 service, say — the appointment is recorded as paid in full and reads “already paid”, instead of showing a deposit with a negative balance the clinic could never collect.
  19. 1.3.1 17 July 2026

    Send a patient a link and let them pay online — deposits, balances and full amounts — and book patients in yourself from the admin.

    • Email a patient a payment link. The Invoice button on any appointment now opens a popup where you can download the invoice PDF as before, or send the patient a link to pay online. They pay by card or PayPal on your own site and the appointment is marked paid automatically — so a booking taken over the phone, or added by a doctor, no longer has to be chased by hand.
    • Deposit or full amount. If you take deposits, the Payment popup shows both figures with a button for each, so you can send the patient the deposit link or invoice the whole amount. The patient sees which they are paying, and a full payment is recorded as paid in full.
    • Collect the balance online after a deposit. Once a deposit is paid, the popup shows the deposit taken and the balance still owed, with a Send balance link button to email the patient a link to pay the rest by card or PayPal. A refund can then return the deposit and the balance together — even when they were paid on different methods.
    • See how a booking was paid at a glance. The Appointments list shows every method used — “Paid (PayPal, Stripe)” when a deposit and its balance went through different gateways — and refunds give you a separate control for each charge, labelled Deposit and Balance, so you can return either part on the method it was taken. For a recurring course, the figures are labelled as covering the whole series.
    • The popup shows the amount due, the address it will go to, and when a link was last sent and to whom — so nobody sends the same link twice, or keeps chasing a patient who has already been emailed.
    • Choose how long a payment link stays valid under Settings → Payments → Invoices — seven days by default. Links expire on their own, and rescheduling an appointment invalidates any link already sent, so a patient can never pay against a time that has since moved.
    • An Invoice / payment link email template joins the others under Settings → Email, with tokens for the patient, service, doctor, date, amount, reference and the payment button, so the wording and the translation stay yours.
    • A Pay Invoice page is created for you during the update, holding the new [alnora_invoice] shortcode. You can move the shortcode to a page of your own and select it under Settings → General → Shortcodes.
    • Add appointment — book on a patient’s behalf straight from the admin, for phone calls and walk-ins. Search your existing patients or add a new one, choose the doctor, service, date and time, then set the status and payment status by hand. Only times the doctor is genuinely free are offered, exactly as on the booking form, and no online checkout is ever started.
    • A booking added this way behaves exactly like one the patient made themselves: the confirmation and clinic emails, SMS and WhatsApp messages, calendar entries, telehealth links and Zapier webhooks all go out as normal, carrying the status and payment status you chose.
    • Appointment details now show “Added by”, naming the staff member who entered a booking. Bookings patients made themselves look exactly as before.
    • Your doctors can sign in and see their own information: a read-only My profile page with their details, locations, working hours and days off, and a My services page listing what they can be booked for. Everything stays managed by the clinic — a doctor cannot change their own schedule or make themselves unbookable.
    • A doctor signing in now sees only their own appointments rather than the whole clinic’s diary. Administrators and clinic managers still see everything.
    • A doctor is recognized automatically when their WordPress account uses the same email address as their doctor record, so there is no extra linking step. Only clinic staff accounts are matched, and a doctor already linked to another user is never claimed by an address match.
    • The per-doctor calendar color picker has been removed — doctors now use the Alnora brand color everywhere, so the booking form and calendars stay consistent. Nothing needs changing; existing doctors pick up the new color automatically.
    • On the Add appointment screen a Clinic Doctor now sees only the locations they work at and books into a specific one — the “Any location” option is no longer offered to them. Reception and administrators still see every location.
    • The Record button and a booking’s medical-record details are now shown only to staff with records access, so a Clinic Receptionist no longer sees a button that only led to a permission error.
    • The minimum for “Release unfinished payments after” is now 15 minutes, giving slow card authentication, bank redirects and PayPal approval more room before a slot is freed.
    • The Category filter is now two independent toggles — Service category filter and Doctor category filter — so you can show category chips on the service step, the doctor step, either or neither. Your existing setting is carried over automatically.
    • Refreshed the admin Settings: on/off options are now branded toggle switches, and in-page links use the Alnora green.
    • A course of treatment could be charged for a single visit. When a payment was started for a recurring series outside the original booking flow, only one appointment’s price was collected instead of the whole course. Payment links now charge for every visit still unpaid — already-settled and cancelled visits are left out — and refunds continue to work per appointment as before.
    • A PayPal payment from an emailed link that the patient approved but never returned to confirm is now collected automatically on the webhook, the same as a payment made during booking, so the clinic is paid rather than left waiting.
    • A telehealth appointment added from the admin as Confirmed now includes its Zoom/Meet video link in the confirmation email and SMS — previously the link was missing even though it existed on the booking.
    • Payment links are signed and time-limited. Appointment references run in sequence, so a link without a signature would have let someone read another patient’s invoice by changing a number in the address.
  20. 1.3.0 10 July 2026

    Unfinished payments stop blocking your diary — and PayPal payments that were never collected now reach you.

    • Unfinished payments no longer hold a slot forever. If a patient starts a Stripe or PayPal checkout and never finishes — closes the tab, loses signal — the appointment used to keep that time blocked indefinitely. Alnora now frees it after a period you choose under Settings → Payments (30 minutes by default, minimum 10, or 0 to never release).
    • The payment is always checked with Stripe or PayPal before anything is released. If the patient did pay and simply never made it back to your site, the booking is kept, marked paid, and the confirmation goes out as normal — so nobody loses an appointment they paid for.
    • If a payment somehow arrives after a slot has been released, you are emailed the reference, patient and amount so you can refund it or rebook them. A payment can no longer arrive without you knowing.
    • Appointments waiting on a checkout now show as “Awaiting payment” in the Appointments list, so your team can see why a pending booking is holding a slot and that it will clear itself.
    • PayPal payments that patients approved but which were never collected. PayPal only completes a payment when the patient returns to your site, so if they approved it and then closed the tab, the money never reached you — and the reference was lost after an hour. Alnora now stores the order properly and collects these payments, either the moment PayPal notifies us or at the next check.
    • The booking calendar mislabelled its day columns when the week started on a day other than Monday or Sunday. Any first day of the week is now handled correctly.
    • Security: the page patients return to after paying has been hardened. A crafted link could previously cause an unpaid appointment to be removed. Returning from a checkout now requires a signed token tied to that specific payment, and only a still-pending, unpaid booking can be released — confirmed appointments, and anything marked paid, deposit, cash or refunded, are never affected. The free version on WordPress.org has no online payments and was not affected.
    • Stripe checkout sessions now expire in step with your release window, and Alnora listens for Stripe and PayPal’s own notifications, so a freed slot is usually bookable again within seconds rather than waiting for the periodic check.
    • The booking calendar now follows your site’s own Settings → General → “Week Starts On”, so it always matches the rest of WordPress. Alnora’s duplicate setting has been removed. If you had set a different first day in Alnora, the calendar will now follow WordPress — change it there if you prefer the other one.
  21. 1.2.9 5 July 2026

    The wording you type into your cancellation and reminder templates is now the wording that actually goes out.

    • “Reschedule — clinic notification” is now an editable template with its own send switch, so the copy your clinic receives when an appointment moves can be worded however you like. Previously it was fixed text.
    • Custom wording for the patient cancellation email, the reminder email and the SMS/WhatsApp reminder was saved and shown in the editor, but never actually sent — the built-in default went out instead. What you type is now what patients receive.
    • The patient portal showed “no appointments” when a request failed or the session had expired, rather than saying that something had gone wrong. It now reports the real problem.
    • Leaving the booking form or the patient portal open until its security token expires no longer shows a raw “Cookie check failed” error. It now explains that the page has been open too long and asks you to refresh.
  22. 1.2.8 2 July 2026

    Search long doctor and service lists, and decide exactly which emails and messages go out.

    • Optional search boxes on the booking form — let patients type a doctor’s name or a service instead of scrolling. Each is a separate toggle, so you can switch on whichever list is long. Search works alongside the category filter: the chips narrow the list first, and the search looks within it.
    • A “Send this email” switch on every email template, and “Send this message” on every SMS/WhatsApp template — turn off any single notification, such as the clinic’s own new-booking copy, without touching the rest. Everything stays on unless you say otherwise.
    • Emails now show each location’s address next to its name, so patients know where to actually turn up rather than just which branch. Custom templates using the {location} token pick this up automatically — no edits needed.
    • Click any completed step in the booking form’s progress bar to jump straight back to it, as well as using the Back button. Answers already given are kept.
    • When a booking form is limited to one doctor by shortcode, it no longer offers locations that doctor doesn’t work at. Previously every location was listed, and picking the wrong one showed a misleading “no free times on this day” message; now only the doctor’s real locations appear, and the location step disappears entirely when just one is left.
  23. 1.2.7 27 June 2026

    Dates and times now follow your WordPress format settings everywhere.

    • The date and time format now follows your WordPress → Settings → General options across the whole plugin — booking slots, the your-details step, all emails, SMS and WhatsApp messages, the patient portal, and every admin page. Set 12-hour or 24-hour time and your preferred date style once, and it applies consistently everywhere.
    • Zapier webhooks now include ready-to-read “start” and “end” date/time fields alongside the raw values, so your automations can use them without any extra formatting.
  24. 1.2.6 20 June 2026

    More control over fixed deposits.

    • A new “Always charge the full deposit” option for fixed deposits — collect the full deposit even when the chosen service is free or costs less than the deposit amount. When it’s off, the deposit is still capped at the service price, as before.
  25. 1.2.5 14 June 2026

    Accurate timezones for clinics that run on a different timezone from their website, plus tidier recurring cash bookings.

    • Google Calendar events, Zoom telehealth meetings and appointment reminders now follow your clinic’s timezone setting. If your clinic timezone differs from your website’s, they all now line up at the correct local time — and keep working across summer/winter clock changes.
    • The main admin menu is now labelled “Alnora Clinic”.
    • The “pay in cash at the clinic” status is now applied to every appointment in a recurring series, not just the first one.
  26. 1.1.2 9 June 2026

    Plan, preview and pay for recurring appointments — patients see every upcoming visit before booking and can settle the whole course in one online payment.

    • See every recurring visit before you book — choose a repeat frequency and the booking form now lists the exact upcoming dates and times, taken from the doctor’s genuinely free slots (and the chosen location).
    • Pay for a whole course of recurring appointments online in one checkout — the total covers every visit, each appointment is marked paid, and a single visit can still be refunded on its own if you cancel it.
    • Recurring repeats now stay on schedule: if the exact time isn’t free, the booking keeps the same day and moves to the nearest free time — or, only if that day is fully booked, to the closest following day — instead of skipping a whole week, fortnight or month.
    • A recurring booking is no longer completed if one of the previewed times was taken while the form was being filled in — the patient is asked to review the dates, preventing a double booking.
    • Recurring booking emails now show the full amount for the whole series, not just the first appointment, and include the patient’s reason/notes.
    • Refunds made from the Stripe or PayPal dashboard for a recurring series now update every appointment in the series, not just one.
    • Removing or cancelling one appointment in a recurring series no longer deletes the uploaded files shared with the other appointments’ medical records.
    • Rich-text service descriptions now keep their paragraphs in the “Read more” popup.
    • Cancelling an appointment from the admin no longer occasionally sends a duplicate cancellation email.
  27. 1.1.1 5 June 2026

    Book several services in one visit, organize your team and menu with categories, and reschedule a booking in a couple of clicks.

    • Multiple services in one appointment — patients can pick several services in a single booking, with durations and prices added up automatically and the whole block reserved on the doctor’s schedule.
    • Doctor and service categories — group your team and your service menu, with a category filter on the booking form so patients narrow down faster.
    • Reschedule an appointment straight from its “More info” panel: pick a new date and time from the doctor’s genuinely free slots. The patient gets a new email, SMS and WhatsApp, and calendars (Google/Outlook) and Zapier update automatically.
    • Editable SMS & WhatsApp message templates — a single template drives both channels, so you never edit two copies.
    • Rich-text service descriptions with a “Read more” popup on the booking form.
    • The booking form’s date & time step now loads noticeably faster.
    • Search and a new category column on the Services list, plus search on the Appointments and Doctors lists.
    • Invoices list each service on its own line, and “Service” becomes “Services” automatically across emails, invoices and calendars when more than one is booked.
    • Tidier, shorter calendar event titles so busy days stay readable, and shorter appointment reference numbers.
    • New “first visit” badge on the Appointments list so you can spot new patients at a glance.
    • Recurring appointments now carry every selected service to each occurrence.
    • License and status notices always appear above the page title in the admin.
  28. 1.1.0 1 June 2026

    Offer a service across several doctors — not just one.

    • Assign a service to multiple doctors — pick any set of doctors, or leave it open to every doctor.
    • The booking form now shows each service only to the doctors who actually offer it.
    • The service editor now uses a multi-select doctor list in place of the single “Offered by” dropdown.
  29. 1.0.0 May 2026

    First public release of Alnora Pro.

    • Multi-step booking wizard (location → doctor → service → date & time → details), as a shortcode and Gutenberg block.
    • Unlimited doctors and staff, each with their own working hours, breaks and holidays.
    • Services with duration, price and per-doctor assignment.
    • Multiple clinic locations.
    • Recurring appointments and a waitlist for fully-booked days.
    • Online payments with Stripe & PayPal, deposits, and automatic invoice PDFs.
    • Encrypted patient medical records (AES-256), with prescription & diagnosis PDFs.
    • Patient self-service portal and CSV import for patients & doctors.
    • Email, SMS and WhatsApp reminders (Twilio), with fully editable email templates.
    • Google Calendar & Outlook sync, and Zoom / Google Meet telehealth links.
    • Zapier webhooks and monthly revenue reporting.
    • Roles for Admin / Doctor / Receptionist, and a full GDPR toolkit (consent log, export, erasure).
    • Booking widget customization (fonts, colors, radius) and 13 languages with localized PDFs.

Get every update as it ships.

An active Pro or Clinic license keeps your clinic on the latest version — automatically.

See pricing Read the docs