Mowz Delivery Deadline

There are three reasons, and the app can tell you which one you have got. Open it and read the first screen before anything else.

Cause 1: the block is not on your theme yet

This is the one, nine times out of ten, and it is not broken. It is not placed.

Shopify does not let an app put anything on your product page by itself. You place a block, once, in the theme editor, and you choose where on the page it sits. Until you do, the deadline is saved and simply has nowhere to appear.

The app checks this on every page load and says so by name: “Checked on this page load: the block is not on your product template on [theme] yet. Nothing shows on your product pages until it is.”

The quick way. Click Add the Mowz block on that screen. The theme editor opens with the block ready to drop in. You still have to press Save, top right. That's the step almost everyone misses.

The manual way:

1. Shopify admin → Online Store → Themes
2. On the theme marked Live, click Customize
3. In the template dropdown at the top, choose Products → Default product
4. Find the section you want it in, usually the one with the price and the buy button, and click Add block
5. Under Apps, pick Mowz delivery deadline, then drag it where you want it
6. Save, top right

There is no App embeds switch for this app. If you have used our countdown app, that one has one and this one does not. Don't go looking for it.

Cause 2: nothing is published, or the deadline has passed one of its dates

Look at your list. A deadline shows one of four words:

Status	What a shopper sees
Draft	Nothing. Saving is not publishing.
Published	The live one, assuming the block is on your theme.
Closed	Your final order date has passed. Shoppers see your closed message, no countdown.
Hidden	Your hide-after date has passed. The block renders nothing at all.

Closed and Hidden are not statuses you set. They are what Published looks like after each of your two dates, and this article walks both.

One deadline is published at a time. Publishing a second one unpublishes the first, with a confirmation naming both. Nothing is deleted.

Cause 3: the deadline is limited to products this one is not in

If you set Where it shows to tags or collections, a product outside that list gets nothing at all, which is exactly right and looks exactly like a fault. Open the deadline, read the line under the field, and check the number beside it. This article is the whole of that one.

If all three look right

Then it's ours. Send us your store address, your live theme's name, and the URL of one product page it should be on, and we'll look at the page ourselves.

And the one to remember for later: blocks are per theme. Publish, duplicate or restore a theme and the new one starts without it. See it was working and now it's gone.

Some older themes can't carry app blocks on a product page at all. It isn't your theme being broken and it isn't something we can work around.

Shopify introduced app blocks with Online Store 2.0 themes. A theme built before that has no JSON product template for a block to go into, so Shopify doesn't offer ours, and doesn't offer any app's.

The app reads your live theme and says so plainly rather than leaving you clicking: “[theme] cannot carry the block. [theme] is an older theme without a JSON product template, so Shopify does not allow app blocks on its product pages. Nothing shows under this theme.”

Your deadline is untouched. All of it is still there. Switch to an Online Store 2.0 theme, Dawn and Horizon are the two we test on, and it appears with everything you configured.

If you'd rather stay on your current theme, the honest answer is that this app can't show anything on it. We'd rather tell you that than take up your evening.

Nothing has been deleted. Two things cause this and they're easy to tell apart.

If a theme was published, duplicated or restored

That's almost always it. Shopify keeps block placement inside each theme, so a theme that becomes live starts without our block, even though the app itself is untouched and still configured.

Open the app. If that's what happened, the first screen is already saying so, in red, naming the theme: “Your live theme is now [theme], and the block is not on it.” The button opens the theme editor for that theme. Add the block, Save, and it's back with every setting.

If no theme has changed

Then look at the two dates on your deadline. After your final order date the block stops counting down and shows your closed message instead. After your hide-after date it renders nothing at all. Both look like a disappearance from the storefront and only one of them is total.

The app says which state is in effect, on the home screen: “Counting down”, “Showing your closed message. The final order date (…) has passed”, or “Hidden. Your hide-after date (…) has passed”. That line names the date that did it.

If a theme hasn't changed and neither date has passed, tell us that. Then it's something else and we'll look properly.

