Four fresh fixes: a less intrusive bot check, a phone-friendly editor and dates that release themselves

What this batch of updates covers

This post brings together four recent fixes that touch two different areas: the public side of your site and page editor, and payments in the rental module. The first two change what your visitor sees and feels when filling in a form, or what you experience editing your site from a phone. The third prevents a situation where a dropped connection or a closed tab wipes out minutes of work. The fourth concerns the rental module and fixes a problem where an unpaid booking held dates hostage indefinitely.

If you manage your site mainly from a computer and don't use the rental module, the first two updates still matter, since they affect every public form regardless of where it's filled in. But if you often work on your site content from a phone, or you use the rental module, it's worth reading through all four sections.

All four changes are already live, nothing needs to be ordered or purchased. One exception is Cloudflare branding, which can only be removed on the Enterprise plan, and we cover that in more detail below.

The bot check now appears on forms only when needed

Every public form on a Husly site - contact form, order form, feedback form - runs Cloudflare Turnstile in the background, which tells humans and bots apart. Previously it always drew itself as a visible grayish box right above the submit button, regardless of whether Cloudflare actually needed to challenge the visitor. On a dark site it often showed up as a black box on a white background, since the box followed the visitor's device preference rather than the site's own theme.

Three things are different now, all at no extra cost:

• The box only draws itself when Cloudflare actually wants to challenge the visitor. The check still runs in the background every time, but almost nobody sees anything.
• The box follows the site's own light or dark theme setting, not the visitor's device preference.
• If the box does appear, it now stretches to match the width of the form fields instead of sticking to a fixed 300-pixel width.

This is nothing you need to turn on yourself - the change applies automatically to all public forms.

Two things remain deliberately unchanged. The box is still in English only, since Turnstile doesn't offer an Estonian translation and switching to Finnish or Russian would be a worse choice. The Cloudflare logo in the box also stays - removing it is an Enterprise plan feature, and it isn't worth the price tag just to hide a brand mark.

The page editor now actually works on phones

The on-site page editor - the one you open directly on your published page - was built for computer screens and simply didn't work properly on a phone. A series of fixes now make it genuinely usable on mobile too.

The toolbar now fits on screen

The bar that appears on top of your own published page while editing used to carry close to 570 pixels of buttons on a single row - site menu, text mode, undo, save, assistant, language and account menu, and a few more. On a phone, with a 375-pixel-wide screen, the buttons squeezed together so tightly that Save and Done ended up around seventeen pixels wide, with the text overlapping. Now the bar wraps onto two rows on a phone, and every button is at least 38x38 pixels - large enough to tap accurately with a finger.

The editing panel no longer covers the whole screen

The floating settings panel used to take up 96% of the screen width on a phone and could cover the entire window height - leaving the canvas itself completely hidden. Since a block can only be selected by clicking on the canvas, changing a single word often meant five steps: collapsing the panel, scrolling, tapping the block, reopening the panel, and finally collapsing it again just to see the result. Now, below a 640-pixel width, the panel becomes a bottom-anchored half-page sheet - a bit over half the screen for the panel, the rest for the canvas, which stays visible the whole time. That way you can select a block and immediately see how the change affects the page, on the same screen.

Nothing needs to be switched on for this - open the editor from a phone and you'll see the new layout automatically.

The keyboard overlap issue has also been fixed - previously the text field often ended up hidden behind the keyboard right when you started typing. The editor now tracks how much of the screen the keyboard covers and brings the edited spot into view. Dragging and docking the panel to the left disappear on a phone, since there's simply no room for them on a narrow screen - that's a deliberate choice, not a bug.

Unsaved changes now stay in the browser

If you were editing a page from your phone and the operating system decided to close the tab - say you replied to a message and came back a few minutes later - all the work done so far used to be lost. No warning was given, since autosave is off by default on a published page: saving means publishing, and Husly doesn't write anything to the server without your explicit command.

Now, changes made are kept in the browser's own storage (localStorage). A couple of seconds after your last click, and once more right before the tab closes, the state of the blocks is written to the browser - not to the server, and not visible publicly. When you open the same page in the editor again, a message at the top of the panel shows when the changes were made, with two options: restore the changes or discard them. Restoring puts the changes back on screen, but they remain unsaved - publishing still requires pressing Save.

The message disappears automatically as soon as you start editing during a new session - if you've already started working, the decision has effectively been made, and the old message would become more of a trap than a help.

Changes are kept for a week, after which they're deleted. If the browser's storage is full, older drafts are deleted first, not the one you're currently working on, and a draft that's too large is simply not saved at all rather than saved partially. In private browsing mode, where storage doesn't work at all, the editor doesn't lose anything - it simply knows there's no draft to begin with. One thing is deliberately left as is: if you click "leave without saving" on exit, the draft is deleted immediately - that's your deliberate decision to abandon the work, and offering it back later would go against your own choice.

Unpaid rental bookings now release their dates on their own

If a renter was sent to pay but closed the tab before completing payment, the booking used to stay stuck in a "pending" state and hold the dates hostage indefinitely. Since no email is sent to either party for an unpaid booking, the only trace of it was a line in the operator's listing - and the dates stayed off the market until someone noticed and cancelled it manually.

Now every booking sent directly to payment gets a holdUntil timestamp matching the validity period of the payment provider's page, which is 30 minutes. Every five minutes the system checks all open payments with the payment provider:

• if the page has actually been paid, the booking is confirmed even if the webhook never arrived;
• if the page is still being paid or the payment is still in transit (for example a bank transfer that arrives days later), the date hold stays in place;
• if the page can no longer be paid, the booking becomes expired and the dates are released immediately.

If the payment provider can't be reached at all (for example due to a longer outage), the dates are held for one more day past the deadline and only then released - enough time to cover a typical outage, but not indefinitely.

This doesn't affect regular inquiry-based bookings that were never sent to payment - for example if the site doesn't accept cards or the payment page never opened. Those still wait for the operator's decision exactly as before.

In the operator's listings you'll now see a new status next to the booking, "Expired unpaid" - it can still be confirmed manually if needed, say if the renter calls and pays on site. Since the renter was never told the booking even existed before completing payment, no separate email is sent about the expiry either - that would be the very first message the renter would ever see.