Changelog

Every phone field in your dashboard — your WhatsApp number, the numbers on delivery and pickup areas, driver contacts — now opens with your country's flag already selected. Some of these fields used to start on the platform's default country instead of yours, so typing a number the way you normally write it locally could save it under the wrong country code, and messages to that number would never arrive. If a saved number looks wrong, open the field, pick the right flag, and save it again.

If you set a carousel slide to show only during opening hours, or only outside them, that setting was being ignored on two of the three storefront designs — the slide appeared around the clock regardless. It now applies everywhere. Worth a quick look if you had set this and it seemed to do nothing: the setting will start taking effect, and a slide you meant to hide outside opening hours will now genuinely hide.

We fixed an issue where emptying your business address, customer hotline or WhatsApp number in Settings did nothing — the page said it saved, but the old value came back. Clearing any of these fields now removes it properly, and entering a new value still works as before.

Option names now appear exactly as you typed them everywhere a customer or your team sees them — carts, order confirmations, printed tickets, the kitchen display, reports and your product feed. Where a size once showed up as "Extra-large", it now reads "Extra Large". Changes to your variants reach your storefront right away too: add a combination, add a value to a group like Size, or remove one, and customers see it on their next visit instead of waiting for the menu to refresh on its own. Add-ons you've limited to specific variants also stay limited to those variants now.

Changes you make to an item's add-ons now reach your storefront and counter immediately. Turning an add-on off hides it from customers straight away instead of leaving it on the menu until they tried to order it, editing a name or price updates what customers see on the next page load, and the order you drag your add-ons into is the order they appear in. Adding a new add-on now places it at the end of the list where you'd expect it, rather than jumping to the top.

We fixed an issue where saving your time slot settings could silently fail — the Save button appeared to do nothing, most often when picking a schedule type for the first time. Saving now works on the first try, and if a required field is missing, the page points you to it instead of staying quiet.

If you use the Delivery Trips add-on, the minimum and maximum trips you set now keep to a practical range of 1 to 100. Previously, saving an extremely large maximum could stop the checkout page from loading for your customers. Checkout now handles any value safely, and out-of-range settings are corrected automatically the next time you save. Nothing to change on your end.

Opening Top 20 Customers by Order Count, Top 20 New Customers, or Top 20 Customers by Purchase Value for a period with no matching orders showed an error page instead of the report. This could happen over a quiet week, on a newly opened store, or whenever a status or payment filter narrowed the results down to nothing. Those reports now load as expected, showing zeros across the summary cards and an empty table. Nothing to change on your end.

We fixed an issue where a formatted item description could show up blank or run together for some shoppers — most noticeably on iPhone Safari. Your descriptions, including bold text, lists, and paragraph breaks, now render correctly for everyone, on every device. Nothing to change on your end.

When you remove a language from your storefront, WhatsMenu now copies any text that only existed in that language across to your remaining default — your category names, item names, descriptions, summaries, and company info stay intact.

Before: if you'd added a second language but only typed translations for some fields, deleting your original language could leave the storefront showing empty names or descriptions on the other side.

Now:

• Removing a language fills any blanks in your new default from the language you're about to drop.
• Translations you've already written in the surviving language are kept exactly as they are — nothing is overwritten.
• Adding a new language also seeds it from your current language more completely, so you start with a full catalog to translate from instead of empty fields.

Nothing to enable. Applies to every storefront from this update onwards.

Two PromoCards quirks fixed in this release.

1-column cards now match the height preset you pick.

Before: choosing a 1-column layout caused cards to ignore your Card Height setting and stretch much taller than expected — a "Compact" 1-column hero could end up 600+ pixels tall on desktop. The other layouts (2-col, 3-col, 4-col, asymmetric) were unaffected.

Now 1-column cards size correctly to the preset:

• Compact — slim banner (~200px tall)
• Normal — standard hero (~280px tall)
• Tall — prominent hero (~360px tall)
• Vertical — full portrait hero (~480px tall)

If your existing 1-column cards looked too tall, they should now display at the right size automatically. No re-save needed.

Image cropping now follows the live card shape, not the shape at upload time.

Previously, when you uploaded an image to a card, the system pre-cropped it to match the group's current Card Height ratio (e.g. 16:9 for Normal, 3:4 for Vertical). If you later changed Card Height, the existing card images stayed cropped at the old ratio — so a Normal-sized image that you flipped to Vertical would show a wide-short slice of the original.

We've removed the server-side crop entirely. Uploaded images are now stored at their full source proportions (just resized so the long edge stays under 2000px on desktop / 1200px on mobile to keep file sizes sane). The visible crop happens at display time via your browser's native image-fit logic, so:

• Switching Card Height (Compact ↔ Normal ↔ Tall ↔ Vertical) immediately re-renders existing cards at the new shape — no re-upload.
• Mixing the same image across groups with different Card Heights now works as expected.
• For Vertical cards, your portrait sources finally show as portrait instead of being flattened into the previously hard-coded crop.

Note for cards uploaded before this update: their stored images are still in the old pre-cropped shape. They'll display center-cropped through the new logic, which works for most images but won't recover detail that was cut off during the original crop. Re-upload any card image that looks off and the new full-aspect storage takes over.

If you set a coupon to "first order only" or limit it per customer, those rules used to silently pass for guest customers — which meant a guest could reuse the coupon as many times as they liked.

Now those coupons require the customer to sign in before they can be applied. Guests get a clear "Please sign in to use this coupon" message; signed-in customers continue to see the original error if they don't qualify.

Coupons without per-customer rules are unaffected — guests can still use those exactly as before.

If you cap how many orders or items can be placed per day, those caps now switch over at midnight in your store's time zone — not server time. Stores far from the server time zone could previously see counters reset hours early or late.

We also tightened validation on the limit-setup form, so invalid dates or out-of-range numbers are caught before saving instead of producing unexpected behaviour later.

No action needed — your existing limits keep working, just on the right clock.

A few fixes for stores using Mollie:

• Webhook callbacks from Mollie now use the same API key your store is configured with, so successful payments mark orders as paid even on installs that only set the newer environment variable.
• Mollie payment IDs are stored against each order, matching how every other gateway records its reference for support lookups and refunds.
• The return URL after payment now lands the customer on the correct order success page.

If your Mollie webhooks were inconsistent before, no action needed — the next payment should flow through cleanly.

If your storefront is on a custom domain and you used the delivery map at checkout, customers could see a RefererNotAllowedMapError instead of the map. That's because Google Maps API keys are tied to specific domains, and the platform's key was only authorised for the WhatsMenu domain.

You can now plug in your own Google Maps JavaScript API key under the DeliveryMap module settings. When checkout loads on your custom domain, your key is used; on the WhatsMenu subdomain, the platform key continues to be used. No customer change needed — the map just works again.

Only relevant if you're on a custom domain and your map was misbehaving. Keep the field empty to keep using the default.