Almost always this is three settings doing exactly what they were told, in an order that isn't the order in your head. They're separate and they stack:

• Cutoff: the last moment an order still counts for that day. It is not when you ship. An order at 13:59 against a 14:00 cutoff counts for today. An order at 14:01 counts for tomorrow's cutoff, and everything below shifts a day.
• Processing days: full days between the cutoff and the parcel leaving you. Same-day dispatch is 0, and 0 is a valid setting. If you pack and hand over on the same day you take the order, set it to 0. Leaving it at 1 moves every date the app publishes by a day, in the direction that makes you look slower than you are.
• Delivery days, fastest and slowest: counted from the day the parcel leaves you, not from the day the order comes in. This is the part most often read as “from the order”.

So a 14:00 cutoff, 1 processing day and 2 to 4 delivery days is not “2 to 4 days from now”. It's: order before 14:00 today, dispatch tomorrow, arrive two to four working days after that.

You don't have to take our word for any of it. The editor shows How the dates are worked out: the whole chain, step by step, for two different orders, in your own dates, updating as you type.

Placed now · counts for Tuesday's 14:00 cutoff · 1 processing day · dispatches Wed 2 Dec · 2 to 4 delivery days · arrives Fri 4 Dec to Tue 8 Dec

The second line is an order placed just after today's cutoff, which is the one that catches people out. Checking at nine in the morning and being satisfied tells you nothing about what a shopper sees at three in the afternoon, and on a Friday afternoon the gap is three days.

If a step looks wrong, the setting above it is the one to change. That's what the chain is for.

Days it skips are named, with the reason: “skipping Sat and Sun”, “Fri 25 Dec is a day you do not dispatch”. If a date looks late, read the skips first. Usually the app is right and the weekend is the answer.

And if the chain in the admin ever disagrees with what your product page shows, that's a bug and we want it today. They run the same engine. They're not supposed to be capable of disagreeing.

There are two, they aren't the same question, and this is the one place the app asks something subtle.

Setting one: the cutoff grid. Seven rows, one per day. A day with a cutoff is a day a parcel can leave you. Untick a day, or mark it Not a dispatch day, and nothing ever dispatches on it.

Setting two: the Weekends choice, under After the cutoff. This decides whether Saturday and Sunday count while the app is counting processing days and delivery days.

• Saturday and Sunday do not count as processing or delivery days: the default. The clock stops at the weekend and picks up on Monday.
• Saturday and Sunday count like any other day: a weekend day counts the same as a Tuesday.

One is about dispatching. The other is about counting. That's the whole distinction, and here's what happens when they disagree:

• A Saturday cutoff, with weekends set not to count. You can dispatch on Saturday, but Saturday will never be reached by a processing count, because processing skips it. In practice a Saturday cutoff only does something for an order placed on Saturday itself with 0 processing days.
• Weekends set to count, with no Saturday or Sunday cutoff. The count runs through the weekend, but when it lands on a Saturday the parcel can't leave, so dispatch moves forward to Monday and the chain says so: “Sat 6 Dec is a weekend”.

Neither is broken and neither needs fixing by us. If the dates look wrong, read the chain in How the dates are worked out: it names every day it skipped and why, so you can see which of the two settings produced the result.

One more that's worth a sentence. Marking a weekday as not a dispatch day stops the parcel leaving that day. It does not stop that day counting as a processing day, because you're still at work, there's simply no pickup. Weekends are the only days the counting setting governs.

And “no dispatch on Sunday” doesn't mean “we're closed on Sunday”. Orders still come in on a no-dispatch day, the countdown still runs, and the app just picks the next day that can dispatch.

That's deliberate, and it's only ever the case under the Christmas deadline.

Under the Christmas preset the headline is about your final order date. Counting down to a date eleven weeks away in hours and minutes is noise, so until that date is 14 days away the headline names the date and the time and carries no clock:

Order by Thu 17 Dec, 14:00 for delivery before Christmas

Inside the final 14 days, it switches to the version with the clock in it:

Order within 3d 4h, by Thu 17 Dec at 14:00, for delivery before Christmas

Two lines of copy, both yours to edit: Deadline line, until then and Deadline line, final 14 days. The editor's preview shows you whichever one applies today.

Under “No season, always show the next cutoff” there is no far version, because your next cutoff is never 14 days away. The countdown is always live.

The second line, the delivery estimate, is always about an order placed right now, whichever headline is showing. That's intentional: the headline is about the deadline, the line under it is about today.

No. Not from us, and not from your own carrier.

What the app shows is an estimate. It's arithmetic on the settings you gave it: your cutoff time, your processing days, your delivery range. It isn't a commitment from a carrier, and neither we nor you can see what happens to a parcel once it's collected.

That's why the block carries a disclaimer line, and why it's yours to edit rather than ours to bury. The default reads: “Delivery dates are estimates based on our dispatch times. Carrier delays can happen.” Change the wording if you like. Keep it saying estimate.

The app won't stop you writing “guaranteed”. We'd rather you didn't, and the reason isn't legal caution. An app that reads as a delivery promise turns one late parcel into a complaint, a refund request and a one-star review of your shop, and none of that lands on us.

The part that is genuinely, verifiably true is the deadline itself. “Order within 4h 12m” is a real statement about your own cutoff, and it's the bit a shopper acts on. Lead with the deadline. Keep the date underneath it as an estimate.

If you'd like, send us your wording and we'll tell you honestly how it reads.

That notice is the app checking your own deadline against your own numbers, and it's worth reading slowly, because this is the one mistake in this app that reaches a customer.

Under the Christmas deadline you type a final order date. Beside it the app shows Last safe order day from your own settings: the last day an order can be placed and still arrive by Christmas Eve, worked out from your cutoffs, processing days, delivery days and the days you don't dispatch.

Three things it can say:

• “Your final order date matches.” Good.
• “Your final order date is earlier than that, which is fine. It leaves a margin.” Also good, and quite sensible in December.
• “Your final order date is later than that. An order placed on it would, by your own numbers, arrive after Christmas.” Read this one. It names the date it computed.

You can still publish. It's your shop and there may be a reason. But the number in that notice came from the same engine your product pages run, so if it disagrees with the date you picked, one of the two is wrong, and it's usually not the arithmetic.

The most common cause is a round number. Everyone in your category says “order by the 18th”, so the 18th gets typed over whatever the app worked out. If your own cutoff, processing and transit say the 16th, the 18th is a promise you can't keep, and the person who finds out is your customer on Boxing Day.

If the notice says “By your own numbers no order day lands before Christmas”, check your delivery days and processing days first. Something in there is larger than you meant.

The cutoff times you set are in your store's timezone, not the timezone of the computer you're sitting at. The editor says which one it's using: “Times in your shop's timezone (…).”

Your store's timezone is in Shopify admin → Settings → General → Store defaults → Timezone. If your store was set up in another country, or you're travelling, those are two different clocks and that's usually the whole answer.

Check the store timezone first, then the cutoff in the app.

If the store timezone is right and the countdown is still out, tell us the store timezone, the cutoff you set, and what your product page is showing right now. That's a real one and we want it.

By default the deadline shows on every product page, which is often not what you want. Not everything in a shop can make a Christmas deadline.

In the editor, Where it shows gives you three choices, and you pick one:

• All product pages: the default.
• Only products with any of these tags: comma-separated. Case doesn't matter; we lower-case them for you. A product carrying any one of them shows the block.
• Only products in any of these collections: collection handles, comma-separated.

It's tags or collections, never both. The choice is a choice for a reason: Shopify's own product search quietly drops one of the two when you ask for both, and we'd rather not show you a number we can't stand behind.

Collections are matched by handle, not by name. That's the last part of the collection's web address: winter-gifts, not “Winter Gifts”. Open the collection in your admin and copy it out of the URL.

Use the count. As you type, the editor asks Shopify how many of your products match, right then, and tells you: “12 products carry one of these tags right now.” For collections it gives you one number per handle, never a total, because a product in two of your chosen collections would otherwise be counted twice. If a handle doesn't exist you get “no collection with that handle”, and if nothing matches you get a warning saying so before you publish.

That count is the fastest way to catch a typo. A tag that no product carries means the block renders nowhere at all.

One thing the count can't see. A collection has to be published to the Online Store sales channel for your theme to know which products are in it. If it isn't, the admin can still count its products, but your storefront genuinely can't see the collection, so the block matches nothing and appears nowhere. Check Shopify admin → Products → Collections, open the collection, and look at Publishing on the right. If Online Store isn't listed, add it and save.

If a product still isn't showing the block:

• Check the tag's spelling against the product itself. Copy it, don't retype it.
• Check you're looking at a product that's actually in the list.
• Check the block is on the template that product uses. A product on a custom template needs the block on that template too.

Two stages, both yours, so the block never sits there counting down to a date that has gone.

Stage one, from your final order date's cutoff. The countdown stops and the block shows your closed message in its place. The default reads: “Christmas orders have now closed. We are still shipping. Orders placed now arrive after Christmas.” Edit it to whatever is true of your shop. The block is still there and still says something useful.

Stage two, from your hide-after date. The block renders nothing at all, and no script is fetched. Your product page is byte-for-byte what it would be with the app uninstalled.

The two dates are separate on purpose. The gap between them is the window where a shopper who missed the deadline still gets told, rather than being left to guess.

The app's home screen says which stage is in effect and names the date that put it there, so you never have to work out which of the two made it disappear.

Under “No season” there is nothing to end. The block always shows the next cutoff, all year.

Short version: nothing is showing on your storefront, nothing is left behind in your theme, and your settings are kept for a short window in case you come back.

• Your storefront is clean immediately. No block, no leftover code, no script, nothing in your page source. The page is what it would be if you'd never installed us.
• Your deadlines are unpublished, not deleted. Reinstall within the window and they're all still there, as drafts, with their settings, their copy and their targeting. You publish the one you want.
• Your access token and session are deleted straight away, on uninstall. The token can't be used again.
• Then Shopify tells us to delete the rest. Shopify sends us a shop-redact signal, normally 48 hours after you uninstall, and when it arrives we delete everything the app holds for your store. That's the real deletion and it isn't reversible.

We never wrote to your theme in the first place. The app's permissions are read-only and it has no ability to write to a theme at all, which is why there's nothing to clean up. The block you placed is yours, in your template; removing the app removes what it rendered.

If you'd like it deleted sooner, ask and we'll do it. What we store and why, including how long we keep each thing, is on our privacy page. Tech2Change BV is the data controller, and formal requests go to info@mowz.nl, or just ask us and we'll route it.

Fair question, and the install screen is blunt about it. We ask Shopify for two things.

• View your Online Store. So the app can tell you whether the Mowz block is on your live theme's product template instead of leaving you guessing, and name the theme when you change it. That is the check on the first screen, and it is read on every page load rather than remembered.
• View products. Used in exactly one place: counting how many of your products carry the tags or collections you typed, so you catch a mistake in the admin instead of on an empty storefront.

Both are read-only. The app cannot write to your theme and holds no write permission of any kind. The delivery deadline itself is computed entirely from settings you typed, your cutoffs, your processing days, your delivery days. It reads nothing about your products to work out a date.

The store owner block on that screen is not one we asked for. Shopify grants it to every app that gets installed and there is no permission we can decline to make it go away.

And the one that matters most: we ask for nothing about your customers. No customer, order, checkout or payment access. It is all set out on our privacy page.

The app is free. There is no paid tier, no trial, no usage limit and no billing of any kind in this version. Nothing in the app is locked.

What's next is a page of ideas we might build: different delivery times per country, the deadline in a bar at the top of every page, cart and checkout messaging, delivery times pulled from your carrier. Tap I want this on the ones you want, and answer the one follow-up question honestly. It's a vote, not a shop. Nothing there is for sale and nothing is waiting behind a paywall.

We read every vote. We won't promise you a feature or a date in return, but the votes are genuinely what we build from.